[API Request] custom/arbitrary tag/field support

[zacaj]

Type of change

API extension

Proposal description

Most song tag formats are fairly extensible, and at least in Navidrome, they have support for custom tags to add certain tags you may care about that aren't in their default lists to their system.

I'd be nice to see an addition to the track models to support extra fields like this- then clients could support adding columns for them to their lists, displaying them in properties lists, and maybe also sorting/filtering on them.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

At the simplest level, this would just include adding support for arbitrary fields to Child. This could be done via an additionalFields dict or array, or via including them directly in with the other fields in the main body (which would be helpful for backwards compatibility if any of these fields later became standard opensubsonic fields).

It'd be helpful to also support the server supplying a list of supported additional fields to facilitate clients easily adding them to their own column lists without needing to scan the individual songs being returned. This could be a new dedicated get endpoint, but it might make sense to add them as an extra field in the opensubsonicextension response for this extension, or to have a more general getServerConfig type endpoint where stuff like this would go?

Security impacts

No response

Potential issues

No response

Alternative solutions

At a basic level, this may not actually need an official api change if it's explicitly allowed for servers to include extra fields in the responses beyond whats called out by the opensubsonic spec- I haven't been able to find any hard info on this either way yet though

[epoupon]

Just curious, which extra fields would you need?

[zacaj]

well personally I've been adding:

1. the original date I added the music to my collection (since most apps use the file system's created date which isn't reliable), which is usually my default sort
2. a custom persistent ID to my files so that I can track+link them up across apps
3. historical record of the iTunes internal ID from when I migrated off there
4. the LUFS reference which the replaygain was applied at

Navidrome, at least, also has internal date such as, eg, 'starred at' and 'rated at' which would be very easy to add into the payloads on their end, as well as many semi-standard ID3 tags such as the other music brainz IDs besides the one track/recording id opensubsonic supports today.

There's also pretty standard ID3 data like 'track count', 'disc count', or any fields about recording vs release date which opensubsonic also doesn't support right now

[epoupon]

I do agree exposing custom tags may be interesting, but personally I am more for adding first useful defacto standard tags (like ENCODINGTIME https://docs.mp3tag.de/mapping/#encodingtime, the MB identifiers you mentioned, track/disc counts, etc.). 'Starred at' and 'rated at' are not related to custom tags though.

[zacaj]

they're not 'tags' specifically, but they are fields, and not necessarily ones that all servers will support. and nothing is going to reasonably support completely custom tags like ones that single users are adding?

[epoupon]

What I meant is that I think it’s better to standardize right away the tags that are most likely to be standardized eventually, rather than rushing into an overly generic solution that tries to cover those needs as well.
If we take the ultra-generic approach, servers will start exposing their own tags with their own names and formats, and some clients will handle them, but it will be harder to standardize things afterwards because we’ll have to deal with the weight and inertia of existing implementations.