Why have classic track artist fields?

Tags: #<Tag:0x00007f05082ec7c8> #<Tag:0x00007f05082ec688> #<Tag:0x00007f05082ec4f8>


Why do we have a track artist when the recording artist and composer are sufficient?

Half the “Classical” CDs I look at on MusicBrainz (incorrectly) show the performer as the track artist, and, half show the composer. Why do we have an option to manually override either, rather than the database choosing to display the classic recording composer or performer (if non classical)?

The only place I see that the track artist may differ from the recording artist/composer, is on the CD itself, where some artists chose to credit the composer(s) of their tracks, and some compilations chose to credit the performers, but this information preference is not recorded anywhere.

Is Jazz considered classical, should I be replacing track artists with recording composers?


These three pieces of data answer different questions (although they often overlap).

  • track artist: usually, who is credited in the track list? For certain specific types of releases there are other guidelines.
  • recording artist: usually, who was credited for this recording (as the track artist) on its earliest release? For certain specific types of releases there are other guidelines.
  • composer: who composed the work? This is a matter of fact, and doesn’t rely so heavily on the credits of a specific release.[quote=“iantresman, post:1, topic:151659”]
    Why do we have an option to manually override either, rather than the database choosing to display the classic recording composer or performer (if non classical)?

It’s been talked about (example), but there’s not a bulletproof way to programmatically determine which releases are “classical”. IMO this is a great goal to work towards, but there will always be a need to capture both “what’s on the cover?” and “what’s factually true and/or contextually relevant?”

There are, of course, ways to override/customize how Picard populates your tags.

Almost never.

It’s possible to e.g. use jazz forms/idioms in a “classical” or “operatic” context, but generally jazz is handled like any other pop music in MB, which is to say it uses the general style guidelines.


I think originally we didn’t have recordings (or relationships) just tracks so at that time there was just track artists and therefore it made most sense to store composer as track artist for classical and performer as track artist for everything else.

Then we added recordings allowing them to be shared between releases. The reason we had both a RecordingArtist and TrackArtist was to implement a form of Object inheritance. i.e whilst every track on a release needed a track artist it was recognised that when different tracks were in fact the same recording they would usually all have the same track artist, this common track artist is the recording artist. It is officially the track artist of the first release the recording was used on but in reality it is more likely to be the track artist of the first release that was added to the database containing this recording, but it doesn’t really matter I would consider it the usual track artist, we have the same logic for RecordingTitle and TrackTitle

But classical music didnt adapt to this change (or rather music added using the Classical Music Style Guidelines) the above logic is ignored for Recording Artist and Track Artist. Instead the RecordingArtist is used for the performers, and the TrackArtist for the composers (however the logic is not ignored for Recording Title and Track Title). Neither Artist field specifically relates to the cover credits, for example if the composer is not credited on the release but you know who the compose is they should still be added to the TrackArtist field.

Personally I would prefer it if classical music guidelines was more in line with the general guidelines.

FWIW I have implemented such an algorithm in my SongKong tagger and it is working reasonably well. Originally I wanted to identify when a release was a classical release in order to set a suitable value for the track artist but I have other reasons to do this as well.

  • To shorten track titles to just the Movement
  • To force Composer to be added to album title if missing, helps distinguish between simarly named works
  • To remove Composer from Album artist, some users don’t like having composer in album artist fieldthis because not a performer
  • To prevent modification of fields, users sometime use certain fields in non-standard ways for just their classical music to compensate for the lack of support in music players.
  • to set an isClassical flag that can then be used when renaming files from metadata to allow classical music to be named differently to non-classical.


A ‘classical’ checkbox (like ijabz asks for in your linked thread) that editors can use would be a pretty simple way of avoiding this.
Not that that’s helpful right now!


BTW I’m not the only one who disagrees with how TrackArtist/Recording Artist works for Classical, so does one commercial user Roon - https://community.roonlabs.com/t/about-album-identification-problems/38954


This is a very valid point, and something which makes me angry whenever I think about it. In many places, the musicbrainz db is built in a very clean way, but those artist fields do not make much sense, in particular the recording artist IMO.

Release artist makes sense. To state the artist(s) which are credited on the front cover. Track artists would make sense if they were used in the same function (state who is (prominently) credited for each track), but the guidelines instruct us to use them in a different way. Recording artists are totally needless IMO. Relationships are much better. And if some tagger software really needs a recording artist string, we should design the relationship framework to build one from the given data (like adding a checkbox “important artist” to the performer relationships, which is used for selecting the artist for the “recording artist” string).

Concerning classical music (fits also the thread How to help people with classical editing?): The artists issue was the biggest obstacle for me when I started editing classical music. To memorize the strange rule “Release: Composer; performer – track: composer – recording: performer” which just feels arbitrary and needlessly complicated. As I said, release artist is fine. For the (questionable) track and recording artists: Why not at least use the same rule “composer; performer” for all? It’s unnecessarily hard to memorize the strange rules, and additionally it’s not so easy to get everything correctly into the database. The best way (without using scripts which is something we should not expect from newbies) is first to set the track artist to the performer and push that change to the recordings, and then to change the track artist to the composer without pushing. Isn’t that insane?


It doesn’t make ontological sense to associate a recording with someone who had nothing to do with the recording itself. For the tracks, that’s just how MusicBrainz used to do it and what people preferred to keep doing (It’s also much less effort if you’re dealing with a compilation, for example - I definitely wouldn’t want to waste time selecting the appropriate composers and performers for every track).

Keep in mind this is specifically why setting recording artist is preferred but not mandatory - it is not supposed to be something new users need to worry about.

In general, though, the answer to the original question:

Is that we can’t leave fields blank. Otherwise, for classical, we would leave everything blank (except maybe release artist) and just use relationships and be happy, but we don’t have a classical-only database, so we need to work with what we have.


Wouldn’t it be a fairly trivial schema change to allow this field to be empty?


I think very few people would be happy with that.

As far as editing goes the problem is that the Track Artist is always different to Recording Artist unlike non-classical releases.


Probably, but it would have a big effect on every single application of our data down the line, from Picard (easy to change) to any of the others we have no control over, so even if technically easy, it’s socially/environmentally very complicated :slight_smile:


Why so? All the data could be generated from relationships and put in the right places if so desired. As far as I understand, that’s for example what @MetaTunes’ classical plugin for Picard does, and it seems to work fairly well.

A classical release without any relationships is IMO pretty close to worthless, you kinda might as well just use freedb by that point. But with all the relationships there, that’s a level of detail almost nobody else has (allmusic, sometimes, but they’re not always too good at it). Which is why we really need to direct classical editors towards relationships more :slight_smile:


Yes it can and I use them in a very similar way in SongKong/Jaikoz as well.

But look at the answers on your How to help people with classical editing? post, the majority complain about the UI and the difficultly of adding relationships, because adding a relationship is more difficult than simply filling in a field that has been presented such as Track Artist. So using more relationships (at least with the current UI) is not going to make things any easier.

Similarly it is more complex for applications to try and decode relationships than just use the standard fields. All music players have an album artist and track artist fields and these need a value, including for classical so make sense for MusicBrainz to at least try to generate these values.

And I do not agree there is no such thing as a Track artist for Classical, there is. It just isn’t a single person, it comprises the Conductor, Performers/Orchestra/Choir on the piece.


In that case, we could do the generation somehow. My main feeling is that if you make people add all this info by hand to the track artists (in all cases where they wouldn’t equal the release artist, which are many), and then you ask them to add the relationships, the reaction would be “didn’t I just tell you all this? not again!” - I’d much rather have them add the relationships and then try to generate artists. Maybe even pre-fill them for them, and ask them to change them if anything looks wrong (which I understand is basically what you ask for at the How to help people with classical editing? post - and it’s a good idea in itself!). The problem with all this is mostly manpower to both write and maintain this UI :confused:


Fair point. I suppose an alternative hack would be to have a special-purpose artist called None or something…


5 posts were split to a new topic: MB development focus and issues


Does it make ontological sense then to associate a release with someone who had nothing to do with the release itself? Come on.

On the second point I agree: I want to add the info only once, namely in a structured way as relationships. The need to replicate that info in a poorer way into those artist fields which are there for historic sentiment or whatever doesn’t make any sense to me. That is wasted editor time and an additional source for errors and inconsistency. Again: If those artist strings are really needed, then automatically and dynamically create them as read-only strings from the relationships. If needed, enhance the relationship framework (like adding an “important performer” checkbox).

Also, consider searching for all recordings with a certain performer. Currently, I always do that twice: Once using the artist field, once using the performer relationship. In the end I get two overlapping lists which I mentally have to merge somehow. This is because of that stupid data duplication which naturally is done in various inconsistent ways by different (inexperienced) editors.
Everything would be so much easier if there was only a single place for adding and searching for that kind of info.

Moreover, when the relationships are the only place where you can add the performer info, people are forced to use relationships! Combine that with a more relationship-friendly UI and your (very valid) point

should improve significantly.