Expose additional data for media

Type of change

  • API tweak

Proposal description

Most servers have more metadata than what the API officially expose. It would be nice to expose what those server may have in commonly defined fields.


  • Album release type (Album/Compilation/Sountrack/Live/ …) [MUSICBRAINZ_ALBUMTYPE / RELEASETYPE]
  • Album Mood
  • Album Style
  • Song BPM
  • Song comment field

Expose last played value is made as a separate proposal as it’s a way more important data for the users.

Backward compatibility impact

Adding fields should not have impacts.

API details

Expose a releaseType String for albums when the server have the data.
Expose a mood String for albums when the server have the data.
Expose a styles String (Comma separated) for albums when the server have the data.
Expose a bpm Int for songs when the server have the data.
Expose a comment String for songs when the server have the data.

Security impacts


Potential issues


Alternative solutions

Proposal status


Server implementation status

Navidrome: NO
Ampache: NO
Gonic: NO
Funkwhale: NO
Astiga: NO

Why not adding for each song an entry “tags” containing “type / array of values” entries ?
Multiple values in a single field with some custom separator has always been a problem

Taggers usually put the album level tags in all songs, do we want to expose them for each song or would it be specific for albums?

1 Like

Let’s wait to see if things evolve a little with the others.

I think album data should not be returned for songs, reducing duplicate data for sync matters fo efficiency.

I think returning a tags item is a good idea since it’s the most general, and clients can then be configured to treat certain tags as first-class citizens, or just display them as a key/value set. What might also be interesting is a new getByTags endpoint that retrieves all albums/songs that have a given tag (key=value) present. This could be used by clients to e.g. make the LABEL tag browsable, allowing a user to get a list of all albums released on the same record label (assuming their library was tagged as such, of course!)

The tags item could be returned as part of the album element to save data, IF all of the tracks in the album had the same value for a particular tag. Tags that were different per track within an album could be attached to the track element instead.

I guess a getTagValues endpoint would be a good idea too then, which returns all the values for a given tag in the library. So a client could present a list of composers by getting getTagValues(composer)

As an alternative to this, multi-genre support could fit the same use case, since styles are basically just more specific genres?

Styles and mood are different tags. Users split them to keep the genre list small while still having more control after. For smart playlist and things like that.

So if they are supported they must not be mixed and returned as genres.

Yeah I guess that’s a good reason to keep them separate. In my library I’ve used multiple genre tags for the same purpose, putting the most specific genre first so it’s the one returned in the API but browsing by the broader genres still pulls in the appropriate albums.

In any case, both multi-genre support and style/mood support in the extended API would be a huge improvement.