First of all, I may have been neglecting this blog, but I haven’t been neglecting NusachDB, a growing collection of Jewish liturgical tunes. It’s up to almost 1000 tunes, though with all the double-counting (for various reasons that I don’t want to get into right now), it’s probably about 400 or so unique ones. While working on NusachDB, which involves transcribing tunes found on the internet, I came across some, well, awful design. One site has its recordings stored as Flash applets, which is annoying enough, but it doesn’t actually have any controls. You can press play or you can press stop; pressing play starts the recording from the beginning and pressing stop stops it. No pause. No way to rewind. As you can guess, transcribing this is extremely annoying and an enormous waste of time. Well, a bit of digging (by which I mean just looking at the source) shows that these are .swf files, which I can download. Great, that’s a good first step! But how do I retrieve the music inside?
At first I figured it was some sort of bundle, like .app, with various resources (like the music I needed) inside. Finder doesn’t seem to think so. I googled it, to no avail. There are plenty of commercial programs that will do this, some costing $100. $100 for sound conversion? Sounds like a scam. This is a simple enough task that it shouldn’t take a program that costs more than $5 to do, so it smells like someone is trying to make some very cheap money out of this. I might as well try it myself. The Wikipedia page doesn’t have anything useful on the file specification, but maybe I can open it as a text file or something just to see what would happen. Probably nothing interesting, but… wait, I right-click the file to open it in Sublime, but one of the programs listed in the menu is The Unarchiver?
Turns out .swf is an archive format after all. The Unarchiver opens it with no problems. So yeah, don’t be an idiot and buy a program to open a downloaded Flash applet, because it’s simply not necessary and might well be an enormous waste of money.
Secondly, a recent Chrome update broke the Microtonal Synthesizer. Very sad. I got emails about it — at least it still worked in Safari, which is usually a few versions behind Chrome. Well, had some time yesterday to try to debug this; obviously there was a change in the API that broke AudioLib.js, the underlying sound library I use for the synth. (One of these days I’ll make my own, I suppose.) The synth is supposed to use WebAudio, but it was using the PCM fallback, which is terrible in every way. I couldn’t believe that Chrome decided to stop supporting WebAudio, so it must be something else. Unfortunately, it also wasn’t obvious where the code chose the right framework to use. It took a while, but eventually I found the switch — a for loop over the available audio frameworks that enclosed the creation of the audio object in a try block. If object creation failed, it would move on; if it succeeded, it would return the new object. This of course relies on an exception being thrown in case of failure. Not sure if it’s the best design. But it’s interesting that there was no catch block to deal with the exception. So I decided to log it instead, and the culprit was soon discovered: a method of the AudioContext that was renamed because who needs backwards compatibility anyway? It was throwing an exception because the method was undefined, so it was causing the audio object creation to fail and the for loop to go to the next iteration until the PCM fallback succeeded. That’s a simple enough fix — call the correct name of the method — and hey, now the synth works again! Check it out. There’s nothing new there yet, but it still works, so that’s something!