Why have classic track artist fields?

MusicBrainz Style
, , ,
1

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?

1 Like
2

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)?
    [/quote]

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.

5 Likes
3

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.

Pasted image837×422 17.5 KB

2 Likes
4

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!

3 Likes
5

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

1 Like
6

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?

2 Likes
7

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.

2 Likes
8

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

1 Like
9

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.

10

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:

1 Like
11

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:

2 Likes
12

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? - #14 by mmirG 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.

1 Like
13

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? - #10 by ijabz 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:

3 Likes
14

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

15

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

16

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.

2 Likes
17

FYI, this is not just a problem that I see, but others as well


and its causing the Roon community to view MusicBrainz as having an inadequate understanding the basics of classical. This is a shame because MusicBrainz has the database structure to support Classical very well, but just a few problems hold it back.

Roon is rated very highly in hi-end audiophile community because they generally add very good metadata to customers music collections (including from MusicBrainz), and make it look very nice. Whilst I think it is rather overrated MusicBrainz would do well to not ignore them.

To reiterate the faults as I see it

  1. MusicBrainz use Track Artist/Recording Artist completely differently for Classical releases whereas for Pop/Rock Track Artist is just a refinement of Recording Artist
  2. There are also far too may releases where the composer is still set as the album artist. I know this has been nicely resolved for some composers with the classical cleanups, but its a shame a more automated approach could not be used to get this done quicker.
  3. MusicBrainz expects users to input data differently for Classical but:
  • make it difficult to add the extra data for Classical
  • don’t set any flag so that readers of the information know they are looking at a classical release that has been entered using the classical guidelines (rather than a non-classical release or a classical release that has been entered with non-classical guidelines)
1 Like
18

1

I don’t understand the claim we use the track artist differently on classical. Just like on non-classical, it’s the person(s)/groups principally responsible for it.

2

It’s also typically the most prominently credited person on the release for the track. Here is a random album I grabbed from my collection (literally; I ran mb-open-release "$(find -type d -print0 | shuf -z -n1)"/01.*.flac and grabbed the first one with an uploaded booklet — the third one it opened.*)

Everything is uploaded to CAA, here is the most detailed tracklist:

Those tracks are clearly credited to Howard Hanson (the composer), not the Seattle Symphony, Seattle Chorale (7–11 only), and Gerard Schwarz (the performers).

You would be hard pressed to find a classical release where the non-classical track artist guideline “[t]rack artists should follow the release artist, except where another artist is credited in the track listing of the release. This can include various artists releases, featured artists, and tracks credited to another artist” would not result in the composer being the first, if not only, artist listed.

3

Currently, it let’s us store a credited-as name for the composer — which we otherwise can’t. The tracklist often uses a fuller name than the front cover, so the release artist doesn’t work for that (not to mention some releases don’t have all the composers on the cover). And the composer on the work entry is shared across all recordings of that work, so we can’t do it there either.

(There of course exists a similar problem with the performer AR credits, but it’s much less of an issue since recordings are far less shared than works.)

*mb-open-release is a trivial script I wrote:

#!/bin/sh

if [ -z "$1" ]; then
	echo "Usage: $0 file.flac" >&2
	exit 1
fi

tags="$(metaflac --show-tag=MUSICBRAINZ_ALBUMID "$1")"
if [ -z "$tags" ]; then
	echo "No MUSICBRAINZ_ALBUMID tag found in $1" >&2
	exit 2
fi

if [ $(echo "$tags" | wc -l) -gt 1 ]; then
	echo "Multiple MUSICBRAINZ_ALBUMID tags found in $1" >&2
	echo "$tags" >&2
	exit 3
fi

alid=${tags#MUSICBRAINZ_ALBUMID=}
xdg-open "https://musicbrainz.org/release/$alid"

(and yeah, sorry that I haven’t found time to contribute code to MB, despite being an actual Perl developer… someday…)

4 Likes
19

Let me try again, we are not talking about the release artist here. For most non-classical albums the track artist is the same as the recording artist field, for most classical albums the track artist is different to the recording artist.

Or look at it another way, the recording artist should always contain the principal performers for that song, but sometimes the same recording is credited slightly differently on a particular album, most commonly the persons name is slightly different, or sometimes a minor performer is credit/non-credited, and this difference is captured in the track artist

But for Classical this difference is not captured, instead we are told to just enter the composer, even though usually the composer had nothing to do with the actual recording/performance.

This is a clear difference, and what makes it such a pain is that the recording artist is what people want to see in their Artist field (or ideally the recording artist as captured for the recordings on the release, but unfortunately we don’t store this for classical), they dont want to see the composer, there is already a separate composer field.

And unfortunately, the recording artist is not always entered correctly, as it is alot more fiddly to add the recording artist then to add the track artist. Consider this for the moment, most tagging software that uses MusicBrainz will end up putting in the composer as the track artist for classical music. This is not what users want and the blame really lies with MusicBrainz for having a poor default mechanism for track artist. I have done alot of work with SongKong to extract a suitable value for Track Artist but it really is not easy with the way MusicBrainz is setup, and often MusicBrainz does not actually include that information so is not available.

2 Likes
20

Given the composer was chosen there by community choice, I’d imagine quite a few people do specifically want to see the composer in the artist field.

Most software that uses MusicBrainz and has an interest in classical music should be using relationships to fill both composer and performer fields. If tagging software is mediocre for classical (which it probably is, Picard included), that’s not directly our problem as a database, as long as the actual information is available, which for a correctly entered release it is. Our job is to make the relevant information available. If the relationships are not used properly, then the tagging will always be mediocre, so I see absolutely no point changing the way we do things for this - and the way we do things is the most useful for MusicBrainz itself.

3 Likes