Support composer tag as a first-class citizen

Type of change

  • API Extension

Proposal description

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.

Security impacts


Potential issues


Alternative solutions

I think we should find more general solution for this (as we basically want the same for performer (with roles), lyricist, conductor, producer etc.)

In that case, maybe this could be handled by my proposed getByTags endpoint Expose additional data for media - #4 by dravin

which would return all matching albums, artists, and/or songs that have a given tagName=value set.

Tags are too generic and different per codec/container.

It’s important to codify the data returned to avoid differences between servers and not precise definition in the API.

Let’s avoid future issues if possible.

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.

1 Like

Just thought about performer, which is not that simple with its (optional) “sub” role.
Musicbrainz does not expose performer in its UI but just performer “roles”, see Credits here:

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)