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.
Expose:
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
N/A
Potential issues
N/A
Alternative solutions
Proposal status
Proposed
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?
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)
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.