Using extended/custom tags

[simonbun]

Whilst I appreciate that OpenSubsonic/LMS already supports an extensive set of tags, it doesn't, and never will support everything I want it to.

To support additional tags (those that don't change the meaning or aggregation of existing ones) whilst keeping changes to a minimum and ensuring they make it to downstream clients e.g. Symfonium, I was thinking that an abstraction layer might be a good option.

I appreciate that VERSION is possibly going to make it into the OpenSubsonic standard at some point, but let's use it as an example. VERSION is used to hold album disambiguation information e.g. Deluxe Edition; because LMS/OpenSubsonic doesn't support it I have albums that appear duplicated in my album listing:

The Dark Side Of The Moon
The Dark Side Of The Moon  (tagged with VERSION = 'Experience Version')

If there was a way to tell LMS to read the VERSION tag and to append it to the ALBUM tag (an already supported object in LMS/OpenSubsonic) my problem would be solved, and with little code change.

Using the foobar2000 syntax as example, my current configuration could look something like:

Album: %album%[' ('%version%')'][' ['%remasterdate%' Remaster]']	The Dark Side Of The Moon (Experience Version) [2011 Remaster]
Title: %title%[' ('%subtitle%')'][' ['%tracktype%' Track]']		Speak To Me (Live) [Bonus Track]

The tags within [] are evaluated and if not empty the expression is added.

With such a configuration in the lms.conf, LMS would only need to:

• Read the additional tags

• Modify the existing supported tags

Nothing else will need to be changed and the modified values would flow through to downstream clients.

[epoupon]

Hello!
I do understand your use case and will think about it. I strongly believe in tags though, but that's indeed a lot of work to support all the relevant ones from the servers to the clients using the OS API.
I guess these different albums already have different release mbid (but same release group mbid) and are already split using release mbid?
(I do plan to think about a way to use the release group mbid to better group releases like that, while keeping the UI as clean as possible)

[simonbun]

I strongly believe in tags though, but that's indeed a lot of work to support all the relevant ones from the servers to the clients using the OS API.

I'd imagine it to be endless, and it still wouldn't support my custom ones.

I guess these different albums already have different release mbid (but same release group mbid) and are already split using release mbid?

They're now split on barcode 👍

I don't use many musicbrainz tags, and in some scenarios they won't help because I don't like box-sets grouped (although I'm sure I could create my own ids to force the behaviour).

[epoupon]

First try with:

• 5 releases per line
• append the version in [] + text-muted style

Will make more tests with longer names to handle multi lines.

Regarding grouping, I’m afraid you’re right: an intermediary view listing all the album’s releases would be the most useful. As you mentioned, there can be many different releases of the same album, and they often don’t have comments attached. So, we’d need another way to distinguish them, such as country, release date, number of tracks, etc. They often look like this: https://musicbrainz.org/release-group/09ac3f31-dd03-36b8-8749-24fcae31bbc3.

Here’s another idea for grouping these releases:

In the albums/artists view, display only the "main" release (e.g., the earliest version, the one with fewer tracks, no version label, etc.).
In the album view, add a button / link to see all versions of the album using the new list view.
The downside is that it adds an extra click to reach the full list.

Alternatively, we could add a small link directly in the albums/artists view—next to the main release’s name, for example—to access the list view (maybe a clickable list icon?).

[simonbun]

First try with:
5 releases per line
append the version in [] + text-muted style

Looks good!
Assuming there will be that one person that doesn't like the fact that fewer albums are now visible, is there any reason you're not making full use of the page width?

In the album view, add a button / link to see all versions of the album using the new list view.
The downside is that it adds an extra click to reach the full list.

In Roon you're able to make a particular version the default/favourite. This version is then used everywhere, and in album view you're able to view the other versions and pick a new default.

If that's an option then just have the other versions available in album view.

[epoupon]

Looks good! Assuming there will be that one person that doesn't like the fact that fewer albums are now visible, is there any reason you're not making full use of the page width?

This is the default width of the Bootstrap container, it could probably be a bit wider.
But I must admit that I find overly wide content tiring to use; the eye movement required to scan the images is not very pleasant, and in the end, you get a poorer overall view.

In Roon you're able to make a particular version the default/favourite. This version is then used everywhere, and in album view you're able to view the other versions and pick a new default.
If that's an option then just have the other versions available in album view.

Interesting! Does this grouping also work when there are two versions of the same release? For example, when only the encoding differs (but the MBID is the same).

[simonbun]

But I must admit that I find overly wide content tiring to use; the eye movement required to scan the images is not very pleasant, and in the end, you get a poorer overall view.

I completely agree. I very rarely view a large number of albums, and I'm certainly not scanning them; that's what search is for!

Interesting! Does this grouping also work when there are two versions of the same release? For example, when only the encoding differs (but the MBID is the same).

That's not something I tested during my trial period, but I would expect it be. I guess that's something that needs to be taken into account when choosing a default.

I've learnt to stop making assumptions, so, I think it only makes sense to group albums when in Random/All mode.

[simonbun]

I've learnt to stop making assumptions, so, I think it only makes sense to group albums when in Random/All mode.

Unless they've Starred multiple I suppose.

[epoupon]

By the way, did you mean VERSION or ALBUMVERSION?

[simonbun]

If only we had some kind of abstraction layer so that the user could provide the "correct" mapping :)

[epoupon]

Here it would just be to customize mapping from lms' album level version to actual tags (albumversion vs version). Way easier than your initial post! That would mean making mapping in

lms/src/libs/metadata/impl/TagLibTagReader.cpp

Line 65 in dd1a080

{ TagType::AcoustID, { "ACOUSTID_ID", "ACOUSTID ID" } },

configurable

[simonbun]

lms/src/libs/metadata/impl/TagLibTagReader.cpp

I had no idea you were using so many tags! That'll work as a good reference for me.

I've never understood the Picard use of Artist, ArtistSort and Artists.
Artists is the multi-value tag (only in Picard) used for building filters/indexes, yet it doesn't have a corresponding sort value! My only use for Artist (single string of concatenated artists) would be on a track listing to show the relationship between artists, and I have no use for a sort value!
To me they should have made the non-standard tag Artists hold the string of artists and left the other two alone.

I've just loaded a CD and this is what Picard populates

Artist:            Elton John & Dua Lipa
Artist Sort Order: John, Elton & Lipa, Dua
Artists:           Elton John; Dua Lipa

If I searched for the artist 'Elton', or wanted to select it from an index, I wouldn't want to see:

Elton John
Elton John & Dua Lipa
Elton John & ABC
Elton John & DEF
...

How could I list all his tracks from that selection? Maybe I'm missing something.

[epoupon]

It is briefly described in https://github.com/epoupon/lms/?tab=readme-ov-file#multiple-artists
The artist field is only meant to store a "display string," while the artists field holds the actual list of artists.
In the database, only "Elton John" and "Dua Lipa" exist as separate artists. However, in the track table, "Elton John & Dua Lipa" is stored solely for display purposes.
Each artist is linked to every track they are referenced in.

It allows things like that:
see https://musicbrainz.org/release/16d060fd-f43c-4430-b4c6-82416fff6ff2
Artists are clickable, and they are not just separated using a single delimiter .

[epoupon]

About sort names, lms tries to extract the sort names with artistsortorder, but if it is single-valued and artists is multi-valued, it is just ignored. The sort name will still have chance to be associated with the correct artist if it appears in a track that has a single artist