A few weeks back I was doing a recording for a buddy of mine and unplugged my Edirol R-09HR sound recorder… and for whatever reason it powered off immediately. Yes there were batteries in it but it decided that it just wanted shut off immediately. The problem is that it was still recording a file. Making things a tad bit more annoying, it corrupted the WAV file it was writing. None of the tools that I had wanted to read the wave file because the sizes that are supposed to be written into the header never got written.
I ended up doing some research on the WAV file format and wrote a utility that sets the two lengths that are required in the header based on the file length. If anyone else needs this send me an email and I’ll send you a copy (to use at your own risk.) The utility does at least verify that the file is a WAV file — but it could still be pretty destructive. It would be really nice if the audio editing software would just allow you to fix this on the fly when you open it since it has to be a fairly common problem when the recording is interrupted. Of course, the tools don’t do that. The fix that I’m doing in this program is painfully simple. I’m comparing the length of the file and using that to write out the header values. Every one of the tools that I tried to use, including my preferred audio editor Sound Forge, refused to fix the file. There were tons of tools that claimed to fix WAV files but the “obvious fix” for the header wasn’t one of the supported fixes.
For me this was an annoyance. It was something that took me a few hours to fix. (I had to remember my binary file reading skills and find an accurate format for the WAV file.) However, it occurred to me that someone who wasn’t a developer — and a developer with a background in reading binary files — would have been completely stuck. Something that is relatively easy would be a seemingly insurmountable challenge. The good news is that the invention of the Internet is making it easier to address these issues (with a bit of luck someone with a corrupt WAV file will be able to email me and I can send them the fix tool.)
In a strikingly similar situation I wrote a tool a few weeks ago for a good friend of mine. He had been using Windows Media Player to index his music files. He plays the part of a DJ occasionally and needed a print out that he could hand party goers in an attempt to help them pick a song that he had. Strangely, Media Player doesn’t have a way to print out a list of the songs that it has in its index. This was painful enough for him that he was willing to pay my hourly rate to build him a tool to get the data out — and he knows what my hourly rate is. So I needed a distraction from some of the other stuff I was doing so I picked up the Windows Media Player 9 Series SDK. 45 minutes later I had a working tool that would create a CSV file from all of the data in the Windows Media Player Library. To be clear, it’s not what I would call commercial grade software. It requires that you run as an administrator. It doesn’t filter out the library for you — the library contains stuff other than music like photos. It also dumps literally every field of data in the library — including a lot of duplicate data. However, 45 minutes of work removed the essential barrier that he was having to being able to have a listing to take to his gigs. (If you want this tool email me and I’ll get it to you — the same thing applies here. Use at your own risk and there is no support.)
My point is to say that a few hours of development can make the insurmountable seem possible. There are things that just simply can’t be done without writing a little bit of code — and neither of these utilities would be considered good from a software development perspective. They’re hacks. They’re not elegant — however, they get the job done. Sometimes developers get caught up in creating the big solutions — the massive architectures — and we forget that any solution is sufficient. I’m going to be thinking about that “less is more” thing for a while…