Proposed clarifications to CSG Style/Classical/Track/Title

classical
styleguide
Tags: #<Tag:0x00007f23c3f9fc70> #<Tag:0x00007f23c3f9fb08>

#1

Despite having a lot of experience with the Classical Style Guide over many years of its evolution, I recently made a mistake by failing to include overall work title in track titles for a classical-style Release entry which I updated. And, I had taken the trouble to check the relevant CSG, https://musicbrainz.org/doc/Style/Classical/Track/Title , but I still made the mistake.

So, of course, I blame the wording of Style Guide. It couldn’t be me that is sloppy, could it? :wink:

It says in that Style Guide:

“Titles on classical releases should mostly follow the printed information, with any changes required by the language-specific classical guidelines. Note that many classical releases have a less detailed tracklist at the back and a more detailed one in the booklet. When choosing titles, it’s generally better to follow the more detailed one, if available.” and “Do list [details…] if they are included as part of the titles on the release, but not otherwise; that information is already available at the work level, so it doesn’t need to be forced into the track titles if the release doesn’t include it…”

I missed the part lower down, where it says, “For groups of tracks that are marked as part of a full work (with e.g. a header), add the full work title (as listed on the release) to all tracks from the work….”. If I had found this text, I would not have made my mistake.

But I think this is poor writing in the Style/Classical/Track/Title guide. The initial paragraph says “No”, and the lower section says “Yes”. The initial paragraph should say “Mostly No, but Yes for inserting work titles”, and the lower section should say “Here is more about the Yes”.

So, I edited the Wiki with a proposed change to the wording of this Style Guide. See the proposed new wording and the changes I made.

The introduction now does a better job of summarising the rest of the Guide:

Titles on classical releases should mostly follow the printed information, with addition of overall work title to movement tracks, and any changes required by the language-specific classical guidelines. Note that many classical releases have a less detailed tracklist at the back and a more detailed one in the booklet. When choosing titles, it’s generally better to follow the more detailed one, if available. Don’t add extra work information (key, catalog number, etc.) that is not in the printed information to the track title; that detail is completed at the Work level.

I also moved the Work Title section to the top of the Guide. I changed the phrase “full work title” to “overall work title”, because I think “full work” might be open to misinterpretation in this context. I clarified the wording of the first paragraph of the Work Title section.

I do this proactively because I think this is how the MusicBrainz process now works: this is a Style Guide editorial improvement, not a rule change, so it is OK for Editors to “be bold” and edit the wiki. The leadership has a chance to accept, improve, or reject those changes before letting them into the official docs. If I am misunderstanding the documentation improvement process, I apologise, and please point me to the instructions for what I should have done.


#2

My initial take on this is that it is a useful clarification. It is helpful to have the a work title as part of the track title, but not if it is overloaded with stuff that isn’t on the release. FWIW, users of the Classical Extras plugin can choose between the track title and the MB work names as a source: if “title” is chosen, the MB work structure is used to infer a structure in the title name so that work and movement can be automatically populated from the title, assuming it is completed acccording to the CSG.


#3

Hi, @MetaTunes, thank you for taking a look at this Style Guide wording proposal.

And,

True. However, the Classical Extras plugin only affects what gets put into the metada of digital music files on a user’s own computer. This Style Guide is about the contents of the database entry in MusicBrainz, which has the primary duty of describing the Release.

Over MusicBrainz’s history, there has always been a seductive lure to adjust Release entries so that they will be easily reusable as metadata for digital music files with little effort by the tagger software. MusicBrainz has been moving more and more to resist this lure, and focus the Release entry on just describing the Release. Fortunately, Classical Extras, and also Picard, have also stepped up to do a better and better job of creating metadata entries for music files from more and more complex MusicBrainz data, and this also reduces the lure.


#4

Right now it feels like an introductory paragraph and then extra detail, which sounds good to me. As such, maybe “Don’t add extra work information (key, catalog number, etc.) that is not in the printed information to the track title; that detail is completed at the Work level.” there should be “Only add extra work information (key, catalog number, etc.) that appears on the release (see below for more details)” or something?


#5

I’m glad that my main point — have the intro paragraph mention adding work title in heading to track title — seems OK.

I put this in for the benefit of readers like me, who remember when the CSG told us to load all this extra work information into track titles. For that reader, it’s useful to get a reminder that CSG now tells us not to do that. Also, it’s useful to know that the extra work information does have a place, namely the Work title.

But this paragraph also needs to serve the novice MB contributor, who is untraumatised by the old CSG.

I don’t strongly about that sentence. Modify it as you see fit. For me, it’s having the intro remind us to put header into track title that is most important.

Thank you!


#6

I made a few more changes and transcluded. Let me know if you think some of them are bad and I can revisit it :slight_smile:


#7

That looks great, and it completely addresses my concerns. Thank you @reosarevok !

This should prevent me from making this mistake again. That means I am freed up to make different mistakes instead. :slight_smile: