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