This post discusses some of my learning about connecting the Olympus VN-960PC digital voice recorder (DVR) to Windows and Linux. One unexpected discovery: audio quality was much higher in Linux. But more on that in a moment.
As described in a previous post, I had used various techniques to get versions of Windows to upload data from a VN-960PC, using the Olympus Digital Wave Player (DWP) software. I had found working solutions up through Windows 10. (Another post provides the Windows registry edits by which I redirected uploads, from DVR to PC, from the default folder on drive C to another folder on another drive.)
Then came Windows 10. As with Windows 7 and earlier versions, the situation (at least at the start) was that the operating system (OS) did not reliably recognize the DVR and upload from it. At this writing, I found that sometimes Windows 10 would recognize the DVR, but for some reason the DWP software did not run automatically. Sometimes, at least, I could overcome that by opening DWP and clicking its buttons to upload manually.
An alternative was to upload from the DVR to Linux. This post describes how I did that. So far, I had found that this approach had some advantages. One was reliability. Another was that the Linux approach brought the recordings over from the DVR to the PC in high quality, not in the reduced-quality .wav files that I got when uploading from the DVR to Windows. This approach was also fairly simple, at least for those who were willing and able to get to the point of opening a session of Terminal in Linux, though there was one potential complication discussed below.
There were two parts to this task: hardware and software. On the hardware side, I had to get the Linux computer to recognize the device. On the software side, I needed to run the Olympus Digital Wave Player software, or something like it, to work with the data coming in from the DVR.
Connecting the Hardware
The Linux solution, for this device (and apparently for other Olympus VN DVRs), seemed to be based on the odvr project, originally archived at Google Code but cloned to GitHub. The first step was to download the driver from one of those code locations. Among the various downloads listed at the Google Code site, I chose the most recent: odvr-0.1.5.tar.gz (September 27, 2009). Eventually I figured out that this would require me to compile source code, which I did not know how to do. I was willing to learn, but the original developer said that this most recent version included only small fixes, aside from “a raw download option” that might be of interest to “advanced users trying to decode PULCOD files found on VN-xx00PC devices.” Mine, a VN-960PC, was not a VN-xx00PC device, and anyway I had no clue about PULCOD files.
So I backed off and downloaded the older odvr_0.1.4.1_i386.deb — again, taking literally the developer’s statement that HQ audio was “still unsupported on VN-xx00PC models.” As soon as I clicked to download that file on my Linux Mint 17.3 KDE machine, the GDebi Package Installer opened and presented me with an Install Package button, which I clicked. According to Hellomoto, the next step was to connect the VN-960PC to the Linux machine via USB cable. Unlike the situation in Windows, of course, this was not going to cause the Olympus Digital Wave Player (DWP) software to pop up. Instead, I had to enter commands to see what was going on.
I opened Terminal and typed “odvr -l.” (Note: this post uses standard English punctuation. This means that, in that example, my command consisted of odvr -l, without the quotation marks or closing period. And by the way, that’s odvr followed by a lowercase -L, not by the number one.) That gave me an error message: “Failed to open Olympus device: couldn’t claim interface.” I tried again: “sudo odvr -l.” That worked. I got a listing of two files I had recorded onto the VN-960PC, with dates and other information about those files.
To get the list of available options, I typed “sudo odvr -h.” (I assumed “odvr” was short for “Olympus Digital Voice Recorder.”) (Note: sometimes, in this post, I write just “odvr,” without “sudo.” That is just for shorthand. If the command would not run without sudo, I added sudo.
In response to sudo odvr -h, I got the following list of odvr options:
-= Options =- -h : This help. -v : Print version. -d <folder> : Download all files in <folder>. -e : Download everything. -l : List all files. -x <folder> : Delete all recordings in <folder>. -c : Delete all recordings. -y : "yes" to all yes/no questions. -r : Reset the DVR. This may fix some sync issues. -D : Enable debug tracing.
I used “sudo odvr -e” to download (I would say upload) the files from the VN-960PC to the computer. Terminal said that it was downloading those two files. It didn’t say where. Terminal had opened in my Mint home folder (i.e., /home/ray), and that turned out to be where the files were.
This sort of command could seem to hang while the system was processing. That is, my odvr -e command would just sit there in Terminal until it was done. If I wanted a progress report, I would have to go to the Home folder and verify that more recordings were being uploaded. The odvr -e command would finally report its results when the uploading was done. As discussed below, in some contexts it would hang, but a simple Enter would move it along.
I noticed that, if I ran the -e command twice, it would not re-upload the files. Instead, I would get a message, for each file in the DVR, like this: “DA_8283.wav already exists. Skipping this file.” I also noticed, in that example, that the Linux and Windows uploads used a slightly different file naming format. In Windows, a file would be saved with a name like DW_A8283.wav, instead of the DA_8283.wav format in Linux. (The “A” indicated which folder it came from on the DVR: A, B, C, or S(chedule).)
At this point, I was rather sorry that I had not been using Linux to upload recordings from the VN-960PC for all these years. Despite the initial hassle of figuring out how to use it, this seemed very much simpler and more straightforward than the various problems I’d had with the VN-960PC in Windows.
On this particular try, I decided not to use “sudo odvr -c” to delete the recordings I had downloaded. Instead, I wanted to compare the results that I would get by connecting that same device, with those same recordings, to a Windows machine with the Olympus DWP software. There didn’t seem to be any way to unmount the device from the Linux machine, so I relied on the fact that it wasn’t doing anything at the moment, and simply unplugged it, and then plugged it into the Windows machine.
The DWP software popped up and I proceeded with the upload. Windows Explorer > right-click > Properties reported that the first file was 12,416 bytes and the second was 25,216 bytes. But the Linux machine said 37,816 and 72,890, respectively. Each of the two versions of the two recordings were only one or two seconds long; they all played OK, and I couldn’t tell any difference by listening to them. The README file included in the source code download (above) provided an explanation for the size difference. The full text of the Notes section of that README file was as follows:
Downloaded files are signed 16 bit PCM WAV files at the recorded sample rate. Olympus DVRs internally use a 3-bit differential PCM format with 14 bit resolution. Unfortunately, the Windows software converts from this format into lossy 4bit IMA ADPCM *and* it resamples. Files downloaded by odvr should be of higher quality than with the Windows software, but it does result in larger WAV files. It is recommended to recompress the WAV files with MP3, Vorbis, or Speex if file size is an issue.
Some programs may have difficulty playing or reading the odd bitrate WAV files. If they do, I recommend using “sox” to resample them into something more common, such as 44100hz.
Mac/PPC support is currently non-existent. There are several places in the odvr code that are endian sensitive, and the code hasn’t been tested on big-endian machines. PPC Mac/Linux/BSD developers are more than welcome to submit patches!
odvr may get out-of-sync with the attached DVR. Use “-r” to force a DVR reset when odvr runs. For example, “odvr -r -l” will reset and then list recordings.
Some Olympus DVRs have a high-quality encoding option (PULCOD). This encoding type is not directly supported and odvr will complain about it. Use a different quality level for your recordings or try the unsupported “sandec” program that that is included with this source. It requires wine, the wine development envornment, and a copy of “san_dec.dll.” Use odvr to download the raw files, then run sandec with the filename of the raw file.
Since odvr did not complain about the two files I uploaded, I assumed that my VN-960PC did not use the PULCOD type of encoding. To test whether the files were indeed of different levels of quality, I looked at Windows Explorer > right-click > Properties > Details tab. It said they were recorded at a bitrate of 88kbps. I did not (yet) have a Linux file manager with that Windows Explorer capability, so I right-clicked on the uploaded files in the Amarok audio player and chose Edit Track Details. There, I saw the a reported bitrate of 256 kbps. That explained why the Linux uploads were about three times as large. That probably also explained why the download process seemed slower, though it might also have been because Linux did not provide a download progress monitor that would inform me how each file’s download was progressing.
Olympus Digital Wave Player (DWP) Software
Having explored those matters, I plugged the VN-960PC back into the Linux machine and tried “sudo odvr -l” again. On a few different tries, sometimes that worked, and sometimes it produced an error — either the “Failed to open Olympus device: couldn’t claim interface” or “Couldn’t query model name: bulk write of 64 bytes to EP2 failed with code -2: error submitting URB: No such file or directory.” Unplugging and replugging the DVR once or twice fixed these errors. Possibly the problem there was that I should have used some kind of eject command to disconnect the DVR. (See below for other steps I tried, successfully, when the latter error recurred.)
When I first created this post, I compared the file dates and times reported by the foregoing commands, on the Linux machine, against the file information shown in the DWP program’s “Created Date” column in Windows. They reported the same dates and times, and agreed that the first of the two files had been created at 6:35 AM, three days earlier. But when I revisited these instructions a year and a half later, for some reason the result was not the same: now DWP said the Created Date was the same as the Transfer Date, so that numerous files uploaded from the DVR might show the same Created Date and Time in DWP. Possibly the explanation was that, in May 2016, I had done this on a Windows 7 system, whereas in October 2017, I was using Windows 10.
Like Windows Explorer, the Linux file manager (both Dolphin and Nemo) reported that the files were created at the time when they were uploaded from the VN-960PC to the computer, not when they were originally recorded. In Windows 7, I had used DWP with Aqua Deskperience, in an awkward manual procedure, to capture original creation time. In Windows 10 — at least when Windows 10 was not recognizing the DVR — it seemed that, as detailed below, I might have to capture, in Linux, the data reported by the “sudo odvr -l” or “sudo odvr-e” commands.
I searched in vain for a Linux version or alternative to the DWP software. Another possibility was to run DWP in Wine. Unfortunately, the Wine AppDB database yielded no relevant results in response to searches for “Olympus” or “Digital Wave Player.” The same was true for the CrossOver database.
It occurred to me that Wine might still run DWP, even if it wasn’t (yet) listed in the Wine database. As described in another post, I went through the process of installing Wine on this machine. With that in place, I was positioned to try to install the DWP software. I had downloaded Olympus Digital Wave Player 2.1.4.exe. I renamed it to be DWP.exe. As described in another post, I then endured an extensive struggle to try to get DWP to work via Wine. Despite others’ claims that they were successful, I was not. Until I could figure out how they had done it, if I wanted to use the Olympus Digital Wave Player software in Linux, I would have to do so in a Windows virtual machine.
Capturing DVR File Data in Linux
As noted above, I used three different odvr command options in Linux: one (-l) to get the file listing on the DVR, one (-e) to upload the files from the DVR to the PC, and finally one (-c) to erase the files from the DVR. Now that it appeared I would be using these commands regularly, I wanted to work out the best way to use them and to work with the information they produced.
The -l option produced information about each audio recording. The -e and -c options did not produce this information. The information provided by the -l option included, for each recording, its “slot” (i.e., its recording number, as reported on the DVR), its “file” (i.e., the part of the Windows/Linux filename represented by the numbers in e.g., DA_1396.wav), its length (in hh:mm:ss), the date and time when it was recorded, and its quality level (set to HQ by default on my DVR).
To reduce the number of steps involved, it was theoretically possible to run the three options at the same time — and also to capture, in a text file, the foregoing bits of information about each file provided by those two options. (At first, I thought the information from the -e option was unnecessary, but I would change my mind later.)
I say it was “theoretically” possible because, at least on my system, the -c option did not play well with the others. I wrote up the full story of the combined, single-command approach, and I have preserved that writeup in the following paragraphs. But I found it was better to exclude -c from the multipurpose command that I am about to describe, and instead to run odvr -c separately, as described below.
For my purposes, the ideal multipurpose odvr command would list detailed information about the files, capture that information in a text file, upload those files to the PC, and then erase those files from the DVR. That ideal command was as follows:
sudo odvr -l -e -c | tee -a DVR.log
When I tried it, that command saved the file information in a file called DVR.log in the Home (i.e., /home/ray) folder in Linux. If I ran the command two or more times (e.g., involving multiple DVRs), it just kept adding the new listings to the previous ones. As noted above, it would not re-upload files that it had already uploaded. This combined command would appear to hang, after the -e step, if the files had already been uploaded; hitting Enter would get it past that.
Of course, the command could be modified. Removing -l would skip the detailed file listing; removing -e would skip the upload; removing -c would cease to include file deletion as the last step in the command; removing -a would cause the previous DVR.log to be overwritten; I could use some output filename other than DVR.log; and I could skip creation of the output log altogether by omitting everything after -c. Note that odvr also had other options (above).
When I ran that combined command, Terminal would seem to hang after the last file had been uploaded. I could fix that by hitting Enter. That would bring me to the -c portion of the command. The -c option would not proceed automatically to delete the files in the DVR unless I added the -y option (above). Instead, at this point, having run the -l and -e options, it would say: “Going to delete all recordings. Are you sure (yes/no)?” If I wanted deletion at that point, it seemed I had to type exactly “yes.” Hitting Enter or even entering a “y” would apparently be treated as a no.
Unfortunately — on my machine, at least — “yes” wouldn’t work either. It did seem to run the command, but the command didn’t work. Instead, it resulted in an endless, hung string of “y” letters. Hitting Ctrl-C got me past that — but then I saw that the files had not been deleted. Possibly the “tee” addition to the combined command was to blame. For whatever reason, it seemed that I would have to run the -c part separately. So these were the two commands that I finally wound up with:
sudo odvr -l -e | tee -a DVR.log sudo odvr -c
When I ran those commands, I got my uploaded audio files and my DVR.log file, and the files were deleted from the DVR without further difficulty. I could repeat those commands, in Terminal, just by using the Up arrow key — the system remembered them even after a reboot. The Up arrow key would take me back through the most recently used commands, in reverse order. Alternately, I could save those commands in a text file, and copy and paste them from there in the future. It was tempting to write a script, and then just run that script, but the complication discussed below suggested that this might not be a good idea, as there could be problems requiring manual attention.
Renaming Files to Include File Data
So now I had a bunch of audio files from the DVR, and I had a DVR.log file containing information about those files. I wanted to use that information to rename those files. Specifically, I wanted to include the file creation date and time in the filename. To do this, I opened the DVR.log file in Excel (or another spreadsheet would probably also work about the same) and went through its text import wizard, so that all those items of information about these files would be broken out into separate rows and columns.
This was where the information from the odvr -e option could be useful. The -l output told me everything except the exact name of the actual file. I would need the -e output to tell me that, say, file 1803 was actually named DA_1802.wav. This was probably not crucial. My impression was that a single upload would not include identical numbers from two different folders. That is, for instance, there would not be a file DA_1803.wav and also a file DB_1803.wav. But it would still be best to have that information on hand for verification.
I used Excel to create file renaming commands that I could then combine into a batch file. Another post has details on technique. In this case, the basic idea was that I would use Notepad to create a .bat file, which Windows would run as an executable. Each line in the .bat file would contain a command to rename one file. Those commands would be in the form “ren oldfile.wav newfile.wav,” where “ren” was batch-speak for “rename.” Oldfile.wav would be the name of the uploaded file (e.g., DA_1802.wav). Newfile.wav would be the name that I preferred, like “2017-08-05 12.14.23 1802.wav.” The new filename would contain spaces, so I would include CHAR(34) at the start and end of the new filename, to tell Excel to insert quotation marks there. I wouldn’t want portions of that new filename to be shortened where there should be zeroes (e.g., 8 rather than 08, to represent August). To prevent that, the Excel formula would include REPT(0,2-LEN(A2))&A2, so that items in cell A2 shorter than 2 characters would have a prepended zero. As in that example, I would use ampersands (&) to tie together parts of the new filename. I would use “-” to insert a hyphen, and so forth. I could then copy my finished set of REN commands from the Excel spreadsheet to Renamer.bat and run it.
A Complication: Nearly Duplicate Filenames
There was one potential complication in the uploaded files. I had previously noticed that, sometimes, in Windows, the Olympus DVR would not name files using the customary format (e.g., DW_A5043.wav). Instead, it would add a suffix, typically a “_1” (e.g., DW_A5043_1.wav). A search provided no immediate explanation of this behavior.
Whatever the reason for that behavior, it seemed that the odvr program, in Linux, could not handle it. At least I think that must have been the explanation for an error message that I got, when running the first of the two odvr commands listed above (i.e., while uploading from the DVR to the PC). The error message was, “DA_5043.wav already exists. Skipping this file.”
Needless to say, I would want to be alert to that. It seemed I would have to manually review the screen or DVR.log file output and/or compare that output against the number of files actually uploaded, before giving the odvr -c command to erase the files on the DVR. This was why it would probably not be wise to combine both the odvr -e and the odvr -c commands in a single script that could run without user attention.
(It belatedly occurred to me that possibly odvr -r would help. I did not try that, this time around, but perhaps I would remember to try and document its effects later.)
In other words, to use a couple of hypothetical filenames, it seems that the DVR was able to tell the difference between DA_5043.wav and DA_5043_1.wav, but the odvr program was not. The odvr program would see that DA_5043.wav had already been uploaded from the DVR to the PC, and it would refuse to overwrite it by uploading DA_5043_1.wav — which it would apparently want to save as DA_5043.wav.
But possibly that was not what was happening. These were the lines of data actually reported for a sequence of uploaded files, taken directly from DVR.log. Note that DVR.log did not use ordinary hard returns at the ends of its lines. That is, Excel was able to tell where one data record ended and the next one began, but Notepad was not: it just ran them all together:
6 8389 00:01:23 10/07/2017 17:14:31 HQ
7 8390 00:00:05 10/07/2017 17:18:56 HQ
8 8391 00:00:15 10/07/2017 17:19:27 HQ
9 8392 00:00:32 10/07/2017 17:21:00 HQ
10 8389 00:00:05 10/07/2017 18:08:58 HQ
11 8390 00:00:18 10/07/2017 18:57:31 HQ
These were the last lines reported for folder B on the DVR. Strangely, when doing the actual upload, the error message appearing onscreen (e.g., “DB_8389.wav already exists”) occurred after the first, not the second, of the two entries for 8389 shown in this list (i.e., item 6, not item 10).
So there were some problems here. For one thing, the odvr -e command was not uploading all files. Also, the DVR.log file was not capturing all this information: it did not contain the “DB_8389.wav already exists” error — but it did contain information about both of the two DB_8389.wav files. So I had to figure out how to get all of the files off the DVR, before proceeding to the odvr -c command to wipe the DVR, and I also had to decide which file information lines applied to which files.
The key to the latter problem, I realized, was in the file information itself. I could compare the actual playing length, of the files that I did get, against the data listed in DVR.log. A Windows file manager (e.g., Windows Explorer, File Explorer) would provide the playing length: right-click on the file > Properties > Details tab > Length. This told me that, for the two files I had actually obtained from the DVR, the playing lengths were 1:22 for DB_8389.wav and 0:04 for DB_8390.wav. Each of those times was one second less than the times in DVR.log for the first of the two duplicates listed in DVR.log — but those times were much closer than the playing lengths for the second of each duplicate filename.
In short, I would have to see more examples to be sure, but it tentatively appeared that, for a given filename, the first lines listed in DVR.log would be for the files I actually got, and later lines for duplicate filenames would belong to the files that didn’t make it from the DVR to the PC. This was what one would expect; it just wasn’t clear, from the screen output, that this would be the actual outcome.
That left the problem of getting, from the DVR, the files that wouldn’t upload due to filename conflicts. The fastest solution seemed to be (a) listen to at least the start of those files that did make it to the PC (i.e., DB_8389.wav and DB_8390.wav), so that I would know what I was looking for; (b) go through the files in that folder (in this case, the B folder, matching the DB filenames) on the DVR; (c) delete, from the DVR, the two files that did make it from the DVR to the PC; and then (d) try the upload again.
I tried that. I listened to DB_8389.wav and DB_8390.wav on the PC; I listened to the files in folder B on the DVR; and I used the controls on the DVR to manually delete its copies of the DB_8389.wav and DB_8390.wav files that had made it to the PC. I also deleted those two files from the Home/ray folder on the Linux system, along with DVR.log.
The rest of the uploaded files were still in that folder, so I expected to get “already exists” errors for all except the two that hadn’t previously survived the upload. Instead, I got the “couldn’t query model name” error mentioned above. I tried running the command again after a reboot, but it was still there. I tried shutting down the system for a few minutes and then trying again, this time not unplugging the DVR before shutdown, and also making sure the DVR was set to folder A instead of B before I plugged in the USB cable. I also allowed a few seconds between connecting the USB cable and running the command. Another possibility: close Terminal before unplugging the DVR. Anyway, something in that magic worked: the command ran.
The onscreen output reported, as hoped, that only those two files (i.e., DB_8389.wav and DB_8390.wav) were downloaded. Nemo (the Linux file explorer) didn’t provide a Length datum in its Properties output, so I brought them over to the Windows PC, via USB thumb drive, and looked there. Windows reported lengths of 0:05 and 0:17 — again, one second less than the times in DVR.log. So it appeared that this procedure had succeeded. I added “a” and “b” suffixes to the filenames for the two DB_8389.wav and DB_8390.wav files, so that both sets could coexist in the same folder. I confirmed that the number of files that had made it to that folder was equal to the number of files on the DVR. So at that point I felt I could go ahead and run odvr -c to wipe the DVR.
To sum up, this section describes a situation where the DVR assigned filenames, to two different recordings, that the DVR and the Windows DWP software could tell apart, but the Linux odvr software couldn’t. The problem was visible onscreen, as the upload was proceeding; it was evident from the total numbers of files uploaded (i.e., one set of duplicates didn’t make it from the DVR to the Linux PC); and it was evident in DVR.log, especially when examined in Excel (i.e., there were duplicates for two of the listed filenames). The solution was as follows:
- To make things a little simpler, leave copies of the uploaded files in the Linux PC’s Home/user folder until the whole process is done.
- Use some tool (e.g., Windows File Explorer > Properties > Details) to identify the lengths of the duplicate files that actually made it from the DVR to the PC.
- Rename those files by adding the letter “a” to the ends of their filenames (both in File Explorer and in the Excel spreadsheet containing the information from DVR.log).
- Listen to the start of the duplicative files that made it to the PC.
- Find and delete those files from the DVR, and also from the previously uploaded set in the Linux PC’s Home/user folder.
- Retry the download. In that retry, only the files that didn’t make it previously should make it now.
- Rename the newly uploaded files — the ones that didn’t make it previously — by adding “b” to the ends of their filenames.
- Verify that the total number of files uploaded to the PC equals the total number of recordings on the DVR.
At that point, it seemed OK to wipe the DVR — unless, of course, some other unanticipated complication lurked.
Going the Other Way: Moving Files from PC to VN-960PC
At a later date, I had a situation in which I wanted to move .wav files from the computer to the VN-960PC DVR. I posted a question on that, but at this writing I had not yet received a useful answer. In case that webpage dries up, here is the part that seemed particularly important:
I am belatedly realizing that, when the DVR is connected to the computer via USB, Windows does not register its presence in Explorer, as would happen if I had instead plugged in a USB drive. (I think that was also true in Linux file managers, though I’m not sure I ever looked into that specifically.) In that case, maybe the preliminary question is, is there a way to make Windows more formally aware of a memory device that is presently accessible only through proprietary software?