Classical music metadata handling #78
Replies: 4 comments 22 replies
-
|
I think the 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 It's not super easy to infer
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
for
|
Beta Was this translation helpful? Give feedback.
-
|
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 [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] |
Beta Was this translation helpful? Give feedback.
-
|
IMO anyone with a need for classical (I am) have those sorted in another folder (Hence why I love multiple folder support :p). 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. |
Beta Was this translation helpful? Give feedback.
-
|
Did something ever come out of this discussion? Movement and work tags would be great. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Type of change
API extension
Proposal description
@certuna brought up the possibility of an
isClassicalproperty 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:workandmovement. (We could go even deeper withopus/opusNumberor more generalworkCatalogto accommodate things like "BWV 565", but I think we should roll these all together into theworkproperty which is a free text string)Regarding the proposed
isClassicalproperty 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 attachingisClassicalto 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
isClassicalis 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 theis_classicaltag, 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 byisClassical, 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
workandmovementshould be pretty uncontroversial, but I'm not sure the difficulties of exposingisClassicalare worth the added benefits.Backward compatibility impact
No response
Backward compatibility
API details
none yet, in discussion stage
Security impacts
No response
Potential issues
No response
Alternative solutions
No response
Beta Was this translation helpful? Give feedback.
All reactions