Playlist Shuffle 2.0
I had a thought in the shower this morning. I have a huge amount of music on my computer, ranging between pop, classical, rock, electronic, ska/emo, as well as a bunch I don't know how to classify. Sometimes, it's fun to add all of that music to one big playlist and then shuffle it a few times. You never know what you're going to hear next, except you probably have a pretty good idea that it's going to be music you like. (Otherwise, why keep it?) The problem is that shuffling is only fun for a short while. It's not that enjoyable to skip around between genres so chaotically.
Here's where feature vector interpolation comes in. A feature vector is a vector of feature ratings. For example, let's make a feature vector where the first element is tempo, the second is "electronicness", and the third is some measure of the complexity of the song. (Complexity is a loaded word: just assume for now that you're using my head's measure of complexity.) VNV Nation's Ascension or Saviour would rate high (near 1.0) on all of those features, so would be given a feature vector of <0.8, 0.9, 0.8>, say. Signaldrift would rate about <0.1, 1.0, 0.4>. Video game music would probably be around <0.5, 0.2, 0.6>. Of course, you could choose any number of features to rate your songs on. You would also need to define an additional weight vector that represents the "difficulty" of moving from one feature to another. In the above example, I would have a weight vector that looked like <0.5, 0.8, 0.3>. In English, that means that I don't want to switch all that often between electronic and nonelectronic music, but don't mind moving quickly around in the tempo and complexity dimensions.
Provided the algorithms exist for deriving feature ratings from audio data, you could make a more pleasing shuffled playlist. Instead of jumping around totally randomly in your playlist, pick k random songs from the playlist and switch to the one that minimizes the distance between weightVector * currentSong and weightVector * song[k]. The k parameter determines how "random" the playlist is. When set to 1, k is the same as a traditional shuffle algorithm. When set to the size of the playlist, you'll be listening to the same genre for days.
Now that we're on the topic of tune-ability... The feature vector is going to depend on both the listener and the playlist. For example, if you're only listening to VNV Nation in a given playlist, some of the features are all the same. In that case, you may want a different set of weights. I'm not sure how you'd (automatically?) get these weights or the preferred features.
If I had time, I'd like to try to implement this. But as it is, I'll just throw the idea out there and hope somebody gives it a shot. :)
p.s. This is the algorithm I use to make mix CDs, just described in a more mathematical, and therefore more programmable, way.
p.p.s. I should have googled first, eh? Turns out others have done some research in this area: Learning a Gaussian Process Prior for Automatically Generating Music Playlists. A Large-Scale Evaluation of Acoustic and Subjective Music Similarity Measures.
Expect another entry soon about heat, power, computing resources, and environmental issues in the future of computing.
follow on Mastodon
follow with Feedly
RSS for the rest
Oddly enough, I had an idea very, very similar to this. It also involved dimensions for bpm and things like content descriptors. So, for instance, you could avoid songs that have references to drugs with your straight-edge buddies (not that I have any of those, but you get the point). I also envisioned a python module that could handle these types of algorithms and the database required and let you programmatically do things like "play upbeat, party music for 4 hours, then lower the bpm by 15 per hour. at 6 hours, transition to winddown music". I was, however, hardpressed to come up with an idea for a UI that would make this usable. Although I guess it doesn't need to be that simplified, considering that the target audience would likely be music geeks and DJs. (They'd have to rate their entire music collection for the algo to even work.)
Having metadata would certainly make it easier to implement, but several orders of magnitude less usable. I can see maybe Apple implementing the algorithms necessary to automatically determine the necessary features of the music. It would certainly take a lot of math, but some work has been done in this area... it would make a good thesis or dissertation. :)
The only thing I could think of for a UI is like a movie editor, where you have time blocks. You could make a time block, then click on it and set what the range limits are, if it should transition between two ranges during that block, etc. Maybe some premade blocks for things like "speed up by 20 bpm", and of course, the ability to save blocks.