For users with a lot of classical music in their libraries, this would be a huge usability improvement.
The getAlbum response should include the composer tag for each track, and there should be a new endpoint getComposers to return the list of all composers, and getComposer which returns a list of all the albums the given composer appears on. (Alternatively I suppose the getArtist endpoint could be extended with a composer option)
Backward compatibility impact
New APIs and new elements in existing response payloads should not break backwards compat.
API details
New getComposers API call which behaves like getArtists except using the Composer tag instead of Artist tag. Also a getComposer endpoint which behaves like getArtist. If a composer appears on an album at all, even a single track, that album should be returned by the getComposer query. This is so searching for Bach should include classical compilation albums that may have tracks by Bach as well as other composers.
Tags are too generic and different per codec/container.
I guess this is more a tagger/server related problem?
But artists handling is not really the same as handling genre, mood, etc. tags. We need to specify the relationships of each song (track actually) and the artists involved (this artist as performer, that artist as composer etc. and these artists may have multiple roles across tracks/albums.
Yes not only tagger but also the way the server interpret the tags, since id3 tags and mp4 tags have subtle differences and in some cases can have different outcome, not talking about translations in some ugly cases.
So yes artist handling with those are a special case that require a special treatment.
Kodi use the concept of roles, artist are possible roles and songs have contributors meaning artist with roles. (Composer, lyricist, …)
But it’s a well defined concept that does not cover all the possible tags of the world.
So 100% yes to have a complete role exposition, but not treating all the tags as a global tag bag where clients have to handle all the edges cases that will be triggered by that.
Yes I meant that artists should be handled separately from other tags: they need a custom solution
Could be something like that: new field artists with ‘role/array of artists’ entries, and the role being one of the well know defined roles.
Yes would also be nice to have all the possible roles from an artist in the artist answer and have an endpoint to get all the possible roles to be able to filter on them.
For Symfonium I can rebuild all from just the song data, but it’s probably better to have the whole package for the other more normal online apps.
I chose the same for LMS, mixing well know artist tags (like composer, producer, etc.) with performer’s sub roles. Showing something like that:
Not sure what we want to expose thanks to the API (sub field for performer or mixing everything like in MB, but that means there is no longer a well known list of defined artist roles)
