Metadata you don't want to store in a music file

Here on the Music Library Management blog I tend to focus on making existing metadata more consistent and finding new metadata to make browsing and searching your music library more effective. This week I'll reverse that 'inclusive' approach and, instead, focus on what metadata shouldn't be in your music files.

Consider this a type of minimalism. By avoiding storing metadata you are lowering your future burden of maintaining excess metadata.

To summarise, there are three types of metadata that shouldn't make it into your music library: duplicate metadata, temporal metadata and user-specific metadata.

Duplicate metadata

The first category of metadata you don't want to store in your music files is duplicate metadata. Why? Well, it's because duplication is evil. Having duplicated metadata of different types increases your maintenance burden.

Let's start with the easiest and most obvious. User facing metadata are the type that you can see in a tag editor or music player. The most obvious duplication of these data are where there are duplicate fields and values. For example, two ALBUM_NAME fields with the value Thriller.

It's possible to also have duplicate fields with different values. For this type of duplication it depends what the field is. Regarding classification tags, for example, it may be valid to have multiple GENRE tags. However identification tags are unlikely to make much sense if duplicated; it's unlikely a given release has multiple ALBUM_NAMEs.

Least obvious is duplication between user facing metadata and the audio stream metadata. Most music file formats store metadata about the audio stream, such as the length of the stream or the bit rate used to encode it. Duplicating that in the user-facing metadata means you've more data to maintain. If you have differing values it may be difficult to tell which one is correct.

Temporal metadata

Temporal metadata is metadata with a short term lifespan. If you tag such metadata, this data is out of date as soon as you tag it, leaving you with old and potentially misleading data to maintain.

Examples of this type of metadata are record sales and Metacritic scores for a particular release. These data are subject to continual revision.

If you require such data, the best approach is to tag a universally agreed identifier for the music. That way, the identifier can be used to lookup the information you require at the time you need it. For example, you could tag with MusicBrainz ID and use that to find information. Sometimes, something as simple as the album name is good enough to find the data.

(Note that there is an intriguing feature suggestion for bliss to monitor and keep such data up to date... I suppose if bliss is doing this for you automatically the maintenance work is greatly reduced.)

User-specific metadata

The final type of metadata to avoid storing in music files is user-specific metadata. These are data like play counts which relate to a specific user, or subjective data likely to differ between different users of your music library, for example: ratings.

One can imagine approaches to tagging this data but it would be heavily customised and unlikely to be understood by different software. Furthermore you would have to document the formatting or syntax of the metadata such that it can be kept in good order and new items to be tagged with the same data are treated in the same way.


Can you think of any other metadata you don't like seeing in your music files?

Thanks to bartholmy for the image above.
tags: identification minimalism maintenance

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.