I listen to music while I'm working. I like listening to good music, and I like it when the music flows from one song to the next. I don't like (for the most part) hearing the same song twice in the same day.

However, I'm too lazy to build playlists that match above criteria by hand. I usually end up half-heartedly tuning the random profiles on Obsequieum's DJ Random. For the most part this works, but it builds up a low-grade frustration that there must be a better way.

Indeed there are a few better ways. The ones that come to mind are ranking systems, which enhance the DJ Random idea with weightings, and audioscrobbler, which relies on the assumption that given free choice, statistically people will choose something good. I like the audioscrobbler idea, except for the unfortunate problem that you still fall victim to other people's poor tagging. Musicbrainz is a good solution to this problem, but it seems not everyone is as enthusiastic about correct metadata as I am.

I would like to say that there is nothing out there that does what I want. The reality is that I'm too lazy to look, and too picky to use something good enough. Mostly I wanted to hack something together.

So I did. It is still pretty rough around the edges, but I built a playlist generator based on extracting features. It extracts features from the first and last 20 seconds of a track, finding the closest few track "heads" to a particular "tail", and then using a distance weighted random selection to pick the next track. There are a few other restrictions -- the markov chainer won't pick tracks that are too far away an initial track. Otherwise you'll end up with a playlist that starts with Ani DiFranco, and ends up with In Flames.

The markov chainer could use some work, but it does a good enough job for me to use it all of the time. You can see some of the results here.

Here are the pieces used to build the playlist generator

• MADplay for decoding.
• HTK for extracting MFCCs.
• treeq for building the feature extraction decision tree, classifying mfccs as features, and then counting the features in a track.
• Tree::M for storing each track as a point in n-space, where the coordinates is determined by the feature counts returned by treeq.

There is still lots of work to be done. The decision tree can be better tuned to extract better features. I think I'll try and optimze the decision tree building process to produce a tree that maximizes the distances between distinct tracks, and minimizes the differences between identical tracks. Then start collecting data, and plot results.

On a more technical level, HTK should probably be replaces with something more specialized (and free). The MTree could probably be replaced by an RTree, or a GiST..

This technique turns out to be quite adept at finding duplicate tracks. A furthur application of this process would be track identification. Combined with something like Musicbrainz, this would make tagging tracks a lot eaiser..