# Expose additional data for media **URL:** \ **Category:** OpenSubsonic API extensions\ **Created:** [January 4, 2023, 12:50pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190 "2023-01-04T12:50:44Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 4, 2023, 12:50pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/1 "2023-01-04T12:50:44Z")
# 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. Expose: - Album release type (Album/Compilation/Sountrack/Live/ …) [MUSICBRAINZ\_ALBUMTYPE / RELEASETYPE] - Album Mood - Album Style - Song BPM - Song comment field - … [Expose last played value](https://support.symfonium.app/t/expose-last-played-value/1189) 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 ---
**Author:** ![itm](http://support.symfonium.app/letter_avatar_proxy/v4/letter/i/da6949/32.png) [@itm](http://support.symfonium.app/u/itm)\ **Post date:** [January 7, 2023, 3:39pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/2 "2023-01-07T15:39:53Z")
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? ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 7, 2023, 4:06pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/3 "2023-01-07T16:06:17Z")
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. ---
**Author:** ![dravin](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@dravin](http://support.symfonium.app/u/dravin)\ **Post date:** [January 7, 2023, 5:48pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/4 "2023-01-07T17:48:25Z")
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)` ---
**Author:** ![dravin](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@dravin](http://support.symfonium.app/u/dravin)\ **Post date:** [January 7, 2023, 9:04pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/5 "2023-01-07T21:04:34Z")
> [@Tolriq](#): > > Expose a `styles` String (Comma separated) for albums when the server have the data. As an alternative to this, multi-genre support could fit the same use case, since styles are basically just more specific genres? ---
**Author:** ![Tolriq](http://support.symfonium.app/user_avatar/support.symfonium.app/tolriq/32/726_2.png) [@Tolriq](http://support.symfonium.app/u/Tolriq)\ **Post date:** [January 7, 2023, 9:35pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/6 "2023-01-07T21:35:06Z")
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. ---
**Author:** ![dravin](http://support.symfonium.app/letter_avatar_proxy/v4/letter/d/da6949/32.png) [@dravin](http://support.symfonium.app/u/dravin)\ **Post date:** [January 7, 2023, 9:56pm UTC](http://support.symfonium.app/t/expose-additional-data-for-media/1190/7 "2023-01-07T21:56:22Z")
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.