Classical Release Artist style and lo-o-o-ng Release Artist strings

MusicBrainz Style
,
1

I’ve been entering a few Releases recently, following the Style / Classical / Release / Artist guidelines. The result has been some entries with very, very long Release Artist strings.

For example:

  • Mozart Requiem / Schubert “Unfinished” Symphony, Release by “Wolfgang Amadeus Mozart, Franz Schubert; Vancouver Academy of Music Symphony Orchestra, Leslie Dala, Caitlin Wood, Laurelle Jade Froese, Rocco Rupolo, Zachary Read, Vancouver Bach Choir” (185 characters)
  • Matthäus-Passion, Release by “Johann Sebastian Bach; Christoph Prégardien, Matthias Goerne, Christine Schäfer, Dorothea Röschmann, Bernarda Fink, Elisabeth von Magnus, Michael Schade, Markus Schäfer, Dietrich Henschel, Oliver Widmer, Arnold Schönberg Chor, Wiener Sängerknaben, Concentus Musicus Wien, Nikolaus Harnoncourt” (292 characters)

Release Artist strings this long seemed to have triggered problems. I had PIcard hang on Mac OS X until I truncated the Release Artist string. Ripping software XLD refused to store files when the Release Artist string was too long. I’ve linked to bug reports for both. I got feedback that these strings are too long. When Picard tries to use a long Release Artist string as part of an audio file path, with Windows compatibility, the result is severely truncated file names.

The Classical Release Artist guidelines say:

  • Composer(s) and Performers: “The Release Artist of a classical Release should include the composer(s) and performers featured on the front cover….”
  • Only those featured on the front cover: “Use only composers and performers who are featured on the front cover (or the spine); don’t add artists from the back cover or the inside of the booklet or other places.”
  • Not too(?) many: "If there is a long list of names on the cover, only the most prominently featured names need to be included. " But it doesn’t say how long is “long”.

The guidelines don’t say how many artists is too many.

The guidelines don’t say anything about how long is too long for the Release Artists string.

What is MusicBrainz trying to accomplish with the Release Artists entry? I see these purposes:

  1. Link Releases back to Artists, so the Discography section of an Artist page is useful.
  2. Provide a useful Release Artists string for taggers. “Useful” includes “concise enough not to truncate file names”.
  3. Provide a way to capture featured artist credits, and collaborator credits, with useful Release Artist strings for the collaboration, without causing a mountain of “collaboration artists” separate from the Artist records of the collaborators.
  4. Capture the credits as expressed on the front cover of the Release

But I think present MusicBrainz structures cannot accomplish all of these at once. So, we have to trade them off against each other, according to a priority list. I suggest that the Style/Classical/Release/Artist guidelines be clarified to set priorities, and assist in the tradeoffs.

I suggest that #4 be a non-goal. We should be clear that Release Artist is not the place to note everyone who was credited on the front cover of a release. Nor is it the place to record the exact wording used to credit the Artist; abbreviations and standardisations are OK, especially if space is tight. If we want to record how credits were communicated on a release, that’s the job for a Relationship.

I suggest that the guidelines say that the top priority for Classical Release Artist is to capture the most significant one or two composers whose works are on the Release. If more than two composers, the editor is to use their judgement in picking the most important one or two for Release Arists.

I suggest that the guidelines give a rough upper bound for the number of Artists to include in the Release Artist: say, four or five. If more Artists than that are prominently featured on the front cover, the editor should exercise judgement in picking the most important ones.

I suggest that the guidelines give a rough upper bound on the length of the Release Artist string. I’d suggest 90 characters. As the length exceeds this, editors should use their judgement about dropping less important Artists. Maybe in some cases going past 90 is necessary, but going past 120 should be unusual. I won’t hold fast to those specific numbers, but I suggest we should have length bounds of some amount.

I suggest that editors be given discretion to use the Credited As option to abbreviate the name of less important Artists who still should be included in the Release Artists. For instance, drop first names, or use initials instead of the full first name. (This might not interact well with the sorted-name variant of Release Artist string, which Picard supplies and which I use.)

I think #3, collaboration Artists, was never an issue for Classical entries on MB anyhow, and the present Release Artist guidelines do a good job of achieving #3.

I suggest that #1, making it easy to create nice Discography sections of Artist pages on MusicBrainz, is high priority only for the one or two most important composers and performers on a classical Release. It is either lower priority, or a non-goal, to get Releases into the Discography sections of less-important Artists credited on the front cover, at least via the Release Artist connection. (If we can get MusicBrainz to populate the Discography section via Relationships, I think that’s great.)

I’m interested in comments. If there’s consensus, I’d like to make a proposal to modify Style / Classical / Release / Artist.

2 Likes
2

This seems to be mainly a tagging problem. wouldn’t an option in Picard to set a limit to the amount of release artists in the file naming string solve this? Other taggers using MusicBrainz data could use the same solution (implementing that is up to them).

4 Likes
3

It is possible to limit the length of the Release Artists string which Picard uses (the $truncate() function). However, this doesn’t eliminate the least important characters, it eliminates the rightmost part of the string. This is a problem. In the releases I pointed to, the sequence of Release artists is: 1. very important Composers, 2. least important singers, 3. least important chorus, 4. moderately important orchestra, 5. very important conductor.

In order to cut length by dropping the least important, either the original editor needs to do that, or we need a new mechanism in MusicBrainz to indicate importance. I prefer the former.

1 Like
4

Style generally operates under common sense being better than hard limits. There might be some cases where 15 artists do make sense. That Matthäus-Passion release isn’t one of them though IMO because, as you said, there are only two artists clearly credited on that cover way above everyone else (“only the most prominently featured names need to be included”).

Even if we did add everyone, they should be added as credited, which makes it 188 - still a lot but somewhat more reasonable (“Bach; Prégardien, Goerne, Schäfer, Röschmann, Fink, von Magnus, Schade, Schäfer, Henschel, Widmer, Arnold Schoenberg Chor, Wiener Sängerknaben, Concentus Musicus Wien, Nikolaus Harnoncourt”).

Basically 1 and 4. 2 is, as always, secondary (database comes over taggers), 3 is obviously useful in general but not specifically what we care about in this case (it wouldn’t affect length). The main use is that a release can be found from the discographies of any of the main artists credited for it.

I strongly disagree with this one. It’s not the editor’s job to count characters - it’s to show who the release is credited to. We already have a “use your best discretion to pick only the most prominent artists” guideline. That will sometimes lead to big artist strings, yes - but that’s because that’s the actual credit.

Is pretty much my opinion on this. We shouldn’t design our data so that a tagger is happy - we should improve taggers so that they can use data properly.

6 Likes
5

As it’s main objective Musicbrainz should focus on having the most complete, accurate and consistent data possible.
It should never compromise this to try to compensate for other programs or current tagging preferences, although it should try to provide them with ways to make meaningful machine interpretations of the data.

That’s my opinion obviously, but it also been the official line in the past, for good reason I think.

Dropping #4 is on my opinion dropping one of the only very clear guidelines we have (‘as printed on release’), and moving towards editor interpretations such as ‘when it’s convenient (eg shortens things) only use the artists that you think are most important’ is probably going to need a new server or two just to accommodate the resulting (and not resolvable) edit discussions! Perhaps you had some more non-ambiguous guidelines in mind, but unfortunately this has a bit too much editor discretion/inconsistency for my taste at this stage.

5 Likes
6

I agree with the general principle that MusicBrainz should make complete, accurate, and consistent data a higher-priority goal than bending to the weakness of clients, like taggers. However, I think that Release Artists is not the data item for which to defend this principle. Rather, it is the Relationships which provide the more complete, accurate, and consistent data about credits.

Can we all agree that Release Artists entries will not be a reliable listing of who gets credit for a Release? The publisher and graphic designer make decisions about who to credit on the front cover and who to leave off. Several MB editors are saying that it’s acceptable for an editor to make a judgement call about which credits on the front cover to include in Release Artists, and which to leave out. Release Artists is not the vehicle by which MusicBrainz achieves complete, accurate, and consistent data.

I see the MusicBrainz web interface as being in the same category as taggers. It is a client of the database. We should not compromise the data in order to compensate for the weaknesses of the web interface. In particular, the web interface should be able to make “discographies of any of the main artists credited” based on Relationship data, as well as Release Artists data. (I don’t see a ticket for this, by the way, is there one?) If it is not appropriate to include the limitations of taggers in writing style guidelines for database edits, it is also not appropriate to include the limitations of the MusicBrainz web interface.

Maybe its critical to have data about which Artists were given credit for a Release on the packaging. In that case, let’s make an Artist-Release Relationship which says this explicitly. Give it attributes: Front Cover major, Front Cover minor, Back Cover, Booklet, or Highly Important, Moderately Important, Les Important. Make a web UI that helps editors enter this with reasonable workload. Make the web interface use this in generating discographies. I think it’s a mistake to rely on Release Artist for this.

I also think that it’s important to strike a balance between the needs of the database design and the needs of its clients, rather than to say the database design is the only thing that matters and the needs of clients are disregarded. Furthermore, I think that we should keep an eye on what provides value to MusicBrainz contributors. I suspect if you counted, you’d find a lot of editors contribute to MusicBrainz because they get something of value in return, not because they are dedicated to the abstract principle of a clean database. And I suspect that a big part of that value is good strings for Artist, Release Title, and Track Title in taggers.

I argue that Release Artist is not the vehicle by which MusicBrainz collects the most complete, accurate, and consistent data about artist credits. It is a legacy of the past incarnations of MusicBrainz. It is a convenience serving multiple purposes. It is presently the vehicle by which one database client delivers discographies, and another client delivers good directory names for music-file collections and VORBIS metadata strings. It’s necessary for now, given the present limitations of clients. So, I think it’s reasonable for Style guidelines to ask editors to strike a balance, rather than be single-minded, in how they fill it out.

7

This is a good point. I think it shows how the wording of the guideline might be improved.

I interpret, “only the most prominently featured names need to be included” as meaning, “the most prominently featured names must be included, less prominent names not not have to be included, but they can be… and maybe should?”. Changing one verb would convey your intended meaning more clearly to me: “only the most prominently featured names should be included”

Fair enough. But common sense is not so common (either in the sense of “frequently found”, or “widely shared”). And what the guideline offers now is silence. It’s possible to write words that convey flexible guidelines. Something like, “Usually no more than three to five, but maybe more if this factor and that factor.” Or, “Brevity is good, and including the most important contributors is good, strike a balance.”

You know, I don’t see the concept of “should be added as credited” anywhere in Style / Classical / Release / Artist. Adding words to that effect would be helpful, I think. How about, at the start of Featured Release Artists, add a second sentence which reads:

In the “Artist as credited” box, fill in the name as spelled or abbreviated on the cover, e.g. fill in last name only, if the cover includes only the last name.

I think it would be helpful to add comments to each of the guideline’s examples pointing out how the wording on the cover led to the wording in the Release Artists string.

Does the example, “Début Recital Martha Argerich” demonstrate a guideline that “only the most prominently featured names should be included”? The less-prominent names of Chopin, Brahms, Liszt, Ravel are left off.

Would it be helpful to add the Matthäus-Passion by Bach; Nikolaus Harnoncourt as an example of both leaving out less-prominently featured names on the front cover, and crediting names as on the cover (last name only for “Bach”, full “Nikolaus Harnoncourt”)?

By the way, one example is: “Copland Conducts Copland Aaron Copland; Aaron Copland, London Symphony Orchestra, Columbia Symphony Orchestra, William Warfield”. That’s now a bit stale: in the live Release entry, the composer credit no longer includes the first name “Aaron”. I’m not sure why the performer credit includes the first name, because the cover says “Copland conducts Copland”, last names only.

It might be that these wording improvements to the Classical Release Artist style guideline might be editorial only, and would be quite a bit of help. I’d be glad to offer first drafts of such changes.

8

OK, thinking as a programmer considering a Picard plugin or feature to generate a short directory name out of the Release Artist credits for a Release, here’s what I would want the database to supply in order to let me make a concise string:

  • Deliver a list of Artist references, instead of a Release Artist string.
  • For each Artist, deliver data about whether the credit was Very Important, Moderately Important, Less Important (or some multi-valued scale of importance)
  • Deliver the ordering of Artist references as credited.
  • For each Artist, be able to supply the Artist name in a variety of abbreviations: Full Name, Last Name only, Last Name plus First Initial, Initials Only. Also, do the equivalents for any language a name might be in: Japanese, Chinese, Russian, German, etc. Don’t forget to handle special words correctly, e.g. “von” in “von Karajan”.
  • Deliver the Release date. Sometimes, in classical music, the same primary performers will record the same work multiple times in successive years. e.g. Maria Callas and Tullio Serafin performing “Norma” in 1954 and 1960. Or re-releases.

Then I can write code that successively shortens the less important names, then drops the less important names, then shortens the more important names, then reduces the more important names to initials.

Without it, the best I really can do is truncate the string, regardless of whether the names I truncate are important or not.

It’s all possible in theory, but the database is a long way from storing this data, much less delivering it to a tagger via an API. In the meantime, isn’t it reasonable to have the tagger’s use of a string be one consideration in the guidelines for how editors construct that string?

9

Not at all. Relationships are for documenting the facts, independent of any credits. E.g., if Jane Doe sang background vocals on some recording, but the liner notes don’t mention her, or wrongly attribute the background vocals to Martha Smith, there should still be a “Jane Doe sang background vocals on” relationship.

(Now you might say that that’s what relationship credits are for. But relationship credits are useless, because they are not tied to a release, and different releases may credit the same things differently.)

10

What is less important for you might not be less important for me. Which one of us would make the final decision? (or are we going to have endless voting wars about it).

1 Like
11

Very true. But here I am talking about tagger code. Presumably this is packaged as a plug-in, so that I use it if it fits my needs, and you don’t use it if it doesn’t. I’m not talking about core database code doing the abbreviation.

I mention the core database here because it has to provide enough data to the tagger to permit the tagger to do this work.

12

Um, I’m not familiar with relationship credits. I’ll accept your word that they are useless. But what to do in the face of this uselessness, if our goal is complete, accurate, and consistent data? Lean more heavily on a historical mechanism which partly does the job but is familiar, or start work on repairing the new mechanism so it is not useless?

I’m afraid I don’t follow you. What I understand people want from the Release Artists mechanism is to describe how a particular Release credited its most important Artists, right? So if different Releases credit the same Artist differently, that’s OK, and in fact its what we want to describe, right? Or am I misunderstanding?

13

Selected quite could have been better but basically many times you prefer editors making decisions about the importance of data. For example “If more than two composers, the editor is to use their judgement in picking the most important one or two for Release Artists” and “Give it attributes: Front Cover major, Front Cover minor, Back Cover, Booklet, or Highly Important, Moderately Important, Les Important”. This doesn’t work for me. I don’t trust you or anyone else making decisions what is important for me.

14

Not trusting me, e.g. to make decisions about what is important for you, is probably wise. :slight_smile:

The Classical Release Artists Style says that publishers and graphic designers, and MB editors, make decisions about which artists to include the the Release Artists field. The publishers and graphic designers, by choosing which names to but on the front cover, and at which size. The editors, by following a guideline which I would word as, “only the most prominently featured names should be included”.

Which names do you think should be included in the Release Artist? Only the prominently featured names? Every name on the front cover, regardless of prominence? Names from the back cover also?

15

[quote=“Jim_DeLaHunt, post:6, topic:127381”]
I suspect if you counted, you’d find a lot of editors contribute to MusicBrainz because they get something of value in return, not because they are dedicated to the abstract principle of a clean database. And I suspect that a big part of that value is good strings for Artist, Release Title, and Track Title in taggers.[/quote]
Quite frankly, I think from the response it’s clear that the majority of other editors don’t consider this proposal, at this stage, to provide them with better strings for their taggers.

You were originally trying to deal with the issue of particular releases that have unusually long artist credits, so I think it’s disingenuous to try to imply that this change also somehow solves an implied issue with how all releases are credited. (Granted, it may do that, but there’s undoubtedly a host of new possible issues introduced with such sweeping changes)

I think it’s a good idea to stick to the original aim, you’ve mentioned some good ideas in regards to this. The rest is honestly getting into the weeds a bit with some broad questions, and I don’t know if that’s a good way to go for concrete results. In my opinion :slight_smile:

1 Like
16

I’m not trying to imply that, and I’m sorry if my words gave that impression. What I’m trying to say about tagger strings being of value to editors, is that making Style decisions in complete disregard of what tagger strings (or MusicBrainz web UI) come out today, and purely on the basis of “having the most complete, accurate and consistent data possible” (to quote you from above), is unwise. There needs to be a balance in weighing these factors. 0% weight to tagger strings is too little.

17

You’re still going to get things like:

where is isn’t clear which unimportant parts you’d drop (that last one I guess you could have no performers, but that doesn’t seem good, either).

Personally, I used to be really concerned about file names, and very carefully named and organized music files. But for a whole variety of reasons—repeatedly hitting the 255-character ext4 limit among them—it just doesn’t seem like file names are sufficient. FLAC comments, OTOH, do not impose any real limits. So mostly I do my music browsing nowadays by tags, not by file names.

1 Like
18

Fair enough. What file naming scheme do you use in your directory tree of music files? The music files have to have some name and some structure.

19

What I’m saying is that personally I don’t think your proposal would improve my tagging strings, it makes then less predictable and consistent. Speaking as a someone who uses MB to tag their music.

I like your alternate suggestions, such as supporting abbreviations (I feel like there must be a way do this already, eg a plugin, using the existing db), or allowing editors to attach values to different artist credits. But in a practical sense they also pose their own problems. But I’m not sure if you are pursuing those suggestions at this stage

1 Like
20

I’m on Linux so I don’t hit them that often (because I don’t have to deal with Window’s total path length limit, only a 255-octet file name limit). But when I do, I just manually shorten it.

Currently, my file names come from whatever morituri makes (when it’s too long, it unfortunately fails out, and I have to manually shorten it—I wish it just truncated). Often its something wrong (or at least not according the the current style guidelines), as I’m often ripping the disc before I edit the album. Or sometimes a rip comes from EAC, so I get some weird name from FreeCDDB.

Eventually I’m sure I’ll try to standardize the name somewhat (if nothing else than to make finding files easier in the few cases where I have to do it by looking through the filesystem, not through tags).

But my ideal way to browse through music would be a player that’s fully aware of the MB schema, and browses through based on MBIDs. Maybe I’ll write one someday…