the guidelines are pretty clear here: since the name of the conductor (Giovanni Antonini) is not shown on the front cover he should not be included among the Release Artists. Whether Vivaldi should be included or not might be controversial ;). He is correctly liinked to every track with relationships. Based on the guideline the Recordings should be the performers (soloist, orchestra, conductor), already correctly linked with relationships. I made this correction with Edit #70262141 (and following)
BTW: There might also be the question, how Vivaldi should be added: Just as “Vivaldi” (like credited - even if it’s more the album title, but anyhow) or with his usual full name “Antonio Vivaldi”.
There is no detailed/strict rule for this. May people use the full name.
Especially for composer known with different names (often for transliterated names, e.g. Tchaikovsky) this might me not so easy. I tend to use also the composers name (and also performing artists) just like credited on the front cover, even if it’s without the first name.
Thanks for your feedback!
I do believe my irritation might be based on the visualization of the release: Directly under the album title is a line “Release by …”
Then there is is table with the title “Tracklist”. The third column is “Artist”. Now I know that its the Track-artist, who is listed here. But naming the column “Artist” is a bit confusing. Especially if you don’t first read the guide for classical music etcpp.
Hello, @henning65! You are asking good questions, and getting good answers. I just want to add, welcome to MusicBrainz, and thank you for your work to learn the rules for good data and for your contributions of good data!
@Jim_DeLaHunt: thanks for this compliment - I’m not sure I deserve it…
I do have a question based on my understanding why you introduces special rules for classical music in the first place: In classical music the importance of “works” and the “composer” differs significantly from other genres. I believe back in time - as there was no tag / metadata for work / composer available there was the desire - and than the decision - to structure classical music differently than other genre. By forcing the metadata TrackArtist to COMPOSER
software which calculates the AlbumArtist as the intersection of all TrackArtist automatically use the COMPOSER as AlbumArtist
software which calculates the AlbumArtist based on the first name in the metadata ReleaseArtist will also use COMPOSER (https://musicbrainz.org/doc/Style/Classical/Release/Artist)
(As MusicBrainz defines an Album to be a release, the ReleaseArtist might be used by some music software to gather AlbumArtist - not sure, if such software really exist)
software capable to handle multiple entries, are also forced by the ReleaseArtist to include Composer as an Artist
I think it might be time to get closer to reality and to picture with more accuracy the different roles. Lets put the COMPOSER into the metadataTag composer. Lets take her / him out from the ReleaseArtist and lets change the TrackArtist to the (list) of performers
Such a “purity” would make it easier for software developers to introduce support for multiple metadata in the first place: As now the COMPOSER is listed for each track in the fields “ReleaseArtist”, “TrackArtist” and “Composer”. If the music software generates a list of artist based on each field you get 3 times the same artist COMPOSER: from the field “ReleaseArtist”, the field “TrackArtist” and the field “Composer”. To handle such a chaos is simply asking software developers for music software to spend time (aka money) to deliver a “good” and “clean” database for a relatively small group of customers (return of investment approximately small)!
I believe its time to directly address music software developers and negotiate a sustainable solution.
Do I somehow describe correctly why there are “special” rules for classical music?
Do you agree that directly addressing music software developers might be a way forward?
I think you have grasped the essential pair of factors, though I might word some of the details a little differently. First, back in the early days of digital music files and metadata tagging — I wasn’t deeply deeply involved then, but this is my understanding — there were really only three metadata tags that mattered: Album Artist, Album Title, and Track Title. Metadata databases went through many contortions to fit more than three data types into three character strings. Second, while the pop music tradition emphasises performer over composer, and performance over composition, the classical music tradition values both composer and performer, both composition and performance. So, fans of classical music wanted different contortions to fit more data types into three character strings than did the fans of popular music. A lot of complexity and confusion has followed from that.
I think MusicBrainz has the right long-term solution to this: build a database which has a lot more data types and relationships than just three character strings; store the metadata in accurate datatypes with meaningful relationships, and let a separate “tagger application” convert that complex data into the three or more character strings for tagging digital music files.
I’m not sure which software developers you mean. In the MusicBrainz world, a number of skilled developers have made some nice pieces of software to let people take as much care with their metadata as the want to. MusicBrainz Picard is a tagging app with a powerful scripting system which lets you map from several MusicBrainz data fields into tags in a very flexible and customisable way. The Classical Extras plugin for Picard does a great job of bringing composer and work data into music file tags. There are lists of tools like The Classical Editor Toolbox right here on this forum.
You are are thinking about ways forward. That is great! You don’t have to start from scratch. A lot of people have been paving this road for a long time.
Waiting for actual substantial change in the player metadata support landscape is probably not too hopeful, the ID3v2.4 standard is almost 20 years old but still it’s niche compared to its predecessor despite actually solving quite a few issues.