Classical music metadata handling

[dweymouth]

Type of change

API extension

Proposal description

@certuna brought up the possibility of an isClassical property in a separate discussion thread but Classical is such a can of worms it's worth its own discussion.

As a client dev, here are my thoughts at the moment. (I should also say that admittedly I haven't used Apple music classical or any other music player that has a nice classical experience, but I am a classical fan and have a large chunk of classical in my own library, and my own system of tagging that works well enough with the legacy subsonic api).

First of all, I think what will be needed and uncontroversial is to expose two new tags to the subsonic.Child: work and movement. (We could go even deeper with opus / opusNumber or more general workCatalog to accommodate things like "BWV 565", but I think we should roll these all together into the work property which is a free text string)

Regarding the proposed isClassical property for albums - I think as a client the value here is in displaying the tracklist in a way that "groups" movements of works together under a single heading - which implies scanning through the tracklist to find consecutive tracks that have the same work tag anyway, so I'm not sure what additional value attaching isClassical to albums would have. (I guess whether or not to display the composer, conductor, etc. along with the album artists, though the user could just include the composer/conductor/orchestra as an album artist in their library tags, once we support multiple artists.)

The other problem with isClassical is that it's inherently ambiguous, as there are genre-bending works that are unclear whether they should fall under the classical umbrella or not (eg from my own collection Anna Meredith - Varmints). The other issue is that even with things that are truly, unambiguously "classical" - like Beethoven, say - where does the server get the info? If every user's library was tagged perfectly with Picard and setting the is_classical tag, it would be easy but a lot of users use other auto-taggers or don't use one at all. In that case, genre="Classical" could be a signal, but there are genres like "Contemporary Classical" that should be considered "classical", but substring matching can lead you astray because there are genres like "Neoclassical dark wave" that should not.

Regarding isClassical, the above difficulties notwithstanding, where it may actually add more value is being able to filter composers by isClassical, once clients and servers support the roles extension. E.g. a client may want to show a list of all classical composers, but exclude the composers that are often tagged for popular music but that 99% of the time, the user doesn't care about.

Anyway, tl;dr, I think adding work and movement should be pretty uncontroversial, but I'm not sure the difficulties of exposing isClassical are worth the added benefits.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

none yet, in discussion stage

Security impacts

No response

Potential issues

No response

Alternative solutions

No response

[certuna]

I think the isClassical tag wouldn't be to judge whether the music is "classical" (that's indeed way too fuzzy), but more a way for the server to transmit that the metadata of the song/album should be displayed as classical, i.e. use Work and Movement, as well as artist entities like Composer, Arranger, Conductor, the Musician Credits List, etc.

I have implemented most of this in Navidrome in more-or-less experimental form: this PR will probably not be merged in this form (it's a bit hacky and it's more useful to wait for OpenSubsonic to be finalized) but it's quite useful as an exercise for the UI and metadata handling, see the screenshots. To be honest, I've mostly copied how the Apple Music application handles it, since I think it looks quite nice (even though it doesn't support multi-valued artists/composers/etc): so consecutive songs with the same Work are grouped under that name.

My experience with the web client of ND was that it really simplifies the client side of things if the API has an unambiguous isClassical attribute.

It's not super easy to infer isClassical, but that logic belongs to the server side I think. The most workable logic I found was ANY of these criteria:

• if Apple's showWorkMovement tag, or Picard's is_classical is found -> true
• if one of the genres is "Classical" -> true (and yes, this is somewhat problematic for other languages, and excludes genres like "Opera")
• if work and movement are both set -> true

But in the end, each server should be free to have their own criteria. The principe I think should be: client follows server. If the server says a song/album should be displayed as classical, the client should do it.

for Child, you'd probably need:

• movementName
• movementNumber
• movementCount
• workName
  (these four are already widely established in tag editors, Apple Music, etc)
• isClassical
• contributors (containing Composer, Conductor, Arranger, and the various musician credits, this already exists in OS)

for AlbumID3:

• isClassical
• contributors (already exists)

[certuna]

True - but I have to say, it will probably be pretty rare for a server dev to go through the trouble of implementing Work, Movement etc and then not do the simple isClassical boolean :)

[certuna]

(also in this case, the composers' last names would go in the album title in my system)

Tricky for the dozen-or-so dudes all named Bach.

[dweymouth]

Lol, yeah true. Which is why another OpenSubsonic thing we need to nail down is how to handle searching albums by contributor roles (so calling getArtist with the ID for Carl Philipp Emanuel Bach could bring up a list of all albums that have any CPE bach compositions on them. Preferentially in a two tiered list where clients can distinguish between albums that are primarily CPE bach (ie CPE is tagged as album artist or composer on all tracks), and ones where CPE may appear on just one or a few tracks)

[dweymouth]

of course this applies to non-classical as well, with track artists that may appear on one track in an album

[certuna]

Yeah, this shouldn't be too different from non-classical. I guess the servers could try to be "smart" and add composer to the album artist if he's on all tracks. But even then that's tricky - I have a Mozart album here where the first and last tracks are sub-1-minute applause by "no artist". So too bad Wolfie, no album artist credit for you!

[dweymouth]

Ah another thing I thought of - for the best classical UX, work should probably be indexed and handled as an entity of its own. Since it's a singular-valued field at the track level, we could do it like the legacy artist field, where we have work and workId properties on the track, along with a new endpoint (and OpenSubsonic extension) for a getClassicalWork API, which returns a response with the work title, work composer, and list of albums that feature the work. In clients then, the work title can be a hyperlink allowing users to quickly navigate all recordings of a particular work in their library.

[Edit - as with everything OpenSubsonic, fields and endpoints are optional, so if a server supports work tags but not indexing them, they can just not assign workId and not have the new getWork API and clients can display the work title without hyperlink]

[certuna]

I've played around with a Works repository serverside because this indeed sounds super nice on paper, but it is really difficult and messy in practice - there are so many different ways that record labels have written the title of a work (different languages, with or without catalog number, roman numerals etc) that it was unusable and I dropped the idea.

And if you think that the MusicBrainz Work ID can do the heavy lifting there, bear in mind that MusicBrainz's idea of a "Work" is different than you'd intuitively think - in MBZ not only the entire Work has a WorkID, every movement within that work also has its individual WorkID, see https://musicbrainz.org/work/e74a3a95-8008-43e3-939d-50d6bc9a221b . And that individual ID of the Movement gets written tot the MusicBrainz Work ID tag, not the ID of the overarching Work. It's...frustrating.

[Tolriq]

IMO anyone with a need for classical (I am) have those sorted in another folder (Hence why I love multiple folder support :p).
And we should expose a new field with musicFolder to handle the display need.

That's how others like Plex do things, this allows the server to expose for a library(musicFolder) a setting that the user configure that says how that particular library should be displayed to the users and what it contains.

That would fit the classical need, but also the audiobooks needs and probably other cases.

That does not change the need for the new work/movements and similar fields, but I think it's a better approach in the long term to expose different libraries for different kind of contents.

[certuna]

This is an interesting idea, use the top-level musicFolder item for this instead of per-song or per-album attributes. It would be somewhat annoying for users with mixed classical/non-classical collections, but it's probably not a major change, just moving some files to other folders.

Would the "category" attribute have a defined set of possible values ("Audiobook", "Podcasts", "Classical Music", "Music", "Video"), or would it be free-form textt? Or a set of booleans isClassical, isAudiobook, isMusic, isPodcast, isVideo? If a UI change is triggered by it, probably a defined set, otherwise clients would have to detect the phrase "Classical Music" in various languages, etc.

It's not entirely consistent with the fact that the legacy Subsonic API has isVideo for Child though, then you may expect that there would be isClassical and isAudiobook.

[Tolriq]

Yes it would be a well known list that would grow with time. To ensure future evolution it would actually be an object like

{"type": "Classical"}

That way in the future we can easily add user preferences too like

{"type": "Classical", "hidden": true, "covertArt": "md-1", "saveBookmarks":true }

OS does not always have to be consistent with wrong choices ;) isVideo on Child is only relevant to actual media, yet Child can be used to return Albums or Artists, no sure an Artist isVideo field makes sense.

[certuna]

Another area where this would be very useful is to have the clients use the three date fields (originalDate, Date and releaseDate) to revert back to the original id3 standard where:

originalDate = original date of the composition, i.e. 1791 for Mozart's Requiem
date = recording date, i.e. 1992-02-17 for Celibidache's recording
releaseDate = album release date, i.e. 2004-11-01 for the EMI CD release

for album items, originalDate and date could be a singular date or a date range, since an album can contain multipe compositions and multiple recordings

[dweymouth]

IMO anyone with a need for classical (I am) have those sorted in another folder

I very much disagree with this. I don't think classical is so different that I need to sort it in another folder, and besides, I have too much borderline stuff that doesn't fit cleanly into either "classical" or "non-classical" (a lot of cross-genre modern classical; "remixes" of traditional classical works, or traditional classical performed with synths, collaborations between classical and non-classical musicians, etc).

I will strongly advocate for a solution that doesn't require the user to organize their library in any particular way other than ensuring appropriate tags are in place. I think one thing we could all agree on is that if work and movement tags are present, they should be exposed through the API, regardless of what folder it's from, or what the genre tags are. And honestly I think that's enough for me at least to build a decent classical UX for Supersonic. We can discuss and plan more but I think we should start with codifying the uncontroversial things into a draft extension, and see how it goes from there.

[SimonTeixidor]

Did something ever come out of this discussion? Movement and work tags would be great.

[j-hugo]

I'd also really like to see work and movement fields. To make this independent of the discussion around isClassical above, I have opened a dedicated discussion about the basic uncontroversial fields handling movement and work information (see #209).