Wednesday 30 November 2011
Revised tips for video import to NVivo 9
I've just learnt that a step and a process described in an earlier post are problematic: in testing file imports into NVivo 9, I learnt that (1) the MP4 format is optimal for sizing, but heavily reduced files are not importable. Also, (2) NVivo 9 does support importing files bigger than 40MB as internal source (contrary to the software's help file advice, ahem!):
1. The MP4 format may be the optimal choice for reduced file size, but encoded versions may fail to import.
In an earlier post, I thought that the MP4 file format would be best used to import long interviews into NVivo due to their relatively smaller size. However, I could not import these files, even though they were under 40MB and in a format approved for import.
2. The 40MB size limit restriction on videos imports can be exceeded using WMV and AVI formats
I did succeed in importing unencoded AVI and WMV files and after struggling to encode other interview files below the 40MB guideline, I succeeded with importing files of 53, 64 and 103 MB files sizes as internal source.
In testing imports, I was also reminded of the important practice of always backing up one's source files; these proved useful as a reserve source when subsequent encodings were not convertible to a new format.
I learnt these facts soon after failing to import MP4 encodings of Thabang's first video interview. NVivo 9 showed these error messages:
I used Any Video Convertor to further reduce the video's file size; selecting a smaller video size (220 * 176 from 320 * 240). The resulting video was 27.8 MB in size. I then tried to import it into NVivo, but received the same generic error message.
I then tried to re-encode the reduced file to a WMV file format, as this matched those used for successful imports of Edmore and Khanya's first interviews. However, this conversion failed.
I then used my video backup folder to source an earlier .wmv version of the file and converted that. However, it went from being 55.4 Mb to 94.4 MB in size; probably due to fixed audio settings that I could not change, while the screen and video settings could be reduced. Out of frustration, I tested whether I could import an earlier AVI export of the interview and was suprised when a 54 MB file import succeeded.
I then tested two WMV interviews with Ace (65 and 105 MB respectively), which were proving difficult to reduce and these imported fine.
Today's learnings have raised an interesting question; should I edit my earlier post to be more accurate and useful for other researchers? While this is tempting, it would be misleading and undermine my research blog's ability to show some of the challenges which emerge in the research process. So, I won't updating the post, but I will certainly add a comment warning readers not to follow the problematic step and process!
If you agree, or not, please add a comment below. Thanks :) .
Labels:
nvivo
,
qualitative
,
research
,
software
Location: Cape Town, Western Cape Province, RSA
Cape Town, South Africa
Tuesday 29 November 2011
Six key changes I'd like in NVivo 10.
Written for QSR International and NVivo 9 users on Apple Macs and NVivo 10's software developers.
Unlike most NVivo 9 users, I run my 62-bit version on Windows 7 via Parallels in Mac OS X Lion. I did not go the PC-only route that's optimal for NVivo, as I also use a Mac in media tutoring and didn't want to buy two desktops! In my context some of the issues described below may have local origins, but I hope that most are global and can be addressed by QSR International's developers in the future:
1. Provide feedback on NVivo's start-up progress during slow starts
Even though the files I use are relatively small, NVivo's stand-alone version has an erratic starting speed and can be slow to start. When this happens, users have no indication that there's a problem and what may be causing it: athough I initially thought this may be attributed to relatively slow entry-level broadband speed affecting the software authentication process, since moving my desktop to optimal broadband speeds in a UCT office, the problem still persisted. I suspect this may now be attributed to accessing files over a PC network using a standalone version of the software.... It would help me if NVivo included a progress tracker. I would also have no problem with NVivo's developers using this tracker to aggregate information on problems experienced in my local configuration, so that they could use this information for making future versions more reliable.
2. Stop a user opening the same file several times at once
When NVivo is slow to open, I sometimes click on the same file several times to check it's opening. The result is that when NVivo does open fully, there are several windows showing the same file :( ! Since this has no end-user benefit and could cause problems, NVivo's developers should aim to prevent this from happening in future versions.
3. Give better feedback to users on video conversions and sizing correction
There are several restrictions on the file size and format types that NVivo can import as internal or external source and the import process could be better designed to help researchers meet these criteria. For example, this could include linking users to online guidance when they attempt to import files that are in the wrong format, or too large. Based on my experiences with video imports, this would be particularly beneficial to researchers using NVivo for the first time; many do not have expertise in file formats and sizes and addressing their limitations would improve the NVivo software experience.
4. Provide feedback on failed video imports
Even after meeting NVivo's file format and sizing criteria, there can still be problems with accessing files on external devices. For example, I'm using a Drobo S drive. After converting its drives to ones that both my Mac and PC can access, it was still difficult to view these videos in NVivo 9. It would be useful if I could view feedback on failed imports and the potential causes: I'm sure other users would agree.
5. Allow the user to set a custom auto-save time
A fair amount of data can be lost if one's computer goes down between NVivo's default auto-save time that set to 15 minutes and cannot currently be changed in the stand-alone version of the software. I think users should be given control of their auto-saving time; whilst being notified of the benefits and hazards of their potential choices.
6. Better integration on the Apple Mac platform
Using NVivo on Mac can be problematic, particularly because it may require complicated troubleshooting: issues may originate or result from interactions between Mac OS X, Parallels, NVivo 9 and the usual suspect, Windows 7. In addition, some of the keyboard shortcuts available to PC-users are difficult or impossible to access on a Mac; for example, there is no "insert" shortcut on Mac for inserting comments as a Mac keyboard does not offer the PC button it requires. There are also challenges with the shift to the Mac OS Graphic User Interface versus s PC's Windows; for example, using Ctrl + Shift + Up keys on a Mac to move a note up one, shifts the notes view to the top of the page, which is irritating if one has created a lengthly annotation for a screengrab and then needs to scroll back to where one was. Even if the number of NVivo 9 users on Mac is marginal, I'm sure they would appreciate NVivo 10's developers addressing issues like these...
So, that's my wishlist for changes; here's hoping my PhD research does not finish before they are implemented :) ! As an NVivo user, what are your thoughts on changes you'd like to see? Please add them to the "comment" box below, ta!
Unlike most NVivo 9 users, I run my 62-bit version on Windows 7 via Parallels in Mac OS X Lion. I did not go the PC-only route that's optimal for NVivo, as I also use a Mac in media tutoring and didn't want to buy two desktops! In my context some of the issues described below may have local origins, but I hope that most are global and can be addressed by QSR International's developers in the future:
1. Provide feedback on NVivo's start-up progress during slow starts
Even though the files I use are relatively small, NVivo's stand-alone version has an erratic starting speed and can be slow to start. When this happens, users have no indication that there's a problem and what may be causing it: athough I initially thought this may be attributed to relatively slow entry-level broadband speed affecting the software authentication process, since moving my desktop to optimal broadband speeds in a UCT office, the problem still persisted. I suspect this may now be attributed to accessing files over a PC network using a standalone version of the software.... It would help me if NVivo included a progress tracker. I would also have no problem with NVivo's developers using this tracker to aggregate information on problems experienced in my local configuration, so that they could use this information for making future versions more reliable.
2. Stop a user opening the same file several times at once
When NVivo is slow to open, I sometimes click on the same file several times to check it's opening. The result is that when NVivo does open fully, there are several windows showing the same file :( ! Since this has no end-user benefit and could cause problems, NVivo's developers should aim to prevent this from happening in future versions.
3. Give better feedback to users on video conversions and sizing correction
There are several restrictions on the file size and format types that NVivo can import as internal or external source and the import process could be better designed to help researchers meet these criteria. For example, this could include linking users to online guidance when they attempt to import files that are in the wrong format, or too large. Based on my experiences with video imports, this would be particularly beneficial to researchers using NVivo for the first time; many do not have expertise in file formats and sizes and addressing their limitations would improve the NVivo software experience.
4. Provide feedback on failed video imports
Even after meeting NVivo's file format and sizing criteria, there can still be problems with accessing files on external devices. For example, I'm using a Drobo S drive. After converting its drives to ones that both my Mac and PC can access, it was still difficult to view these videos in NVivo 9. It would be useful if I could view feedback on failed imports and the potential causes: I'm sure other users would agree.
5. Allow the user to set a custom auto-save time
A fair amount of data can be lost if one's computer goes down between NVivo's default auto-save time that set to 15 minutes and cannot currently be changed in the stand-alone version of the software. I think users should be given control of their auto-saving time; whilst being notified of the benefits and hazards of their potential choices.
6. Better integration on the Apple Mac platform
Using NVivo on Mac can be problematic, particularly because it may require complicated troubleshooting: issues may originate or result from interactions between Mac OS X, Parallels, NVivo 9 and the usual suspect, Windows 7. In addition, some of the keyboard shortcuts available to PC-users are difficult or impossible to access on a Mac; for example, there is no "insert" shortcut on Mac for inserting comments as a Mac keyboard does not offer the PC button it requires. There are also challenges with the shift to the Mac OS Graphic User Interface versus s PC's Windows; for example, using Ctrl + Shift + Up keys on a Mac to move a note up one, shifts the notes view to the top of the page, which is irritating if one has created a lengthly annotation for a screengrab and then needs to scroll back to where one was. Even if the number of NVivo 9 users on Mac is marginal, I'm sure they would appreciate NVivo 10's developers addressing issues like these...
So, that's my wishlist for changes; here's hoping my PhD research does not finish before they are implemented :) ! As an NVivo user, what are your thoughts on changes you'd like to see? Please add them to the "comment" box below, ta!
Labels:
apple
,
nvivo
,
qualitative
,
research
,
software
Location: Cape Town, Western Cape Province, RSA
Cape Town, South Africa
Monday 21 November 2011
Three steps to get video files NVivo 9 ready
Written for researchers importing video into NVivo 9.
In my assistant researcher role for the Student ICT Access and Use project, I must ensure that the diverse video file formats and file sizes used to record student and researcher interviews are usable in NVivo 9.2. This is done in three steps; 1. consistent file name use, 2. compatible file conversion and 3. file re-sizing:
Step 1. Consistent file names
It is important for ease of reference and searchability that filenames are accurately and consistently named. For example, video files of the first interview were named according to the following format: (first name) interview (number = one) (date of interview DD Month YYYY).
- The choice of a first name protects the research subject's privacy; whilst not over-complicating the researcher's codings for subjects.
- Researchers conducted several interviews with each subject and these need to be distinguishable.
- Wherever possible, the date of interview should be added to ease citation for research articles.
Step 2. Video files must be compatible with NVivo 9
All file formats must be NVivo 9 compatible and I decided to use mp4 as the optimal format for compression. NVivo9 only imports .mpg, .mpeg, .mpe, .wmv, .avi, .qt, .mov and .mp4 files, so I converted all files that were not compatible (i.e. .mts and .flv) to mp4.
Step 3. Video file sizes must be less than 40 MB to be NVivo 9 import-friendly
Interestingly enough, videos created by the best resourced researchers posed the most problems for getting the files NVivo 9 ready: researchers at the University of Fort Hare and Rhodes University used their mobile phones to record the interviews that were in Windows Media Audio/Video File format and these were seldom over 20MB in size. This contrasted to up to 1GB in file sizes being generated by those "better" equipped!
The University of Cape Town (UCT) and Free State University (UFS) researchers used high fidelity settings to record their interviews. However, there was no reason for file sizes to be so large; high resolution video or high fidelity sound has no (or minimal) benefits for our analysis.
Changing filenames was easy, but steps 2 and 3 presented varied challenges and involved using different video compression software to encode the files at lower video resolution and audio fidelity. I have documented processes to overcome these challenges for other researchers, below:
Problem #1 with UCT interviews number one: WMV files too big.
Actions taken to reduce the size of WMV videos:
1. Did an internet search and found a guide at: http://www.ehow.com/how_5620360_reduce-wmv-file-size.html;
2. Downloaded AVC video convertor for Mac at http://www.any-video-converter.com/products/mac_video_converter_freeware and installed it;
3. Changed its output directory to match that of the import directory;
4. Selected Customised MP4 Movie as the output selection;
5. Selected one file to encode and export;
6. Defined the "profile" settings to reduce; the video frame rate to 8, video bitrate to 192, audio bit rate to 32 and sample rate to 8000. Changed audio channel to 1.
7. File was then encoded, reducing from 180 MB to 43 MB.
6. Imported the file as external source into NVivo 9 and it played successfully.
N.B. The "profile" definitions for the desired export are specified for each file individually; it was more efficient to work on one file at a time.
Problem #2 with UCT interviews number one: MTS file format is not NVivo 9 compatible and is too large
Actions taken to change the MTS file format and reduce it size:
1. Downloaded the free MTS convertor from http://www.mtsconverter.us/ and installed it on Windows 7.
2. Selected the export option: MPEG-4, 786 kbps, Audio: MP3, 96 kbps. This took 1hr and 20 minutes and the file size was reduced from 837 to148MB.
3. As this is a free version of the convertor, by default it added the AVS Video Convertor watermark to the middle of the image. Fixing this will cost $59 (before the 30th of November, 2011): the price of unlimited AVS4YOU.com software use.
4. I then used AVC video convertor to reduce the file's size.
5. MTS convertor allows for advanced encoding options, so I used the settings from #1.6 on a 1GB video and it was reduced to 52.4 MB. This process only took 25 minutes.
Problem #3 and #4 with UOFS interviews number one: Interviews in .FLV and .AVI format and too large
Actions taken to change the FLV and AVI file formats and reduce their file sizes:
1. I used Any Video Convertor to convert both file formats to MP4 and used the profile settings to reduce the file sizes.
The next step is to check that all the newly encoded files can be imported into NVivo 9; balancing file size with losses to video and audio quality... and that'll be the subject of my next blog post!
Saturday 5 November 2011
Want an individual, non-commercial, ZA domain? Fokof.
Forgive me for occasionally using my research blog as a blue-sky thinking space, whilst venting the frustrations of a South African wanting a better consumer experience; whether it's about television, buying music or the Apple third-world product experiences at first world prices (see iTunes Store, my exhibit "F"). Not only is writing these concerns a bit better than keeping such thoughts in my head to stress on, but I really do not have a better alternative; do forums exist in which customers can criticize companies for services they "should be" (not "are") delivering? Thought not! So, I feel justified in roping my research blog in as a stand-in soapbox...
My current concern is justifying the choice of the .co.za domain name for one's research blog in the absence of better, local alternatives for South African consumers. I have recently assisted Associate Professor Laura Czerniewicz (@Czernie) with hosting and publishing her Wordpress blog; the site is hosted by the environmentally- friendly GetGreen (who were very helpful with facilitating a speedy domain purchase, hosting and linkage).
The choices they could offer for a personal domain are shown on this screen grab:
Like all local Internet Service Providers (ISPs) I have used (or use), this list's options offer no second and first level domain combination appropriate for an individual researcher stressing the local context of her research:
.co.za =commercial, but local.
.com = commercial, american or international.
.net = commercial, international, generally used as an alternative to .com.
.org = non-profit organization, international.
.biz = commercial, international.
.info = informative internet resources, international.
.mobi = used for mobile devices, international.
.co = international, country code top level domain used by Columbia.
.co.uk = commercial, United Kingdom businesses.
.de = international, country code top level domain used by the Federal Republic of Germany.
.es = international, country code top level domain used by Spain.
.us = international, country code top level domain used by the United States of America.
.ca = international, country code top level domain used by Canada
.com.au = international, commercial domain used by Australia
.net.au = international, commercial domain used by Australia
.eu = international, country code top level domain used by the European Union
.in = international, country code top level domain used by India
.asia = international, domain sponsored by the DotAsia Organization
.me = country level domain used by Montenegro, with a few exceptions
As you can see, Laura chose the "lesser of two weevils" by selecting a co.za address to show local context, whilst also unavoidably signifying her blog as a "co.mmercial" (as I have also done, but via Gridhost).
This is a systemic problem that is not the ISPs' fault; http://en.wikipedia.org/wiki/.za shows that there are simply no domain addresses available for individuals to buy: for example, the academic second level domains (ac.za and school.za) are strictly for organizations (universities and schools, respectively), rather than individual staff...
It is frustrating that South African customers do not have any second domain choice (i.e. like name.za {an extension of .name domain}) to reflect their non-commercial, local context. Frankly, in a Web2.0 context where it has become very easy to publish online, this seems like a bad hangover from the predominately corporate publishing in the World Wide Web preceeding it :( ...
If you are also concerned about this omission, kindly add your comment below. This will help me to raise awareness of this problem online (and off). "Thank you", "Nkosi", "Baie Dankie".
My current concern is justifying the choice of the .co.za domain name for one's research blog in the absence of better, local alternatives for South African consumers. I have recently assisted Associate Professor Laura Czerniewicz (@Czernie) with hosting and publishing her Wordpress blog; the site is hosted by the environmentally- friendly GetGreen (who were very helpful with facilitating a speedy domain purchase, hosting and linkage).
The choices they could offer for a personal domain are shown on this screen grab:
Like all local Internet Service Providers (ISPs) I have used (or use), this list's options offer no second and first level domain combination appropriate for an individual researcher stressing the local context of her research:
.co.za =
As you can see, Laura chose the "lesser of two weevils" by selecting a co.za address to show local context, whilst also unavoidably signifying her blog as a "co.mmercial" (as I have also done, but via Gridhost).
This is a systemic problem that is not the ISPs' fault; http://en.wikipedia.org/wiki/.za shows that there are simply no domain addresses available for individuals to buy: for example, the academic second level domains (ac.za and school.za) are strictly for organizations (universities and schools, respectively), rather than individual staff...
It is frustrating that South African customers do not have any second domain choice (i.e. like name.za {an extension of .name domain}) to reflect their non-commercial, local context. Frankly, in a Web2.0 context where it has become very easy to publish online, this seems like a bad hangover from the predominately corporate publishing in the World Wide Web preceeding it :( ...
If you are also concerned about this omission, kindly add your comment below. This will help me to raise awareness of this problem online (and off). "Thank you", "Nkosi", "Baie Dankie".
Labels:
choices
,
customer
,
research
,
south_africa
,
web2.0
Location: Cape Town, Western Cape Province, RSA
Cape Town 8000, South Africa
Subscribe to:
Posts
(
Atom
)