Batch Verifying or Validating Scattered WAV Files

I had previously looked for ways to test MP3 files.  Now I wanted to test some WAVs.  This post describes one approach that seemed to work.

Initially, I tried using IrfanView, before rediscovering that IrfanView did not do audio file conversions.  After some searching around, I tried the command-line option in Boxoft WAV to MP3 Converter (freeware).  This looked promising.

To run the Boxoft converter, I used this syntax:

WavToMp3Cmd "D:\Folder\File Name.wav" -O"D:\Test\Output Filename.mp3"

This syntax seemed a little awkward, because (as shown) there was no space after the -O. (That's an oh, not a zero.)  Of course, I had to use quotation marks, as shown, because I had spaces in the folder and/or file names.  I had to run this command in the folder where the Boxoft program was installed (i.e., where WavToMp3Cmd.exe was located). That is, I had to run my batch file from there. That installation folder, on my x64 system, was C:\Program Files (x86)\Boxoft Wav to MP3 (freeware).

The foregoing command was pretty bare-bones.  I would have had to add more parameters, as described in the Boxoft help file, if I had wanted to produce high-quality output MP3s.  I was just creating the output MP3s to see whether the input WAVs were valid.  I would be deleting the output MP3s when the test was done.

I wasn't sure how the Boxoft converter would deal with a flawed WAV file.  To find out, I created a TXT file, changed its extension to WAV, and ran the foregoing command on it.  Boxoft produced an unplayable Test.mp3 in the output folder, so in that sense the test failed:  I would have preferred that it would not produce junk files.  Fortunately, Boxoft did register an error message on the command line. I captured that error to a log file by adding some stuff to the foregoing command.  That command now looked like this:

WavToMp3Cmd "D:\Folder\File Name.wav" -O"D:\Test\Output Filename.mp3" >> D:\Test\Log.txt

That was all on one command line.  Now I would have a Log.txt file that would capture error messages produced by the converter.  The next step was to work up my list of commands.  My WAV files were scattered in various folders around the computer, so as described in more detail in another post (and in several prior posts listed at the start of that one), I used a DIR command to identify the files I wanted to test (in this case, they were of the form 2010*.wav), and then I used Microsoft Excel formulas to create the relevant commands.  So now, for each file to be tested, I had an Excel row containing something like the command shown above.  I copied all those commands into a text file in Notepad, renamed that file's extension to be BAT (so that it would run), saved it in the Boxoft folder as noted above, and ran it.

In 10 or 15 minutes, the batch file was done; I had tested about 2,800 WAVs.  I verified that the number of output MP3 files equaled the number of input WAV files.  I wasn't sure how Log.txt would register errors, so I copied and pasted the entire log into a Microsoft Word document and reduced its size by doing global search-and-replace operations to remove the lines pertaining to the Title, Artist, and other settings that didn't matter to me.  (Word's special character to remove line breaks was ^p.)  I changed the remaining output to fit on one line (that is, I changed "^pSave to" to be just "Save to"), so that the file name and the result (e.g., "Success") would all be on one line.  I pasted this remaining text into Excel, did a FIND for lines containing "Success," and sorted the list according to whether "Success" appeared.  There was only one non-Success line.  It said, "Set the error bit rate. Please run WavToMp3Cmd to get help."  In the Word doc, I searched for that text.  I played the original WAV file whose name appeared just before that text.  It played OK.  I looked for the output MP3 file of similar name.  It wasn't there.  In this case, Boxoft hadn't created the failing file.  But then why did my file count agree?  Oh, of course, because the Log.txt file was in the output folder.  I wasn't sure why Boxoft had balked at the input WAV; but now that I had manually tested it and found it was OK, I didn't really care.

It occurred to me that Boxoft had produced an error when confronted with the obvious impossibility of converting a TXT file to MP3; but what about if some of the input files were mislabeled as WAVs when, in fact, they were MP3s or WMAs or some other kind of audio file?  I wasn't sure whether Boxoft would produce an error message or warning for such files.  I ran a version of the foregoing command on an input WMA, not renamed to WAV.  That crashed Boxoft.  I tried again after renaming the WMA to WAV.  That crashed Boxoft too.  I also tried with an input MP3.  Same results:  crashes.  I re-checked that the command did work with a genuine input WAV.  So apparently Boxoft would have crashed if my list of WAVs to be tested had contained an MP3 or WMA that was accidentally misnamed as a WAV.

To sum up, it seemed that the Boxoft command line converter, using a command with syntax shown above, was able to test large numbers of WAV files by converting them to MP3s, with error messages captured in a log file.