Since giving up mpd a couple of years ago, I’ve been trying out various music players, and I have yet to find one I really like. Since then, I’ve tried out first xmms2, then Rhythmbox and Banshee, in that order. While I especially liked xmms2’s collections, I found that music actually is something best visualised in a way a command line interface really can’t (two words: album art).
Rhythmbox and Banshee, however, are both seriously bug-ridden and unstable, both of them (I still can’t get any of them to transfer music to my mobile phone, and both continuously hangs and/or crashes randomly). But that’s a transitory problem (at least I tell myself it is). Much worse is the fact that they both visualise music very clumsily.
Ever since I started using notmuch and it’s Gmail-inspired tagging approach to sorting mail, I’ve been thinking I’d like to do the same with my music. The only problem is that music and arbitrary meta data really don’t mix well. Therefore, in this entry I’m going to draw the lines for a slightly different mode of thinking about digital music management.
Dualism never works (ask Descartes)
Most music organisers today are built around a database as well as the file system, because not all relevant (meta) data about music can be stored in the actual music containers, and even if that were possible, you probably wouldn’t want to, for both technical and social reasons. Constantly writing data to lots of files is (but I’m guessing here) probably quite slow.
So the first question about the synchronisation of your actual music files and your music organiser becomes what, exactly, to synchronise. The various players I’ve tried act differently here: xmms2, for instance, doesn’t even sync changes in tags (please note: I’m going to use »tags« for id3/ogg comment-style tags and »labels« for Gmail-style tags from now on to avoid confusion as much as possible, even though I know that »label« is actually a reserved keyword in the music domain as well).
The next question is how to handle changes to the music library outside of the music player. The typical case, of course, is adding or removing music, but we can also imagine changing meta data through an external editor (when is this updated in the database? I’d bet different managers do this differently) or even moving actual files around.
What I’m getting at here is that you obviously have multiple entry points for altering the state of your music database with these systems, something that’s almost guaranteed to give you unexpected behaviour and/or bugs (what happens if you just move a file?). The solution? Ditch either the files or the database. And since I believe we started using databases for a reason (faster search, ability to store more data), I’m going to suggest ditching the files.
That way, you can harness all of data base theory’s solution to these common problems (atomicity, consistency and so on), and make sure all your changes are consistent. You also get solutions to most other problems I’m naming further on in this entry for free.
Also, choosing a flat file-based approach has some problems with sorting. Most of the time you’d probably want to sort your music in a tree from artist to album to song. However, how do you handle albums with songs by multiple artists? You could, of course, use symbolic links to make sure the relevant songs appear both as /artist/album/song, AND as /various artist/album/song, but that would be a tricky to manage (and spell disaster if you’re using a database-based player).
TL;DR: Upholding the dualism between music files on one hand, and the database on the other is expensive, and we should ditch the files and keep all our music in a database.
We’ve got identity all mixed up in digital music
Here’s a riddle: when are two songs the same? I’m quite sure your answer isn’t »when they are digitally encoded exactly the same and has identical meta data«. However, this is your music organiser’s.
I think that basically, we’ve been doing identity for songs wrong ever since we started storing music digitally. At the very least, meta data shouldn’t matter as long as the actual data is identical. But I’d like to go a step further here, and suggest that at least theoretically we should be able to treat two identical recordings of a song on two different albums as the same song.
At least our music organiser should have the possibility of having the same song showing up on different albums, since two albums could easily contain the same song (imagine a one-hit-wonder being both on a »best of« collection as w ell as on its original album). Of course, we may be audiophiles and require cue sheets that precisely punctuates all songs with the exactly correct amount of silence. But this, really, is also meta data, and not really related to the actual identity of the song. It’s the same song, just with more silence.
TL;DR: Identity in songs, we’re doing it wrong. The fact that a song participates in an album or in a collection is data about the song, not a property intrinsic to the song itself.
Arbitrary (but relevant) meta data should apply to music as well
In Banshee, I have a play list called »rain«, collecting a bunch of songs that are about/remind me of rain. However, on a second thought this would seem a rather backwards way of organising my music. I have externalised the fact about a bunch of songs that they are about rain to a play list. That is, the songs aren’t about rain (according to the database), the list is.
But the property of being about rain is a property of the individual songs, not the list. And using a list to capture that really misses something (not to mention that I can’t easily search for that property in my music library). Therefore, our music collection should allow a system of Gmail-style labels to store information about our music.
This way, we can set up our play lists as smart play lists, and have them add songs about »rain« or »cyberpunk« themselves. Of course, one of the positive emergent effects of this is the ability for us to keep an In-box for our yet-unlistened music.
Organiser ≠ player, a note for those of a cloudy disposition
An important aspect of keeping our music in a database rather than in a set of files is the fact that the organiser part of our music infrastructure becomes logically separate from the music playing part. Playing back music becomes a matter of reporting to the back-end which track you are playing (and are going to play), and getting the actual music data streamed back to you.
This means that we could easily have multiple player front-ends to our database back-end, and that these can even run simultaneously (but don’t tell RIAA about this, please). And some of these front-ends could be HTML5-based streaming web apps, or (for that matter) music sync clients on your phone. That way, you could run your music database on your Freedom box and have access to your very own Spotify – all the time.