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
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.
I think this would be extremely hard and laborious to do
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.
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
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.
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.
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.
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 . 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.
. Theyāre less well-known, though.