Various booleans for song/album categorization - client dev feedback?

[certuna]

Type of change

API extension

Proposal description

The API already has some booleans in the Child/AlbumID3 responses: isVideo and isCompilation
The other way to do categorization is by free text, like OS does with releaseTypes ("ep", "live")

See the list below for some attributes that could be set by new booleans.

Are there any of these that would be particularly interesting to client devs? Are there some other values that you'd like to receive from the server?

API details

There are a number of track and album attributes that could in principle either be set by a specific boolean or as free text:

• isExplicit
• isAudiobook (useful for clients to know without having to implictly infer this from other free text tags?)
• isClassical (the popular Classical Extras plugin of MusicBrainz Picard writes an is_classical tag)
• showWorkMovement (Apple's own tag that switches the client UI from "normal" view to "classical music" view where the Work and Movement tags are displayed, as well as more prominent display of Composer - this probably serves the same function as isClassical?)
• isMixed (potentially useful for clients to exclude tracks from DJ mixes from auto-playlists?)
• isLive (similar)
• isComplete (for albums, to filter out those albums that do not have the full album tracklist, but only one or two songs - many users don't like seing those listed as "complete albums" in the album list)
• isLossless
• hasLyrics

[dweymouth]

For audiobook, DJmix, and live, those are all standard release types as defined by Picard/MusicBrainz, so I'd think rather than introducing new booleans, the proper way is for the server to add those to the releaseTypes list if appropriate, and for the client to use that as the source of info.

An isComplete flag could maybe make sense, but I'm not sure how the server is supposed to know that info. (I guess if Total Tracks and/or Total Discs are set, the server could use that info, but a lot of times those won't be tagged).

for Classical, I definitely think we should add work and movement as properties to the subsonic.Child type. I would think there is no need for a separate isClassical flag because clients could just check if work and movement tags are set (and/or if any of the genres contain "classical" as a substring, though that is messy because some genres that aren't considered classical do have classical as a substring)

The only one I think probably doesn't need much discussion is isExplicit (though maybe we should just name it explicit), and an album should be considered explicit if any of its tracks are explicit. I don't think there would be much objection at all to adding this one.

[certuna]

And another one could be isLossless - not so much for Now Playing (easy to detect that), but it would allow clients to filter for it or put a little lossless icon next to the song in songlists.

[dweymouth]

Adding on to isLossless, isHD or isHighRes, for tracks/albums in a format that has sample rate > 48kHz OR bit depth > 16 (Personally, I am of the opinion that anything above 16 bit/44.1 kHz lossless is unnecessary, but it's a popular user request to be able to easily identify their high res music)

[dweymouth]

Or expose sample rate, bit depth, codec directly and let the clients decide. (For albums I guess it would be based of the minimum stat of any track?)

[Tolriq]

Lossless have a well defined meaning based on the codec being lossless or not, HD HiRes and the rest is just personal taste that depend on users and would be problematic to have a perfect fit all values.

Sample rate bit rate codecs will need to be exposed in some way at some point for the new transcoding engine.

[certuna]

sampleRate, bitrate (already in), codec and channels are all good attributes to add, but that's probably better for another topic, this was about booleans :)

For albums I guess it would be based of the minimum stat of any track?

Maximum I'd say - there are lots of Hi-Res albums with a couple of 'regular' bonus tracks. I'd say, "if an album has any Hi-Res material, display the album as Hi-Res". Same with lossless, multi-channel, etc. Again, we end up with the question: should the server decide this (send a isHiRes=true for the album), or do you give the client all the attributes and let the client write the logic? In this case, to ensure consistency across clients I'd probably lean towards "server decides".

[dweymouth]

OK, I think classical tagging/metadata is such a can of worms it deserves its own discussion...

[certuna]

Probably yes. Admittedly, it's very hard to do right - I think it's safe to say that nobody has really managed to implement it in a fully satisfactory way in the 25+ years that metadata tags exist.

[dweymouth]

Classical discussion here #78