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
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
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
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
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.
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.
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?
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.)
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
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.
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?
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.
Not trusting me, e.g. to make decisions about what is important for you, is probably wise. 
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?
[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 
1 Like
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.
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
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.
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
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…
- Capture the credits as expressed on the front cover of the Release
Seems to be the primary reason for the release artist credit more than any other of the other reasons, but perhaps for physical release it could be adjusted in some way so that what is written as the artist credit on the spine takes precedence either always or when the front cover is particulary verbose since the physical spine does impose a limit on how long the release credit can be without setting an actual number.
Ideal would be a separate field SpineReleaseArtistCredit field that by default would be same as ReleaseArtistCredit but can be used when value on the spine is different. This would be valid for any type of release, but most useful for Classical.
4 Likes