Four truths about large music collections
This article is a guest post by Dan Gravell who runs the Music Library Management blog.
We all want to build large music collections, right? The more music we have at hand, the more choice we can offer listeners and the more flexibility we have to build engaging playlists.
But large music collections come with costs
I’m not talking about the financial costs of purchasing larger hard drives, or storing the music in the cloud. I’m talking about the effort of organizing and categorising a music library so that it’s as usable to you as possible. That means it can be searching, arranged, music can be easily queued and scheduled, and when playing the playback experience is informing, beautiful and engaging for your listeners.
The last thing you want is a music library that is impressive in its size, but unwieldy in its organization; becoming more of an impediment than a strength.
Since starting the bliss project in 2009 I’ve encountered a lot of very large music collections. What truths do each collection exhibit, and how can you work with your music library to ensure both a usable library, and a secure one?
Mo’ music mo’ problems
The more music you add to a music library, the more complex it gets. That might seem strange; you’re just adding a few tracks, maybe an entire album or single. It’s just a bit more, right?
As far as the music is concerned, that’s right. But in music library management, there’s more to consider. Each album you have, each track in your library, can be categorised in different ways. A track could be assigned a genre, for instance. An album can be assigned a release year.
Each of these pieces of information is known as metadata and, in a self stored music library consisting of MP3s, FLACs, AIFFs, WAVs or whatever, are stored inside the music files in tags. They’re generally simple textual pieces of data in each file… ALBUM=OK Computer.
Those pieces of data have costs, because they have to be maintained. Genre is a particularly pathological case; it is very subjective, not only in terms of how one judges which genre a track belongs to, but also the set of genres you want to consider. Having hundreds of genres in a music library is not helpful to browse and search it, so enforcing a narrower set of genres is helpful. But then, each album added has to comply with that set, existing tracks have to be re-assigned… and the more music you have, the harder that becomes.
You might think the release year of an album is more immutable and objective. That’s right to a certain extent, but maybe the release date for an album isn’t what your listeners want to see for, say, a remastered set of tracks; maybe they want to see the original recording or release date. Bob Dylan’s The Times They Are A-Changin’ was remixed in stereo and re-released in 2015. But would your listeners want to see The Times They Are A-Changin’ (2015) when reviewing your “Now Playing” text?
Again, if you decide to change how this information is stored, the more music you have, the bigger a job this is.
There are two principle ways to avoid these issues. The first is to embrace minimalism. The second is to use automated tools to help you fix issues when you have them.
Embracing minimalism means only storing metadata which you know is required, especially when that metadata is subjective. Think of it this way: aim to store identification and structural information, but be more guarded about classification information.
There are plenty of software tools that will work with a self-stored music collection in batch mode to fix items. Free tagging tools include MP3tag and Kid3 for Mac users. You can set these up to perform batch operations. And then there’s my own tool, bliss, which operates in a slightly different way, enabling you to define what rules your music library should follow, rather than focusing on going straight to editing the music files.
Consistency becomes more important
The larger the music library, the more chances that its organization can have inconsistencies introduced. Why is this a problem? Because of the two things your music library must interface with: software and, most importantly, your listeners!
Software can be fickle when your music library is concerned. Some music players enforce restrictions; music file formats that aren’t supported, album art sizes that it won’t display (and maybe won’t show to your listeners), support for internationalised alphabets, and more.
We’ve already described how, in a large music library, it’s a big job, often not feasible, to go through the entire library and change the organization such that these restrictions are obeyed. But equally, when you do perform a large edit like this, the edit needs to be pervasive across the library otherwise you will still encounter the same restrictions.
That leads us back to our listeners. Humans are brilliant pattern matchers and will spot inconsistencies a mile away. If you display artist names with slight variations for different tracks, for example R.E.M. and REM, your listeners will spot these. Not the end of the world (as we know it – sorry, couldn’t resist) but it may look a little unprofessional.
There will be damage
Now it gets dark. If you have a valuable thing like a music library, and it forms the basis of your radio station, you have to… have to… invest in securing it.
Threats come from different sources, not always intentional. Obviously, you could get a virus or a malicious piece of software, or you could have your music library physically stolen from your premises. But less obviously, you could fall victim to buggy software, or a simple misplaced press of the [Delete] key.
It’s best to consider how to approach this in two ways: how to recover from a disaster, and how to prevent it. If you have no disaster recovery procedures in place, I strongly suggest you start there.
The simplest and most solution for disaster recovery is redundancy; i.e. backups. Backing up your library automatically, testing the backups and knowing how to restore is something you should do, period. You can get software to do it for you, and once set up it needn’t take a lot of your time.
Preventing damage can be achieved through a number of approaches. Authenticating access to your music library is one way, using usernames and passwords, as is authorising who can do what to your music library. For example, you might expose your music library in a read-only mode to software, to ensure even if the software was unwittingly buggy, it wouldn’t be able to make changes to your library.
It’s a marathon, not a sprint
Groan. A tired cliché I know, but one that is fitting.
Inevitably, building a music library is a long term pursuit. New music is released all the time, and so your music library becomes an evolving beast.
By investing in your music collection, not with (much) money, but with thought and consideration as to what tools you should use, how to secure the library, and how best to organize it, you can ensure your library is both impressively large and maintainable over the long term.
I hope you’ve found something of interest or insight in these thoughts. Feel free to drop a comment at blisshq.com, tweet or facebook me or send an email, and I’ll get back to you!
