Discussing Musicbiz: Classical Metadata Style Guide

MusicBrainz Style
1

This styleguide appears to have been created so as to allow release producers to name their classical music products in ways that fit with stores’ processes and provide a good UX (user experience) for consumers of classical music releases, perhaps especially those using small screen devices.
To the extent that it is used by the industry it would make cataloguing classical music easier for MB editors.
I’m not clear how us adopting it would be improvement on the current Musicbrainz CSG (Classical Style Guidelines) that is used pretty successfully on Releases that were named using a very wide variety of methods.

(Though maybe a ISO-named pseudorelease for every classical Release would make classical music more accessible for consumers.)

Anyone want to put forwards other views?

2 Likes
2

I recently recommended this document in another thread. Good that you made it its own topic here.

I would find it especially important to finally put the composer in front of the album title, which is how Apple Music does it, by the way. What does the composer have to do with the album performer?

Another wish of mine would be to have a single album artist, because then a folder structure such as Apple Music or Swinsian create would actually make sense. So far, you have folders that are made up of several different names, often even the same ones, but in a different order, which again creates a separate folder. My suggestion would be that a soloist always becomes an album artist. If not a soloist, then the conductor. And if no conductor, then the ensemble.

3

Who says the ‘artist’ is the performer? The composer obviously has a much bigger influence in how the music sounds, and is traditionally given more prominence than in popular music (where performers usually pretend to have written everything themselves).

This style guide seems to be mostly written from the perspective of presenting a single release on a store page instead of a more extensive database, but without the composer as release artist, how am I going to find all releases with Rachmaninoff works for example?

3 Likes
4

@Hape40 Just wanting to check whether you can get what you’re after by changing the way that Picard tags your music files?
I think there are scripts that will have Tracks and Releases tagged ( and named?) pretty much the way that you describe.
Or is it the way that Releases are presented in the Musicbrainz Encyclopedia of Recorded Music that you want to change?

5

“… how am I going to find all releases with Rachmaninoff works for example?”

Hm, let me think – by using the “composer” tag maybe?

6

MusicBrainz is a database. The biggest sin one can make with databases is to put several different things into one field. It becomes inconsistent and you have to force your contributors to obtain certain rules of filling in fields. Sounds familiar?

The composer has his own tag, so why cramp him into the album artist field? “Oh, but you can write a script to pull it apart again as it is supposed(!!!) to be separated by a semicolon from the other album artists, which are divided between themselves by commas!” … except when they aren’t, like in the sort album artist field.

Imagine you enter a friend’s room and classical music is playing. You ask: “What’s that?” The answer will most certainly be like: “Beethoven’s 9th Symphony with Karajan.” – And you have all you need in a short sentence. Of course you could ask further to gather more information, but these TWO, not three bits of information are essential. Two because there cannot be an album tag with just 9th Symphony – from whom? It must be “Beethoven: Symphony No. 9”. The second bit is of course “Karajan” as THE one and only Album Artist. Because which orchestra he conducted in this particular release isn’t as important as the fact that HE conducted. Same with say a violin concerto: here the soloist takes the main attention, the conductor and the orchestra fade into the background (=artist field).

That is what I propose: to give everyone their own field in the database, as there are equivalent tags for them as well. And voilà: automagically audio players will handle classical music like it is meant to be presented, just like Apple Music does, but most others I’m aware of, too. No stupid scripts needed. Just make the database right.

Oh, and dare you to call MusicBrainz an “Encyclopedia of recorded music”? “Mess of recorded music” would be a better fit …

Edit: And I’m in tune with Apple Music and the rest of the classical music industry, exhibit 1 is the aforementioned document (look who has co-authored it!). MusicBrainz tries to re-invent the wheel here instead of just complying with best practices …

1 Like
7

I haven’t read the document, but I would agree that we should encourage proper usage of the composer field if that’s not what’s currently happening. Then, if someone prefers the existing Classical Style where the composer is at the beginning of the artist credit (?), then they can write a userscript to copy the Work Composer value(s) to the beginning of their Artist field. It’s less reliable the other way around (trying to separate the composers, conductors, orchestras, primary performers, and/or arrangers from the same %artist% field into discrete fields).

2 Likes
8

It is important to include the composer’s last name as part of the album title. Proper
formatting is also necessary

Isn’t that exactly the practice argumented against?

1 Like
9

Look at any classical album you want: There is always the composer mentioned with the work(s). Now you can say: “See, the composer AND the album title!”, but I say the composer IS part of the album title, because you don’t even have an album title when it only says “Symphony No. 9”. There are dozens of ninth symphonies from dozens of composers. That’s the same as printing Dollar bills without mentioning “Dollars” only saying “100” – 100 what?

To make it even clearer: Sometimes you have additional composers on an album, who aren’t mentioned on the cover. They can easily mentioned at the track level for each track, but don’t appear in the album title if not mentioned on the cover. IF several composers are mentioned on the cover, THEN MusicBrainz already advises us to suddenly put them into the album title nevertheless: “Beethoven: Symphony No. 1 / Brahms: Symphony No. 2” BUT just “Symphony No. 9” when it is the only work on an album. THAT is inconsequent, isn’t it? My argument is to do it the same way as well with only one one composer AND to use the composer tag as intended (on the track level) AND to not cramp the composer into the album artist field AND to restrict the album artist field to just one name for structural reasons regarding the folder structure that music softwares generate. Again: all the other artists besides the ONE album artist should be mentioned on the track level, not the album level.

1 Like
10

Just wanted to point out that an argument chain like “There is already a special field for composer. Putting several data into one field is the biggest mistake. It forces users to follow certain rules. Hence I propose the rule to put the composer at the start of the album title, followed by a colon.” has some flaws :wink: When I started to read your comment I was originally assuming you were arguing against the composer in title.

There seems to be some general agreement here that the composer of a work for classical is so important that it deserves some special handling. If that’s true, we can let the “only use the dedicated composer field” go down the river. So for me the following questions would need to be answered:

  1. Why is the composer field not enough?
  2. What are the advantages of crediting the composer as an album artist? What are the downsides?
  3. What are the advantages of putting the composer into the title? What are the downsides?

I think for 1. there is a broad agreement anyway. All the release information is incomplete without the composer, and the composer usually appears quite prominently on the cover.

For 2. I’m personally not sure and never fully understood it. One argument might be that artists are well supported in players and music can be easily sorted by artist, and since users want to listen to music of specific composers that makes it convenient for them. But I always was against compromising data quality for tagging needs (see also below), especially as this could be easily solved with the composer field when tagging. Another argument might be to get the releases listed on the composer’s page. But here I’d say for a classical composer, especially the ones who died before the age of physical music media releases, the relevant list is their works page on MB.

For 3. I see an advantage. The release title is usually a name for the entire work, and without the composers name this does say nothing, as you already noted. And the composer is already prominently shown on the cover. I also think that the composer name and the work title are the two most important pieces of information, with the performer having a secondary role. For the example above if someone asks “What’s that?” the answer “Beethoven’s 9th Symphony” might already give the most information, and it might or might not be followed by the “Who’s performing it?” question. So to me it makes sense to keep composer + title together.

Which, btw., I find better suited than “Beethoven & Brahms: Symphony No. 1 / Symphony No. 2” as that document would propose.

This is a point were I strictly disagree. Following this would mean that a release like Release group “Symphony no. 5 in C‐sharp minor” by Mahler; Rudolf Schwarz, The London Symphony Orchestra - MusicBrainz does not get credited to the London Symphony Orchestra, and the release does not appear on the release list at https://musicbrainz.org/artist/38712b4c-0fd4-4c65-8c7a-45676fecc973 . If there is a conductor, an orchestra and a soloist just applying some random rule to pick one and let the rest fall under the table seems odd. Especially if the argument is for file folder structure. I’m really against making such heavy compromises on the data just for some special file metadata needs and music player limitations. And even for the use case of folder creation people likely will disagree if they want a certain release have listed under the orchestra or the soloist.

Why not also follow the above discussed document for this? That guidelines puts quite some emphasize on crediting all performing artists.

4 Likes
11

I agree.

Ok, you convinced me.

12

I’m looking at what changes are being discussed on this thread, what claims are being made, and then considering how they’d impact a MB encyclopedia Release page.

I don’t see the mess that the encyclopedia is claimed to be when looking at that Release page.
Nor any benefit in changing the names of the track titles to include Composers.

This has me thinking that the current discussion is about the use of the MB db for the purposes of tagging. Tagging is a worthy use of the db but far from the only use of the database.

Just from hanging around on these forums I’ve got the impression that the addition of a “the CSG have been applied to this data” flag/tag to the db would allow the conflict between the traditional record shop categorisation method for classical LPs and the use on displays by digital playback devices of a categorisation standard that suits pop music to be resolved automagically for people wanting to tag their classical music. And would make entering classical Releases into the db more accessible for beginners Editors and quicker by removing the “replace performers with composer as track artists” step.

1 Like
13

The problem is much more fundamental. It is always said that MB is “more” than just a tagging database, a real encyclopedia. And that it would be disapproved to “bend” database entries to tags. But the whole database is bent towards tags right from the start. This becomes particularly obvious if you look at it from the point of view of classical music. Everything in here is thought from the original perspective of the first rudimentary player software, as you can see from the lack of a composer field in the database - because at that time there was no composer tag integrated in any player software (let alone hardware). With works and movements it is the same. (That only came with iTunes just recently.) Likewise the artist-albumartist-performer confusion. That too comes from pop music and the early days of player software. So don’t anyone tell me that MB’s claim to be an “encyclopedia” has any merit. MB is just as much of a muddle as freeDB, but with inflated self-confidence. Well, I admit, the part of the database dedicated to canonical works, where recordings are linked to standardized catalogs of works, that part still comes closest to an encyclopedia in terms of its concept.
The biggest sin with databases is to squeeze several different pieces of information into one field. And that is exactly the case here. (Think alone of the track title field!) Someone would have to finally take care of basic birth defects, instead of sticking always new patches over it with ever new style guidelines and thus discouraging new contributors. A good user interface can neither be replaced by style guidelines nor by discussion forums.

14

I’m not seeing you having pointed out any mess or problems with encyclopedia page I linked.
Can I take this as you agreeing that page was good enough and doesn’t need to be changed?
If so we can agree that the current db layout works ok for an encyclopedia.

Which leaves the complications in device display, tagging and editing, caused by the use of historical standards to decide how classical recordings are to be entered into the db to be considered.
I’m pretty sure that this has been considered in the past but having a fresh look at it now is something I support.
Though it would be easier to reconsider this if we are clear that renaming the tracks on encyclopedia classical pages is not being proposed.

15

Oh, you wanted me to judge this particular page, if it fits my claims? Sorry, I didn’t apprehend it that way. – Yes, why not? This entry seems to be ok.

You asked another question, if there was a need to include composers into track titles. Although I know that some hardware library players handle it this way, I personally didn’t propose it, and I can live without it.

My point regarding track titles would be that a consistent naming scheme (not only for track titles, but globally) within the database could be easily achieved by getting the user interface right, finally:

Look into the above mentioned document again:

Beethoven: Symphony No. 3 in E-Flat Major, Op. 55 “Eroica”

They divide it into “Composer”, “Type of work”, “Number”, “Key”, “Catalogue” and “Name”

But it isn’t a division into categories, the whole term is a composition of categories that together make the track title string. From a database point of view we have 6 entires, not one. And these 6 entries are applicable to most of classical music (which is all I am familiar with). Let one or two be empty for some works, like “Name”, and have a few others in reserve for special needs, like with Opera, where “Act” and / or “Scene” may be needed. But make everything that is its own category an entry in the database and make an input mask for each of them! All the hassle with English, German, Italian etc. keys (C minor or c-moll or do mineur?) are instantly gone! All you (not you personally, of course) as the database programmer have to do, is to provide translations for the 24 keys in all supported languages ONCE – in a drop-down-menu. With another drop-down-menu (or a toggle in Picard’s preferences), the contributor and the user can chose their language and the order, in which they want to compose the string – and automagically they get what they want without scripting or guidelines – every time and for all their music, consistently. Contributors can only chose from dropdown-menus, no typos, no alternatives, just the set of possibilities they have chosen with their language. The output for someone else might vary, as everything is pre-translated in advance internally. For example: German and English require a “in” in front of the key, like “in C minor” or “in c-moll”. Others not. So the “in” isn’t optional, but is inserted if the language is set to English or German. Other languages don’t insert (or even show) the “in” at all in the input mask. I hope you understand what I mean. This way all the trouble with guidelines and inconsistent data and discussion forum questions would instantly disappear. Don’t give the user of a database any chance to decide something by themselves! Everything can and must be standardized and the input mask must have crystal clear fields to fill in. In MusicBrainz there already IS a lot of stuff just like I propose, like in “Year” one can only type in digits and there must be four of them. Or the barcode is checked for plausibility. Or artist- composer- or orchestra names have to be chosen from pre-existing ones or have to be created elsewhere once and for all. This is the way a database should work! But as soon as one clicks to the next page with the tracks, the mess begins …

16

You are really always arguing one way, and then proposing things in contradiction to your own arguments.

You claim MB is just trying to cram data into a structure for the “first rudimentary player software”, yet you propose to follow a guideline that attempts to cram all the data into the rudimentary structure provided by music store fronts.

You (still) claim that “the biggest sin with databases is to squeeze several different pieces of information into one field”, yet you propose to do this by putting the composer into the album title. Hint: Your claim is wrong, it always depends on the specific use case. As you somehow intuitively seem to acknowledge by your proposal.

Everything in here is thought from the original perspective of the first rudimentary player software

CDDB did that, it has a field for album and artist, and a list of track names. Because that’s what the “first rudimentary player software” supported. MBs structure provides much more, with detailed relationships. Even today it provides more than even sophisticated players support.

That’s wrong, and you should know that:

grafik

And that’s also why your claim that MB is sticking composer information into the wrong field is wrong. There is a dedicated composer field, so identifying who is the composer is easy. The point of having the composer also in the album artist (or in the album title instead, if we’d follow this discussion here) is not to have a place to store the composer. It is to properly provide credits and make releases identifiable by the top level data easily. And that’s not even something that “comes from pop music and the early days of player software”. This is basically a thing since music gets published. Both the ones who sell the music and the listeners want to know who’s music this is. The very vast majority of releases (including classical) quite prominently credits various people on any release. And this usually involves the most important ones. And who to credit for an entire release can not just automatically generated by all people somehow involved on each separate recording.

What exactly is that?

Now we are shifting topics again. But just one thing to remember: A more sophisticated database structure and a better user interface are two separate aspects.

I guess you’ll have far more fields then, e.g. you need to consider Should Track Titles Include Attributes (Ragas, Countries, etc.) + Carnatic/Hindustani style guidance . And not sure about Jazz, but the Jazzers might have something to say also how they want things formatted.

6 Likes
17

OH! There is a composer field in the DATABASE! (<-Sarcasm! I knew that already.) And where do you fill it in when adding/editing a release? In some random “artist” field, together with all other artists.

I was speaking of the USER INTERFACE and you are telling me that there is a field in the DATABASE. The Database isn’t my business, I’m not the server admin. The only thing I see is the UI, and it is a mess! And internal there must be a mess too, because everyone and their mother gets a dedicated field, but the user has to link everything together himself. (Works from the internal canonical catalog with tags from the release he edits. That should be ONE, at least under the present circumstances, where text from the cover/booklet is overruled anyways by some random guidelines. – Once, years ago, I supposed to copy the text of the booklet letter by letter in order to have the original tags of the release, which people expect to get when they just auto-tag their ripped CDs, but no, the guidelines must be followed! Ok, then why do we have a canonical work catalog at all? And why do we have to link them together by hand? My proposal today was to take the catalog and make it the only way to enter data by drop-down menus and presets.)

and THAT is exactly why this database is such a mess! MusicBrainz wants to be everything to everyone (“Encyclopedia”!!!), but instead it has become one big mess …

18

A big shame to lose an editor with so many edits - I think you should expect some debate and discussion when you raise modifying a massive database structure :thinking:

Nonetheless, would be great to see you back someday Hape40.

Edit: agreed that the MB UI languishes overall. But should we expect more from a project borne and carried by the passion of devs? Over the years I’ve become more grateful for what we have here.

4 Likes
19

With the dropdown menus with very limited ranges such as (known) Composer, Work type, Work name, Series number, Hape40’s approach would provide a good ways of rigorously defining each track and release and having it displayed on small screen digital devices.

If there is a big market for this then MB could fill the demand. Personally I’m just interested in this as a technical learning opportunity.

But there are many Releases/tracks out there with very incomplete metadata available. These releases would seem to be even harder to distinguish between if limited range menus were used.
Ie (Unknown composer): Aria performed by (Unknown) is less distinguishable than say (Unknown composer): Aria, crotchet=93 performed by (Unknown)
Which has me thinking that a “machine title” is not suited to an encyclopedia.

A lot of us are under a lot of stress from a pandemic. Wishing you all well and enough space to be kind and gentle with youselves and others.

2 Likes
20

Anyone know what the market size is of people who’d want a Hape40-style name for all classical tracks in the MB database?

If it is sizable then providing it could increase the MB user base.

( ? One extra field in the db for each track. If it contains data then that signifies that CSG has been used. And the data would be the Hape40-style track name. ?)