De facto or de jure? Five misused tags.
July 28, 2015 in tags by Dan Gravell
This week we step up a level of abstraction. We take a look at, not individual music library tagging, but instead, tag schemas. That means the pre-defined tag fields (and in some case values) that may be used to tag a collection.
Such pre-defined fields, when mandated by a standardisation group, could be considered de jure. But this is not the only source of a tagging scheme. Over time, music library collectors may adopt certain fields for a given purpose, or define their own label. This is called de facto.
Here come five different tag fields that have been perverted from their original intention, where de facto has taken over from de jure!
Album artist
ALBUM ARTIST is one of the most useful tags out there. It defines the artist for the release that the music file is contained within, which in turn is defined by an album name tag. The obvious application are "Various Artists" compilations, where each track has a different artist but the overall album artist is "Various" (or some alternative).
Inside a music file, each piece of metadata, such as the album artist, is identified as to what the data is by use of a pre-determined label. FLAC and Vorbis Comments both use the self describing ALBUMARTIST. MP4 mandates aART. Windows Media formats use WM/AlbumArtist.
ID3v2.x (used within MP3s), however, has no such field. Instead a de facto approach has caught on where TPE2 is used. According to the ID3 documentation, TPE2 is used for:
The 'Band/Orchestra/Accompaniment' frame is used for additional information about the performers in the recording.
These are quite different semantics to that of the album artist. This mis-use of TPE2 has now been widely adopted. But what if you now still want to store the orchestral accompaniment, say? For classical recordings this may be quite useful, but it's asking for trouble to use a given field for all classical recordings for one purpose, and then use it for another purpose for all other tracks.
The inconsistency will inevitably lead to some strange looking data and some difficult to navigate music libraries, but there's little other choice.
iTunes' Grouping tag
There isn't much documentation about to describe exactly what iTunes' generically named Grouping is for, but a simple Google search nets this, gleaned from the AppleScript dictionary for iTunes:
grouping (Unicode text) : the grouping (piece) of the track. Generally used to denote movements within a classical work.
What is iTunes “grouping” tag for?
The fact that (a) the field is very generically named and (b) the documentation as to what this is for is so difficult to find means this will inevitably be used in different ways by different people.
And so it has proven. The author of the citation above uses it for the record label. Others use it for grouping albums or tracks of a given mood, sub-genres, or for a given occasion, or identifying albums of a given type, e.g. live tracks.
This is generally ok if you apply this within your own collection and do it consistently. Where you might still meet some trouble is if the software you use makes assumptions of the semantics of the Grouping tag, and so treats your entries in a way you might not want.
I'd leave it empty!
Composers
Wikipedia defines composers as:
A composer [...] is a person who creates music.
It goes on to note that the term is most often used in the context of Western 'classical' music, but that's still a pretty broad definition! As such, it would apply to contemporary genres as well.
Here's a case where your music player software could trip you up. You could legitimately enter song writers into the tag field, and software could, assuming the use of the tag exclusively for classical compisitions, give you some very strange entries when you browse your classical composers.
It comes down to how you want to browse your library. If you really require the original song writer of a piece, and that is different to the artist (performer) or the piece, you could use composer for this, but choose your music player judiciously.
Years and dates
YEAR or DATE (depending on the tagging format) is an interesting one because there are so many different timestamps you could pick for any one track. Should it be the year the track was recorded? Should it be the year its containing release was released? In the case of re-masters, should it be the original recording year of the track? That might help you navigate your collection best.
ID3v2.4 itself defines three different timestamp fields pertinent to this:
- TDOR
- Original release time
- TDRC
- Recording time
- TDRL
- Release time
TDRC is the commonly used one and the one used by default by most software, so I suggest storing the date that makes sense to you (original or re-release) there.
Then there's the formatting of the date. Traditionally this would just be the year. But there's no reason why a given day couldn't be provided in an appropriate format. This opens up more questions - is 10/04/2014 the tenth of April or the fourth of October? That would depend on whether you live in the States or not... But again this is not defined de jure, so music transferred between collection to collection could be misinterpreted.
Genres, and the dangers of prescriptive tag schemes
The previous examples of mis-used tags could generally be put down to mistakes, confusion about the purpose of a tag field or the simple absence of a field to store an otherwise important piece of data.
But even in the post-modern world of digital music, there's space for a good old Ivory Tower. The original version of ID3 pre-defined eighty genres which were supposed to cover all past and future music. This was later enlarged to a set of 148 genres, but the point was that this level of prescriptive standardisation was never going to stand the test of time.
Here's the list if you think that 148 genres should be enough for anyone (you'll notice dub step isn't there... or dub for that matter).
The writers of the ID3 specifications realised trying to guess all the future musical genres in the world would never work, so for ID3v2 and onward they allowed free text genres.
Maybe the lesson from the genre debacle was that pre-defining tag values, setting what they should be de jure, was a step too far.
Pre-defining tag fields, on the other hand, is both useful and necessary to avoid inconsistency and incompatibility between software. That's where you want de jure standardisation!
Thanks to KeithBurtis for the image above.
