Your music library and music players are separate

So there's this thing called abstraction which is used a lot in computer science. It's a way of making a complex subject more understandable by hiding details of the underlying complexity, sometimes presenting the subject in entirely different ways.

I'm bringing it up because it's a topic in music library management that I think any collector should be aware of. The reason you need to be aware is that abstraction is not a free lunch.

Abstraction is a handy tool, but there's a problem that springs to mind. The first is that abstractions can sometimes be leaky. That is, the complexity of the details below will inevitably 'leak' and be exposed to the actor that the abstraction was designed to 'protect'.

The results can be various; a lack of understanding, an inability to understand how to change a system such that it can be used in different ways (be flexibly), or alternatively a leakage such that too much complexity is exposed to the user and they give up trying to understand the system.

This is the reality of software engineering; how to achieve an appropriate level of abstraction.

The question recurs in music library management in the relationship between music player and your underlying music library. For a newcomer to music libraries, these two entities can appear one-and-the-same. Many people talk about their "iTunes music" and to many performing library management tasks means using a music player to perform the task.

The trouble is that a music player itself builds a layer of abstraction over your music library, and sometimes performing library management tasks may actually mean you are performing tasks on the abstraction layer rather than your music library underneath.

Perhaps the most common example I see of that is album artwork management in iTunes. It's well known that iTunes is pretty... possessive about its artwork. To the unwary, you could be changing artwork only to find that when you share the library elsewhere; on your phone, to a new hi-fi system, that artwork doesn't appear.

Roon takes abstraction almost to its natural conclusion by combining your music files, and streamed files, with very rich metadata. And yet that metadata can only be partly populated back into your music files. So come the day you stop your Roon subscription, or some other calamity happens, you'll be without that (fair enough, some may say).

The unfortunately thing is that, because the abstraction layers are coded into the apps we use, the only way we know how to avoid potential leaky abstractions is to understand the way the music player works. This is a non-trivial demand to place on a user, but I think it's just one of the costs of being a savvy music library curator.

Remember: your music player is not your music library.

Thanks to Mike Wilson for the image above.
tags: thought

The Music Library Management blog

Dan Gravell

I'm Dan, the founder and programmer of bliss. I write bliss to solve my own problems with my digital music collection.