Understanding Classical Release Artist style through practical examples

Tags: #<Tag:0x00007f0506040788> #<Tag:0x00007f0506040648>


Let’s see if I’ve correctly understood the lessons from the Community thread Classical Release Artist style and lo-o-o-ng Release Artist strings.

In Edit #40622421, I cut down the Release Artists list for the Harnoncourt Matthäus-Passion, and I’m leaving it open for votes and comments. If I got it all wrong, let me know, and I’ll cancel the edit.

The Release Artist list now has only the most prominently displayed names, per CSG/Release/Artist, “only the most prominently featured names [should] be included” (“should” is my word, based on clarification in the thread). The composer, J.S. Bach, is listed as “Bach”, per “…they should be added as credited…” (as stated in the thread).

The CSG/Release/Artist guideline is at http://musicbrainz.org/doc/Style/Classical/Release/Artist .

Votes? Comments? Thank you.


Harnoncourt recorded Matthäus-Passion at least 4 times. If we seriously believe that lesser data is better than more we are making it more difficult to identify and find correct releases. I’m strongly against of shorter credits especially when there doesn’t seem to be good arguments against them.


This is why I love practical examples, they help make the underlying issues clearer.

You are right that Harnoncourt recorded Matthäus-Passion several times, so “Harnoncourt Matthäus-Passion” is ambiguous. But we have other fields which provide disambiguation: the Disambiguation string, the Release date, the label, and more.

Are you arguing that the Release Artist list should have a goal to provide disambiguation? I don’t see that in CSG/Release/Artist. It says, “The purpose of the Release Artist field is to assign releases to specific artists.” I don’t think that wording is all that clear, but it doesn’t include “disambiguate”.


Disambiguation “2000 recording” wouldn’t be enough for identifying this because not that many of us would search recording data from booklet to find the correct release. Maybe we could disambiguate this “2000 recording by Concentus Musicus Wien & Arnold Schoenberg Chor” (choir is included because there’s another recording with the same orchestra).

Which one is more logical to you: storing data about artist with artist credits or by using disambiguations? Do we need to write a guideline to clarify this?


I wonder how often people using Spotify, Itunes or Amazon.com or any services related to music have been having similar problem. How often they think that “this service is showing us too much data” even though they often show exactly as much data about artist as we. How often is MB support getting emails because people feel we got too long artist credits? Are you trying to fix a problem which actually isn’t a problem for majority of us?


That is an excellent question! I believe that disambiguation strings are a better place for disambiguations than artist credits, though sometimes the artist credits turn out to be sufficient.

I think every field and string in MusicBrainz should have guidelines that are a reference about that the purpose of the field is and how to fill it out correctly. But, there is a cost to more text: not everyone will read every word, and sometimes the sight of lots of text makes readers give up without reading.

That is another excellent question! I have no information about MB getting support requests because artists credits are too long. I didn’t start this thread because of problems for other users. I started it because following the CSG/Release/Artists guidelines caused me to make Release Artists strings that were a problem for me. I want to either understand the guideline better, so that I make Release Artist strings that are less of a problem, or improve the guideline.


I think per the style guidelines the edit is correct—but this strikes me (now) as a good reason to change the guidelines. I know when trying to find albums in the database it’s very helpful to be able to search by a less-common artist; and indeed a lot of places your only choices are release title and artist. Sometimes only one or the other, like on the lookup/attach CD discid page. So I think in voting for that edit I made the database harder to maintain in the future, and that makes me think it’s not the right approach.

Some of this of course could be handled by more fields, or flags on the existing ones. We could have a flag on each artist on the release if it’s in big text or not. We could add a field for artists (and title!) on the spine. Of course, it’ll make it take even longer to enter a classical release. And of course some of the search limitations could be solved by site coding.

But lacking more fields and checkboxes; and lacking search improvements., it seems like we should change the guideline to be simply: list all the artists on the front cover, composers first, semicolon, then performers. If some are indicated as more important, list them first in their group. This would let folks who need shorter strings for names do a simple truncate, and would preserve full searchability.

I see disambiguation strings (at least for releases) as mainly a last resort when nothing else can be used to disambiguate. The label kept the same catalog number, bar code, etc., but changed the cover art a little, or fixed a typo. Or released two slightly different versions to different retail channels. All kinds of minor differences which are beyond what we can reasonably build a schema around.

Their big problem is that they are free-form text. It’s perfectly valid to have a disambiguation comment that says “blue cover”, “‘Agnus’ spelled wrong”, “Walmart exclusive version”, or whatever. Trying to do anything with them computationally goes from a trivial MBID or string compare to an AI problem. Disambiguation comments are great to show to a human to pick from a few releases, but they’re terrible for anything else.


Isn’t this just another request to bend the database contents, to make up for the weakness of a client of the data? Whether it’s a tagger or the Musicbrainz web UI, we still shouldn’t change our database structure or style guidelines to help, is the argument I kept hearing. I disagree with that extreme an unbalanced view, and I’d like to see use add a little more balance to our guidelines. But I keep losing that argument.


Somewhat, yes. A rather special client of the data, but a client no less. Though the bit about favoring structured data (release artist) over unstructured data (disambiguation comment) isn’t—structured data is, I think, in some fundamental way more useful.

Realistically, the style guidelines already have compromises in them. Clear example: CSG says that the recording artist should be the performers, but its OK for newly created recordings to be the track artist (composer) instead. That’s entirely because the MB site makes anything else extremely painful.

I’m not sure if anyone really believes the style guidelines/DB should never accommodate the needs of programs using the data, but it’d appear you believe in more accommodation than most folks commenting here. (But I’m sure there are still some you’d reject is absurd; e.g., I doubt you’d suggest we should prohibit all the punctuation Windows doesn’t like in its file names.)

I’ll note I suggested an accommodation: put all the artists in, but the “important” (big letters, different color, whatever) first. So then your tagger can take as many as fit, and get the most important ones.


Agreed because the CSG makes us use these fields in a different way to how they were intended, but the way I would do it is when I add the release I would add the performers as the track artists (so they get used for recording artist) and then once added just change the track artist (leaving the recording artist alone) to the composer which is less painful.


That’s how most autoeditors used to do it before the script. Now it’s generally no longer necessary, but still useful on occasion.

Keep in mind that this is only trivial for autoeditors though. I guess the situation has improved now since any user can change the track artists to composers on their own add, as long as they do it less than one hour after the first add, but if they wait any longer then they’d have to wait a week. In that case, or if they’re not the original adder, the other old option is still better if not using the script (change the track artists to performers, then cancel the tracklist edit and let he recording ones stay).

Carthago delenda est game too strong.


Well, interestingly the MusicBrainz Web UI has been used as a reason for using the recording and track artist credit fields in a different way for Classical than all other releases. The reasoning was essentially that it makes it easier for editors, but this seems to be a very bad reason for messing up database tables. as is the tagger requirement.