Mind your FLAC ALBUMARTISTs
August 13, 2013 in digital music by Dan Gravell
ALBUM ARTIST tags are a great way of describing the canonical artist for a release, rather than an individual song. This is useful because it provides a means of grouping album tracks where there may be multiple track artists involved with the individual tracks. Unfortunately, when tagging FLAC files, you need to be a little careful when choosing an ALBUM ARTIST field name.
These "tags" themselves are simple textual descriptions of the album artist. For example, "The Beatles" or "Michael Jackson". In the case of FLACs, tags are most commonly stored as Vorbis comments.
Each Vorbis comment consists of two parts: the data itself ("The Beatles") and a field name describing the data (in this case, "album artist"). It's the field name that's crucially important and the subject of this blog post. The field name informs your music player how the data contained should be used. For example, if the field name was "track number" it would know to show the resulting integers in a particular place in the user interface, and to order the tracks in a surrounding album by this number.
Like with most computer music tagging, however, there's no agreed standard to the name of these field name, and an example of where disagreement lies is with ALBUMARTIST.
ALBUMARTIST, ALBUM ARTIST or ALBUM_ARTIST?
The crux is that, because Vorbis comments are free text fields where both the field name and value are freely editable, minor yet absolute differences can emerge. Generally speaking, this has developed because the human readable abstraction "album artist" has a space in it, and different software and hardware have taken different decisions in what to do with the space.
While I have seen a few ALBUM_ARTIST tags in my time, they are by far the least common. Most disagreement, and problems arising, come from mixups between ALBUMARTIST and ALBUM ARTIST. I've drawn up a table of common hardware and software players, with how they treat these fields:
| Music player | ||||
|---|---|---|---|---|
ALBUMARTIST | ALBUM ARTIST | |||
| Read | Write | Read | Write | |
| foobar2000 | ✓* | ✓ | ✓ | ✓ |
| JRiver | ✓† | ✓ | ✓ | ✓ |
| MediaMonkey | ✓ | ✓ | ✓ | |
| Sonos | ✓‡ | ✓ | ||
| Squeezebox | ✓ | ✓ | ||
| Subsonic | ✓ | |||
| Winamp | ✓ | ✓§ | ✓ | |
- *
- By default, there's an option to change. Note that this was changed from, originally,
ALBUM ARTIST. If both are fields are non-empty, both values are shown. - †
- JRiver reads
ALBUM ARTISTpreferentially - ‡
- Sonos only allows one to be used
- §
- Winamp prefers
ALBUM ARTIST
In this table, the "read" columns relate to the field name used to extract data from a music file. The "write" columns relate to the field names used to update a music file, should you want to make a change. As not all players in the list support updating tags, some "write" cells are not completed.
It's clear that both are in widespread use, and the sometimes complicated rules make it difficult to choose a winner. In general, I would err on the side of using ALBUMARTIST, but you need to be wary where other fields are used preferentially.
If you have both fields, but you only write to ALBUMARTIST, some music players such as Winamp may not reflect any changes you make because they are only reading values from the ALBUM ARTIST field. In general, it's best to avoid having multiple duplicate fields for the same data, and some music players may even give up showing any data if you do this (see the Sonos link in the footnotes above).
If you have a choice, use ALBUMARTIST. But it's never that simple!
Thanks to Ken Teegardin for the image above.
