Wouldn’t it be a fairly trivial schema change to allow this field to be empty?
1 Like
I think very few people would be happy with that.
As far as editing goes the problem is that the Track Artist is always different to Recording Artist unlike non-classical releases.
Probably, but it would have a big effect on every single application of our data down the line, from Picard (easy to change) to any of the others we have no control over, so even if technically easy, it’s socially/environmentally very complicated 
1 Like
Why so? All the data could be generated from relationships and put in the right places if so desired. As far as I understand, that’s for example what @MetaTunes’ classical plugin for Picard does, and it seems to work fairly well.
A classical release without any relationships is IMO pretty close to worthless, you kinda might as well just use freedb by that point. But with all the relationships there, that’s a level of detail almost nobody else has (allmusic, sometimes, but they’re not always too good at it). Which is why we really need to direct classical editors towards relationships more
2 Likes
Yes it can and I use them in a very similar way in SongKong/Jaikoz as well.
But look at the answers on your How to help people with classical editing? - #14 by mmirG post, the majority complain about the UI and the difficultly of adding relationships, because adding a relationship is more difficult than simply filling in a field that has been presented such as Track Artist. So using more relationships (at least with the current UI) is not going to make things any easier.
Similarly it is more complex for applications to try and decode relationships than just use the standard fields. All music players have an album artist and track artist fields and these need a value, including for classical so make sense for MusicBrainz to at least try to generate these values.
And I do not agree there is no such thing as a Track artist for Classical, there is. It just isn’t a single person, it comprises the Conductor, Performers/Orchestra/Choir on the piece.
1 Like
In that case, we could do the generation somehow. My main feeling is that if you make people add all this info by hand to the track artists (in all cases where they wouldn’t equal the release artist, which are many), and then you ask them to add the relationships, the reaction would be “didn’t I just tell you all this? not again!” - I’d much rather have them add the relationships and then try to generate artists. Maybe even pre-fill them for them, and ask them to change them if anything looks wrong (which I understand is basically what you ask for at the How to help people with classical editing? - #10 by ijabz post - and it’s a good idea in itself!). The problem with all this is mostly manpower to both write and maintain this UI 
3 Likes
Fair point. I suppose an alternative hack would be to have a special-purpose artist called None or something…
Does it make ontological sense then to associate a release with someone who had nothing to do with the release itself? Come on.
On the second point I agree: I want to add the info only once, namely in a structured way as relationships. The need to replicate that info in a poorer way into those artist fields which are there for historic sentiment or whatever doesn’t make any sense to me. That is wasted editor time and an additional source for errors and inconsistency. Again: If those artist strings are really needed, then automatically and dynamically create them as read-only strings from the relationships. If needed, enhance the relationship framework (like adding an “important performer” checkbox).
Also, consider searching for all recordings with a certain performer. Currently, I always do that twice: Once using the artist field, once using the performer relationship. In the end I get two overlapping lists which I mentally have to merge somehow. This is because of that stupid data duplication which naturally is done in various inconsistent ways by different (inexperienced) editors.
Everything would be so much easier if there was only a single place for adding and searching for that kind of info.
Moreover, when the relationships are the only place where you can add the performer info, people are forced to use relationships! Combine that with a more relationship-friendly UI and your (very valid) point
should improve significantly.
2 Likes
FYI, this is not just a problem that I see, but others as well
and its causing the Roon community to view MusicBrainz as having an inadequate understanding the basics of classical. This is a shame because MusicBrainz has the database structure to support Classical very well, but just a few problems hold it back.
Roon is rated very highly in hi-end audiophile community because they generally add very good metadata to customers music collections (including from MusicBrainz), and make it look very nice. Whilst I think it is rather overrated MusicBrainz would do well to not ignore them.
To reiterate the faults as I see it
- MusicBrainz use Track Artist/Recording Artist completely differently for Classical releases whereas for Pop/Rock Track Artist is just a refinement of Recording Artist
- There are also far too may releases where the composer is still set as the album artist. I know this has been nicely resolved for some composers with the classical cleanups, but its a shame a more automated approach could not be used to get this done quicker.
- MusicBrainz expects users to input data differently for Classical but:
- make it difficult to add the extra data for Classical
- don’t set any flag so that readers of the information know they are looking at a classical release that has been entered using the classical guidelines (rather than a non-classical release or a classical release that has been entered with non-classical guidelines)
1 Like
1
I don’t understand the claim we use the track artist differently on classical. Just like on non-classical, it’s the person(s)/groups principally responsible for it.
2
It’s also typically the most prominently credited person on the release for the track. Here is a random album I grabbed from my collection (literally; I ran mb-open-release "$(find -type d -print0 | shuf -z -n1)"/01.*.flac and grabbed the first one with an uploaded booklet — the third one it opened.*)
Everything is uploaded to CAA, here is the most detailed tracklist:
Those tracks are clearly credited to Howard Hanson (the composer), not the Seattle Symphony, Seattle Chorale (7–11 only), and Gerard Schwarz (the performers).
You would be hard pressed to find a classical release where the non-classical track artist guideline “[t]rack artists should follow the release artist, except where another artist is credited in the track listing of the release. This can include various artists releases, featured artists, and tracks credited to another artist” would not result in the composer being the first, if not only, artist listed.
3
Currently, it let’s us store a credited-as name for the composer — which we otherwise can’t. The tracklist often uses a fuller name than the front cover, so the release artist doesn’t work for that (not to mention some releases don’t have all the composers on the cover). And the composer on the work entry is shared across all recordings of that work, so we can’t do it there either.
(There of course exists a similar problem with the performer AR credits, but it’s much less of an issue since recordings are far less shared than works.)
*mb-open-release is a trivial script I wrote:
#!/bin/sh
if [ -z "$1" ]; then
echo "Usage: $0 file.flac" >&2
exit 1
fi
tags="$(metaflac --show-tag=MUSICBRAINZ_ALBUMID "$1")"
if [ -z "$tags" ]; then
echo "No MUSICBRAINZ_ALBUMID tag found in $1" >&2
exit 2
fi
if [ $(echo "$tags" | wc -l) -gt 1 ]; then
echo "Multiple MUSICBRAINZ_ALBUMID tags found in $1" >&2
echo "$tags" >&2
exit 3
fi
alid=${tags#MUSICBRAINZ_ALBUMID=}
xdg-open "https://musicbrainz.org/release/$alid"(and yeah, sorry that I haven’t found time to contribute code to MB, despite being an actual Perl developer… someday…)
4 Likes
Let me try again, we are not talking about the release artist here. For most non-classical albums the track artist is the same as the recording artist field, for most classical albums the track artist is different to the recording artist.
Or look at it another way, the recording artist should always contain the principal performers for that song, but sometimes the same recording is credited slightly differently on a particular album, most commonly the persons name is slightly different, or sometimes a minor performer is credit/non-credited, and this difference is captured in the track artist
But for Classical this difference is not captured, instead we are told to just enter the composer, even though usually the composer had nothing to do with the actual recording/performance.
This is a clear difference, and what makes it such a pain is that the recording artist is what people want to see in their Artist field (or ideally the recording artist as captured for the recordings on the release, but unfortunately we don’t store this for classical), they dont want to see the composer, there is already a separate composer field.
And unfortunately, the recording artist is not always entered correctly, as it is alot more fiddly to add the recording artist then to add the track artist. Consider this for the moment, most tagging software that uses MusicBrainz will end up putting in the composer as the track artist for classical music. This is not what users want and the blame really lies with MusicBrainz for having a poor default mechanism for track artist. I have done alot of work with SongKong to extract a suitable value for Track Artist but it really is not easy with the way MusicBrainz is setup, and often MusicBrainz does not actually include that information so is not available.
2 Likes
Given the composer was chosen there by community choice, I’d imagine quite a few people do specifically want to see the composer in the artist field.
Most software that uses MusicBrainz and has an interest in classical music should be using relationships to fill both composer and performer fields. If tagging software is mediocre for classical (which it probably is, Picard included), that’s not directly our problem as a database, as long as the actual information is available, which for a correctly entered release it is. Our job is to make the relevant information available. If the relationships are not used properly, then the tagging will always be mediocre, so I see absolutely no point changing the way we do things for this - and the way we do things is the most useful for MusicBrainz itself.
3 Likes
That decision was made a long time ago, and I suspect by a very small group of people, what may have been right then doesnt mean still right now.
- Surely it is MusicBrainzs responsibility to have a sensible database and currently
- from a Database point of view using the way you use trackartist/recordingartist is wrong, it is inconsistent and it means not capturing info that can be captured for Pop/Rock.
- from Database point of view storing Composer as track artist is pointless anyway since already have composer relationships.
- The UI to the database make it hard work to enter relationships easily.
- Mediocre taggers are not your responsibility, but if the relationship data is not there because the UI is poor then that is MusicBrainz responsibility. and as previously discussed (and I think you agreed) if MusicBrainz provides no way for taggers to identify if released entered CSG then again that is the responsibility of MusicBrainz not the taggers.
It is not just me who thinks this, its a common complaint on Roon, I don’t know what you know about Roon but they do have users who understand Classical very well. There does seem a great resistant to accepting there is even an issue, despite the evidence
1 Like
Right now there are officially “genre: classical” tags in the web service, FWIW, which should be a good start to know that at least for releases / RGs tagged that way it makes sense to assume CSG. Not saying that’s a perfect substitute, obviously, but it’s a start
Does it? It does, admittedly, make it non-obvious that they’re a thing you should add, but I don’t think adding them once you know this is difficult. Linking to works is the only slightly more difficult part (without userscripts) - I’d be happy to see something like the @loujin Guess Works userscript adapted to include in the default UI.
I’m not really claiming the current way we store things is ideal. It might very well not be ideal: as you probably know, my personal preference would be not to even have track and recording artists as a concept for classical, which is probably quite different from your personal preference, but means I also don’t think the current situation is the best it could be.
I just haven’t seen anything that suggests changing what’d certainly be over a hundred thousand releases to adapt to a different track/recording artist choice would be useful enough to be a good use of anyone’s time. The same time being used to add proper relationships to releases missing them would be infinitely more useful for MusicBrainz itself and for the use any tagger wanting to take classical music seriously. And if the time wouldn’t be taken to change them all (or most of all) properly, we’d end up with another in the middle situation which would be bad for whoever wants what we have now and bad for whoever wants the alternative.
Yes because the tracks page with track artist (that gets propagated to recording artist) is a standard part of the release editor, and you can you seed a release to add the releases with tracks, but you cant use it to add relationships.
I think the trouble with generating from relationships isn’t it doesnt allow you to capture the joining words and order, but I may be wrong about this.
To do it manually would be quite ridicolous, but to amend the guidelines and programmatically set track artist to be same as recording artist would be a good start, and that would fix track artist where the recording artist is set correctly
Any progress on MBS-211 would help in so many situations
Then it would be clear where recording artist/track artist is not set correctly and manual editing required.
But the point is not really how it is done, I’m struggling to convey the problem with the recording/track artist because replies from MusicBrainz are along the lines of there is no problem rather than there is a problem but we don’t want to fix it.
The thing is, you’re bringing up multiple problems, but their solutions actually conflict with each other.
You seem to want the track artist to be the performers, which is a perfectly valid option, if different from the one we currently chose. It does, admittedly, match the definition of “artist” tagging fields more closely. It also hides composer information more while bringing more visibility to performer information, which can be desirable (in one-composer releases with multiple performers), equally unimportant (on releases where there’s only one composer and one set of performers) or less useful (in one-set-of-performers releases with multiple composers). I do not think this is necessarily a worse choice than composers, but I also do not think it’s a clearly better choice.
At the same time, I understand that you want the track artist and recording artist to follow the way it’s done in the rest of MusicBrainz. You seem to think that means the same as the previous point, but as @derobert explained earlier, that’s not true. What that would mean is that we would credit for the track and for the recording whoever the tracklist has listed, meaning:
- For most releases with multiple composers, the track artist would still be the composer, since they’re who is usually specifically credited for the track on the tracklist.
- For most releases with one composer and multiple sets of performers, the track artist would be the performers alone, since they’re who is usually specifically credited for the track on the tracklist.
- For most releases with one composer and one (set of) performer(s), the track artist would be effectively the release artist, since each track is unlikely to have an artist marked - so composer and performers both.
I don’t think anyone actually wants this inconsistency for classical, even if it would actually be more consistent with the usage in the rest of the database.
The only change that I feel would bring an actual improvement to both information storage and navigation would be to make track artists basically equivalent to release artists: “Track composer; Track performer 1, track performer 2… n”. It would also make editing more complicated though, by requiring selecting multiple track artists for basically every single classical track - I’m sure a better UI would help with that to some degree, but it would still be annoying. I’m convinced this would be at least somewhat better, but unconvinced the benefits are worth the annoyances, and fairly sure the benefits are not worth the effort of changing everything now.
So, there might be a problem (there’s certainly a problem for some people, there’s certainly no problem for others) but I’m not sure I see a reason to try to fix it in any of the proposed ways.
You bring up another problem that does exist and should be fixed: relationships are not obvious and many people do not enter them, even when editing classical music. I expect once our design work reaches editing interfaces, this will be something we will put extra attention towards. In fact, unless I have left MB for some reason by that time, I can guarantee I’ll work to get attention on this issue, because every release that gets added without relationships is a release I** need to fix later.
** Or one of a smallish group of people who actually clean up existing classical content and do a lot of good work, if you’re reading this you probably know who you are, thanks so much for your work.
3 Likes
Okay I see where you are coming with this, but I dont really agree with @dreoberts analysis of the album, on the front cover its credited to Seattle Syphony and Chorals and Gerald Scharz (conductor). You can argue that is its credited to Howard Hanson, or that is just part of the title., i.e I would read as Howard Hansons Symphony No, 6 & No .7performed by Seatle Symphony and Choir, conducted by Gerald Schwarz,
But on the back it is not individually crediting Howard Hanson as the track artist, its simply repeating the title and showing the movements for each symphony under each.
Basically they havent explicity credited the track artists, but they can be simply derived by listening to the music.
So just like Pop/Rock each piece of music has performers, and often they are same on every track and quite often they are not which is why we need track artists. But the problem is that classical releases they are quite slack about actually crediting at a track level, it often has to be derived.
So taking what is written too literally leads to the three inconsistent meanings you specify.
So my preferred option is to take the RecordingArtist as the basis for TrackArtist but allow for when intentionally on cover they credited artist slightly differently, but when they don’t bother to individually credit at least main performers I don’t think that should lead to no credits. Taking this approach is almost the same as Pop/Rock rather than completely different.
Should we include composer as well as performers as track artist or not, I tend to think not then very easy to keep recordingartist/trackartist mostly the same but I don’t have such a strong view about this. The problem is only having the composer, and therefore not having an easy way to add the main performers when creating the release.
I think this would be a welcome improvement, would it be more complicated to edit though, i don’t think so.
For one thing track artists default to release artist so actually for many releases would start of correct rather than having to modify them to only have composer. And the if do further edit for recording artist we would only have to delete the composer. much easier than having to enter all the performers .
Musings, if we didn’t include composer at track artist or release artist level then things would be much simpler to enter, because in many cases all three values would be the same. But of course composer very important so what we really need for the composer to be able to be added as part of the ui edit so easy to add to fro release and tracks (and then stored as relationship)
And for there to be a Composer Search like Artist Search, and a way to view all releases they have composed rather than performed on. But all that is a very major task.
1 Like
(I really ought to edit this down some, but I even more really ought to go to bed. So, sorry!)
If the composer is not the person most responsible for what you hear at a performance, then, well, you’re not listening to classical music. The now, what, thousand-year long practice of musicians trying to realize the music envisioned & recorded by the composer is sort of fundamental to the classical tradition.
Or: the composer often isn’t in the room; often isn’t even among the living. But the composer still is mainly responsible for what you hear.
Well, first, some people don’t want to see the composer there. Some people (myself included) do. But you’re talking about tagging. How you map MusicBrainz database fields to FLAC/MP3/whatever tags is up to you (and there is, by the way, a separate performer field, too).
And in the MB schema, there isn’t another place for the composer. It’s the only place we have to even get close to crediting the composer as he/she is credited on the release, the recording artist & advanced relationships often work (or at least well enough) for the performers. And that matters quite a bit; e.g., there are a lot of ways print Tchaikovsky’s name.
It’s only wrong with the definitions you’ve made up for the fields, which aren’t the ones used or documented by MB. Your alternative means we instead couldn’t capture other info (the composer). And… if it’s different than pop/rock, well, so what? They’re different music traditions with different requirements.
That’d be awesome, if we had three-way relationships to give artist credits per-release even on works & recordings (e.g., a work-release-artist relation).
The joining words are hardly ever there/important for classical releases. Order is—rarely—but probably we could have ordered relationships there (like we do for works). (Grouped ones would be more useful, really).
I agree there is a problem in that we can’t store the credited-as field for performers when a recording is shared between multiple releases and the releases credit the performers differently. And I agree your proposed solution would fix that, but I think (as pointed out above) creates far worse problems. @reosarevok’s alternative of putting both composers and performers would work (except for, as he points out, the amount of extra work and the significant transition costs).
Please go fix https://musicbrainz.org/release-group/055be730-dcad-31bf-b550-45ba9c202aa3 then, that’s currently credited to something that’s just on the cover as the title. Seriously, of course, we’ve decided in MB to not treat that as part of the title, and even if were part of the title, it can be a credit too. There are some release where figuring out exactly which words on the cover are the title is hard — this isn’t one of them.
I think you must have very limited experience with entering classical releases. Changing the album credit to just the composer is trivial; you click edit, hit the X button a few times, and check the “change all” box. If an entire release has the same performers for all the tracks, it’d save maybe 30 seconds, tops. But when a release doesn’t (which is common, it applies to that Hanson release, which remember was picked randomly) then the edit relationships page is much nicer. For one thing, you can select multiple tracks to add an artist to at once; you can’t do that in the track editor. The tracklist also has width limitations (the field is only wide enough to hold a few artists; more is common on classical) which the relationships editor does not. And you can more easily save partway through the relationships editor.
2 Likes
I said
even though usually the composer had nothing to do with the actual recording/performance
i.e they were not involved in the recording, they didn’t decide to record this version of their music with this orchestra, surely you must have realized what I meant here !
Ive already explained this, you are using the same database field for different things, and you don’t store what method you are using in the database, this is just database basics.
You seem to be saying we must store the composer in track artist so we can can capture how displayed on the release, but its unimportant to capture how performers are displayed on the release. This seems to be quite a simple understanding of classical, i.e composer v important, everyone else less so.
With the current system you have to enter the composer for each track, but then enter performers for each recording then submit release. Then we have to use the relationship editor to edit relationships for each recording, so there alot of duplication and it is clunky.
The fact is that no-one thinks MusicBrainz is good for classical apart from MusicBrainz editors.
1 Like