Classical Convert

Score Processing, Part I

Dear regular readers, you know that fantastic idea I had last week about automatically analyzing scores? Well, it’s a bit more complicated than (the royal) we had hoped. Of course. Stuff like that always is. It’s the same with lab research: when I look back at the sum of the previous year’s work, it is frickin’ astounding how much effort I have put in, in order to advance such a tiny distance. Oh woe, woe is we.

But enough of the whining. Here is why it doesn’t work:

The top line is the first violin part from… well… any guesses? The bottom, in red, is the average amount of “stuff” happening at each point in time. Specifically, it’s a measure of the average pixel intensity — which is why it dips down when notes are being played, because there are more black pixels, which have zero intensity. If this system worked as well as I would like then every note would be associated with a dip in the red line. That does in fact happen, but the problem is that all the other junk also makes it dip, like those f’s and accidentals.

So I’m going to have to implement something a bit more sneaky, like a normalized cross-correlation. Instead of just looking at blackness, an NCC would search through the score for stuff that “looks like” a note. Unfortunately it’s a lot slower, and more difficult to program.