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

Tags: #<Tag:0x00007f341f5dff48> #<Tag:0x00007f341f5dfe08>

  1. 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.


I could understand limiting the amount of artist listed on artist credits if there would be good arguments for it. What I have now understood is that we got “it’s a problem for my tagging” or “it doesn’t look nice” as a reason to consider it. Both at least for me are lesser problems than making it harder to find and identify releases.

I don’t support adding new fields or new relationships for storing credits from spine or back cover. I feel there’s exactly same situation like with front cover: there’s no logic which names label has decided to include. Credits from spine are quite useless when many releases don’t even include performers on spines. Sometimes credited names are only composers and sometimes only performers.

I personally hate to see people removing data added by other editors. It could have taken tens of minutes to add all opera performers (often adding new artists to MB) from the cover and then suddenly some editor decides to remove them because “there’s too many artists” (as I once saw on edit note removing data added by me). Since when it has been a problem of having too much data?


So many people use MusicBrainz, each for their own reasons. Each has their own opinion on which arguments are “good”.
Me: “ReleaseArtist string triggers bugs in my taggers”, "useful ReleaseArtist string for music files directory name"
You: "find and identify releases"
Someone else: "assign releases to specific artists"
The whole purpose of this thread has been to review different choices for what CSG/Release/Artist could say, in order to guide all of us to enter data that others will find useful.

The challenge for me was to persuade others that my reasons justified adding words to CSG/Release/Artist about length of the Release Artist string. It looks like I didn’t persuade enough people. The challenge for you is to persuade others that the Release Artist list should do a better job of helping you find and identify releases, and what words to add to the CSG/Release/Artists guideline to make that happen.

I am also a supporter of data, lots of data, detailed data. But MusicBrainz has many different fields and mechanisms. The data should be in the correct field, using the correct mechanism. The right way to include detailed data on all opera performers is by Artist-Recording performance relationships. The Release Artist list is not the right place for a detailed list of everybody. In my opinion.


Release Artist credits are helpful and necessary resource when identifying releases. For me the correct definition for release artist credit (classical) would be “artists as on the front cover” and there’s clear usage case for it: identifying correct releases. It’s making easier to find releases with current MB system because we can easily include artist names on release search.

For me it feels silly that if label has decided to include these names on the cover I would decide what is more important and what should be included. Current guideline is simple and good enough. It doesn’t force anyone to add all names but still gives opportunity for it.

There’s no way we could define and all agree which roles of the performers are more important than others. Spotify includes all the names why couldn’t we? Because we know it better? Or are we seriously caring about decisions of graphic designers? There’s smaller font for violinist performing violin concerto so let’s not include him! (even though violinist might be the most interesting data for MB users).

This is kind of interesting discussion but still I decided not to use my time for it. Now I feel that I’m forced to do so or people will instantly start removing perfectly valid data from releases.


Perhaps if no performers credited on spine its because relatively unimportant in therms of the release, more usually performers are included but only the most important. I think this is useful because ‘importance’ can only be gleaned from the release artist credit/track artist credit fields, the relationships are no use for this. In terms of a tagger having the release artist containing the same artists as the one you would index by if yo had the physical release is useful.

I Think MusicBrainz should capture useful real world data and then break it down and store it usefully in a way that it can be used, and the spine credit is useful.

But I fundamentally disagree with Jim complaints about the field being too long for his filenames. Even if release artist credit is too long for use in filename it doesn’t mean its too long to be stored as metadata so wouldn’t he want to store the full value in the releaseartist field of the tagger, and then within the tagger create a shortened version to use as part of the filename


I would love to do this, but as I explained above, I don’t think the MusicBrainz database and tagger interface provide enough control to shorten a ReleaseArtist string intelligently. Until that happens, I think the best course is to encourage human editors to shorten the string intelligently.

If someone can point me to a Picard plugin which shortens ReleaseArtist strings intelligently, I’d like to see it. I suspect it doesn’t exist, and at the moment, cannot exist.


Doesnt Picard have functions that can be applied to the metadata to create a filename, do you must you dont have enough information to make a sensible decision about the name. I have some sympathy with this as I have similar problem with my Songkong tagger I have commented on your list of requirements below

  1. I dont understand the first point, the release artist credit is provided as a list of artist credits, and within each artist credit the name credit can bue used to store a shorter version as credited.
  2. I think this would be extremely hard and laborious to do
  3. The artist credits are returned in an order, From CSG it appears that composer should be first (which it normally is on the cover) but it doesn’t make it clear afterwards.
  4. The webservice does allow you to lookup an artist, so once you have the artistids you could do more lookups to find aliases ectera, perhaps we need a shortname alias ? . But it would be alot of data to return it every time you looked up a release
  5. Release Date is returned in lookup


And when ‘that’ does happen, we go back through the thousands of releases that have been added in the meantime, and update them?
Manually re-enter all the data in the DB as a workaround every time something like this crops up?

There’s good reason why editors are standing by the ‘database first, applications second’ rule, because the above scenario sounds truly nightmarish. At the same time I don’t want to diminish legitimate tagging issues that you or other people are having, but if we have to make compromises - it simply can’t be on the DB end.


Help me understand, please. What piece of software provides the list of artist credits? Is it the Picard tagger script environment, the Picard plugin environment, the MusicBrainz Web Services API, or maybe something else?

So far I’ve only explored the Picard tagger script environment in detail. What I see there is are three strings: %albumartist% string, %albumartistsort% string, and %musicbrainz_albumartistid% string. I don’t see documentation about what Picard puts into the %musicbrainz_albumartistid% string when there are multiple entries in the ReleaseArtist. I see no tagger script facility to get arbitrary Artist data based on a %musicbrainz_albumartistid% string.

It seems to me that writing a Picard plugin is harder than writing Picard tagger script code. Writing a tagger to replace Picard is harder than writing a Picard plugin. But I’ve only tried one of those.


It’s the web service that was meant.


Yes, you were listing [quote] what I would want the database to supply[/quote] rather than Picard, I think the name shortening might have to be built into Picard done on the basis of the results of the webservice rather than as an external plugin to be doe efficiently but the %musicbrainz_albumartistid% should contain all album artist ids so could be used as the basis of the pluging.I think Picard also now add individual track artists one by one to the the artists field now like Jaikoz/SongKong, but neither currently has a separate field for albumartists


In Picard scripts, is there a way to specify the number of items in a multi-value tag to keep?

I use MusicBee for file naming, and it offers a $First() function if you just want the first item. But if you want more than one you can hack it with a $Split() function which allows you to pick a specific segment of the tag based on the split character. For instance, $Split(,";",3) would return the third Artist value (if there is one).


I don’t see anything like $split() in the Picard tagger script functions list. I don’t even see a clear statement that there is a multi-valued data type (list, array, or similar), but I do see hints that such a type exists.

In any case, $split() only helps reduce length if you know which items are top priority and should be kept, and which are low priority and may be dropped. I don’t know how to get that data.


One idea would be to have another metadata field called RELEASEARTIST_SHORT that the Picard developers could use when the standard releaseartist is problematically long, and that field could be accessed as a file renaming variable. But this field would have to be added at matching time use some logic as part of the core product so it doesnt help with your current woes but does it sound like a useful idea ?


What I think you are suggesting is that the MusicBrainz database provides two ReleaseArtist strings, one full, and one shortened by the MusicBrainz core. Picard passes both on to tagger script variables, and the tagger script can use whichever it chooses. It would help, yes.

I suspect that the code to generate the shortened ReleaseArtist string will be difficult in cases, because it won’t have information about which members of the ReleaseArtist list are more important and which are less important.


Yes thats right, in terms of the db by default the shortReleaseArtist would just be blank/redirect to the usual releaseArtist but it could be edited to be shorter, so maybe there could be an initial automatic population of the field but it could be manually edited as well for difficult releases. I was concentrating on shortening the artist names rather than shortening the number of artists but it could be used for both and I would suggest that Picard would just the value as is.

Actually I’m not clear how names should be added because looking at the links on the CSG to this release is credited to Ludwig van Beethoven when the cover just says Beethoven whereas this release just uses the surname of the composer and the conductor ?


I take two points from this: that some releases have Release Artist values that don’t follow the CSG/Release/Artist guidelines, and that the CSG/Release/Artists guidelines could be made clearer.

I think Release/0fa5e “The Very Best of Beethoven” actually points to a gap in CSG/Release/Artist guidelines. What I see on that cover is a Release Title, and no Release Artist credit. The name Beethoven is clearly part of the Release Title phrase. But, it is in a different font, so maybe it’s indirectly serving as a Release Artist credit as well. The guidelines don’t address this case. But if we say the Title is an indirect Artist credit, then (as I understand it) the Release Artist should read “Beethoven”, not “Ludwig van Beethoven”.

I think Release/ba355 “Dvořák: “American” Quartet…” has a correct Release Artist with “Dvořák, Tchaikovsky, Borodin; Emerson String Quartet”. The name “Emerson String Quartet” is for the performing group, not a conductor. The cover credits only the last names of the composers, so that’s what the Release Artist string has.


Yes I agree with that summary.

Could Artist Aliases be better utilized, I was thinking along the lines of a shortname alias type

if we look at aliases for Bach

we can see the following aliases all exist, and all could possibly be considered a suitable shortname that a classical music user might want but the search type doesn’t give such an indication making it difficult for tool such as Picard to make use of them.

Bach (1685-1750)
J. S. Bach


Curious which of those Bach entries you think should be the short name? I’d want “J. S. Bach”, but I’m guessing someone not familiar with Baroque and Classical music would want just “Bach”. That’s because there is also a C. P. E. Bach, W. F. Bach, J. C. F. Bach, J. C. Bach, and of course P. D. Q. Bach :wink:. They’re less well-known, though.

I’m not sure how we’d resolve those disputes. Unlike most of the data in MB, there isn’t an authoritative source (album booklet, score, etc.) to point to. And this sounds like something fairly contentious.

I guess maybe it’d work like tags, where they’re voted on. Especially if the tagger would always listen to your vote, even if you’re in the minority (though then you have to make a ranking as your vote, not just simple approval). This sounds like a lot of complexity.

Also, having non-stable names strikes me as a problem: you’re going to have to routinely retag the entire artist, otherwise he/she may get split in your music library (when the short name changes from “Bach” to “J. S. Bach”, etc.).


You are quite right that there is not a single short name, but there doesn’t need to be only one I was suggesting adding a new alias types since the examples I gave are already listed as aliases but just have the not very useful type search hint. Anything listed as an alias could be a search hint, but personally I would only consider a common misspelling to be specifically a search hint, some one would be better described as other things if we had more alias types such as shortname.