Andrew Ash

So in the tradition of every website, I’m going to be starting a blog to share some personal views with all of you, whoever you are. I’d imagine this will act in a combination of a research journal for my CBR research and some interesting papers on information security, machine learning, and music technology that I run into. When cool things come up in my classes as well (most likely Infosec or Databases), I’ll make sure to make a mention of that too. Just in general, I’ll try to keep things non-stagnant and moving in some sort of cohesive direction. We’ll see how that goes…

CBR website functioning

First up is some work on the CBR Research. We’ve gotten the first few similarity matrices done on a subset of our music library, just 500 songs for now. The similarity matrix is the actual product of the entire CBR algorithm: a complete graph with weighted edges and n vertices, where n is the number of songs. Each edge weight is the distance one song is from another. So theoretically, the vertex which is closest to another should be the song that is most similar to the first. Theoretically.

Part of what I’ve done over the past few weeks is to convert the matrix into a more usable form (row-column-distance 3-tuples) and import those into the MySQL database. Now we’re able to make queries that return the closest few tracks to any given seed song and actually listen to the music, always a good thing. Because without listening to it, you can’t tell if the algorithm is producing any sort of meaningful results!

Turns out the results are pretty good, especially for a very first run-through. Loud and fast songs are followed by other loud and fast songs, and slow, airy songs are followed by slow, airy songs. Excellent. Next up, we think that adding a tempo component to the algorithm will greatly improve results, and are looking at throwing bpm into the whole mix. Since it’s working solely on frequency distributions now (MFCCs, to be precise), adding tempo should be a good discriminatory attribute. Makes sense to me, so we’ll look towards putting that in soon too.

BPM submission interface

The problem is, though, that we need a way of calculating bpm algorithmically, which should be a relatively solved problem as far as Music Technology goes. Unfortunately, the first run-through of the default bpm detection function in the MIR Toolbox only got three of five bpm values correct, compared to our manual annotation. So to scale up to our 500 song subset, and later to the entire library? Three of five sure won’t do, so we’ve got some tweaking to do with the algorithm there, and the only way we can know if it’s working correctly or not is to have correctly-annotated songs… enter human intelligence!

I’ve added new tables to the db structure for users and bpm ratings, created the ability to login as a particular user, and label a particular song with a particular bpm. All with a relatively decent, but perfectly functional, interface. So the group of us in CBR Research will be annotating these few songs and working from there. That’s right, crowd-sourcing with a crowd of … 6. Fun stuff.

Ajax-y prettiness

I’m looking into a real-slick ajax interface for the submissions with jQuery and other fanciness, but it looks like just too much work for someone with much less javascript/jQuery experience than in PHP and MySQL. It’s working now, so if it ain’t broken don’t fix it! In the future, once this whole thing is opened up to the public, slickness will be a factor that we’ll need to consider, and the ajax experience certainly promotes that. I’ll have to work on it sometime, so might as well start immersing myself in the technology before there’s a deadline and it’s still early in the semester.

Expect to hear more about the work in future! I’ll be sincerely trying to keep this blog from falling into disrepair like so many seem to do. Things should be interesting, that’s for sure.