"The dark side", or, the limitations of walled gardens

A good proportion of the emails I receive to the blisshq inbox relate to how to deal with what I call "walled gardens". What I mean by this are the abstractions added by music players which are kept inside the player only, and not stored in the music library itself.

Examples are album artwork that is displayed when using the app, but copying the files elsewhere doesn't copy the art. Or where you have changed, say, the release date for an album, but that isn't propogated into your music library.

I smiled when I heard Hans Beekhuyzen phrase this "the dark side".

Why is this a bad thing? It's because your experience with new music players may be rather severely hampered when you open your files up in a new player and artwork, say, are missing. This doesn't encourage people to experiment with new setups. It also leads to a duplication of effort on the user's part - having to wade through another task of fetching album art, or fixing album artist tags, or whatever.

But hey, I have a tool for that.

The usual, and unusual, suspects

There's no doubt the chief offender is iTunes. iTunes is famously avaricious about metadata. When changing album artwork you need to be meticulous to ensure it is also stored inside your music files; simply allowing iTunes to download artwork automatically doesn't cut it. But it's not the only music player to do this.

The darling of audiophile music players, Roon, delivers a wealth of metadata unsurpassed by any other music player. The graph-like connections between musical entities are a joy to navigate and learn from.

But if you copy your underlying music library, don't expect that data to show up elsewhere. The target music player you copy to has to build their own code to identify, interpret and analyse your music library.

In newer versions of Roon, there's an export feature which will write back music files with some of the Roon metadata - chiefly more atomic items, not the full graph of musical entities that a given track, say, has.

In Roon's case, there are good reasons that the true wealth of metadata doesn't end up in your music files. That's because the data schemas within music files and your library at large are not really a good fit for the full extent of Roon's graph structured information.

Another good reason is that many people's tags are wrong, so why should Roon show potentially incorrect information?

To build this structure, Roon does something different to most music players, at least by default. Rather than use the existing tagging information for display, Roon uses it merely for identification. Once a given release is identified, its richer data on Roon's metadata servers can be shown to you. So really, you're looking at Roon's data layer, rather than the metadata in your own music library. (As I said: by default. There's also an option to show your tags.)

But still, there's no reason why simpler changes to your library shouldn't be propogated from Roon. "Export" can do this, but it's a shame it isn't done automatically and by default. And in the case of iTunes, there's definitely no reason album artwork shouldn't be saved embedded in your music files, for other players.

So music player programmers: please be a bit more sharing with your users' metadata!

Thanks to east_mountain for the image above.
tags: jukebox
blog comments powered by Disqus

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.