[Enhancement] Artist names as credited

[simonbun]

I'm pulling together the pertinent points from our previous discussion so they're not lost.

LMS currently uses the most recently credited name (in terms of LMS loads) for each artist (per musicbrainz_artistid) in indexes, and also when building the album and track listings; when this name is no longer part of the artist_display_name the artist list is recreated, losing the types of collaboration e.g. feat., with, vs.

Example: The first album added to LMS was credited to 'Norah' whilst a second added via a subsequent scan was to Norah Jones.

Artist index after first scan: Artist index after second scan:

Album listing after first scan: Album listing after second scan:

Discussed changes:

• Use track_artist_link.artist_name when transforming artist_display_name in album and track listings so the original credits are retained.
• Retain the first encountered value in artist.name to prevent the artist index changing. We did discuss using originalreleasedate/date but this would still result in changes to the artist index (as in example above).
• Allow the user to provide a preferred name through ArtistInfo for use in Indexes e.g. preferred_name and preferred_sortname.
• Enable search to operate across all credited names e.g. 'Jacksons' or 'Jackson 5' would return 'e5257dc5-1edd-4fca-b7e6-1158e00522c8' (nice to have)

[epoupon]

Retain the first encountered value in artist.name to prevent the artist index changing. We did discuss using originalreleasedate/date but this would still result in changes to the artist index (as in example above).

This has the drawback to make it impossible to update the artist name afterwards (if the user made a typo for example)?

Allow the user to provide a preferred name through ArtistInfo for use in Indexes e.g. preferred_name and preferred_sortname.

Would it be acceptable that the name set in the artist info file is the primary name?

[simonbun]

This has the drawback to make it impossible to update the artist name afterwards (if the user made a typo for example)?

Good point I hadn't considered typos. To be honest, I thought it was the easiest option that would maintain state in the artist index, but if we can override it with ArtistInfo then any solution is fine by me including the current. If you really wanted to change the current logic then I'd go for the earliest name by originalreleasedate/date, just because then it's not dependent upon the order in which the albums were added.

Would it be acceptable that the name set in the artist info file is the primary name?

That's how I'd prefer it but don't you currently use it as part of the matching process, or is that only when there isn't a mb_artistid?

The kodi nfo documentation states that :

Overwrites artist name in artist table, when "prefer online info" is "enabled". Does not change that name anywhere else

Whilst I have no idea exactly what that means, it seems there is precedent for having it be an override.

[cquike]

* Retain the first encountered value in artist.name to prevent the artist index changing. We did discuss using originalreleasedate/date but this would still result in changes to the artist index (as in example above).

You probably have thought more about it than me, but my naive approach would be that the the artist name is the "canonical one" in musibrainz.

So in your example, after the first scan the Artist index would show "Norah Jones" because this is the name that appears in musicbrainz for that artist MBID (https://musicbrainz.org/artist/985c709c-7771-4de3-9024-7bda29ebe3f9). I think that has the advantage of not depending on the order in which the albums are added.

A possible issue would be to know when to update the name in the Artist index if musicbrainz updates the name. I update a my ~1500 artists collection with a cron job daily, so making so many musicbrainz queries every day would be probably too much. Maybe a parameter could be added to set how often to check musicbrainz for updates in the names.

Or do you know if picard can store a tag with the artist name as it appears in the artist name rather than the name credited in the album? If so, then lms could just use that (non-standard) tag.

[simonbun]

Hi @cquike

* Retain the first encountered value in artist.name to prevent the artist index changing. We did discuss using originalreleasedate/date but this would still result in changes to the artist index (as in example above).

You probably have thought more about it than me, but my naive approach would be that the the artist name is the "canonical one" in musibrainz.

I believe LMS relies wholly on local metadata so the development and additional processing of such a solution (musicbrainz lookup for each artist every scan), for a somewhat limited problem, doesn't seem warranted to me, though that's for @epoupon to decide. The problem I'd have with this solution is that the mb canonical name is unrelated to my collection; for example, whilst I do have a couple of Kanye West's early releases I'm unlikely to obtain any more, yet if we were to use the mb logic he'd be indexed under 'Ye'.

So in your example, after the first scan the Artist index would show "Norah Jones" because this is the name that appears in musicbrainz for that artist MBID (https://musicbrainz.org/artist/985c709c-7771-4de3-9024-7bda29ebe3f9). I think that has the advantage of not depending on the order in which the albums are added.

I suggested first encountered mainly to keep the index consistent (and because it's simpler to implement) but it does have its drawbacks, which is why I also suggested originalreleasedate/date.

I update a my ~1500 artists collection with a cron job daily, so making so many musicbrainz queries every day would be probably too much.

What exactly are you updating? One of the problems with credited names in MusicBrainz is that there isn't an associated sortname, so refreshing tags can be troublesome.

Or do you know if picard can store a tag with the artist name as it appears in the artist name rather than the name credited in the album? If so, then lms could just use that (non-standard) tag.

I don't see how that would help unless you're constantly refreshing your tags; for example, when Kanye West released 'The College Dropout' his credited and canonical name was Kanye West, but it's now Ye for new releases.

[Bigmack3000]

Hey, just curious if there's been any movement on this one?

I just added a new John Lennon boxset where he is credited as "John" so now that's how he's displayed for every album.

[simonbun]

Hey, just curious if there's been any movement on this one?

I don't believe so.

I just added a new John Lennon boxset where he is credited as "John" so now that's how he's displayed for every album.

I think it's safe to change the artist back to "John Lennon" in the database so it's mostly correct (except for the boxset):

sqlite> update artist set name = 'John Lennon', sort_name = 'Lennon, John' where mbid = '4d5447d7-c61c-4120-ba1b-d7f471d385b9';

Probably best to shut the server down before making the change (and make a backup).

[epoupon]

@simonbun Unfortunately, this may only be a temporary solution, as the next full rescan could roll back the change. I’ll try to find a fix for this specific issue in v3.72.0 by making the name specified in the artist info file the highest priority.

[simonbun]

@simonbun Unfortunately, this may only be a temporary solution, as the next full rescan could roll back the change.

I performed a couple of rescans and it seemed quite stable but it was far from an exhaustive test.

I’ll try to find a fix for this specific issue in v3.72.0 by making the name specified in the artist info file the highest priority.

If name and sortname from ArtistInfo were used as priority that would be great!

[epoupon]

@simonbun Unfortunately, this may only be a temporary solution, as the next full rescan could roll back the change.

I performed a couple of rescans and it seemed quite stable but it was far from an exhaustive test.

I’ll try to find a fix for this specific issue in v3.72.0 by making the name specified in the artist info file the highest priority.

If name and sortname from ArtistInfo were used as priority that would be great!

I have pushed the image df344448, It prioritizes the artist info file and falls back to the name in the latest release. Any feedback is welcome!

[simonbun]

I have pushed the image df344448, It prioritizes the artist info file and falls back to the name in the latest release. Any feedback is welcome!

I've tested both scenarios (with and without Artist,info) and I can't see any issues.

I'm not sure track artist should override album artist (thinking specifically about compilations here), but given we can now supply an override I'm happy.

Great job!

[epoupon]

Thanks for the feedback!

Indeed a recent compilation with an old artist name should not be taken into account. Will also prioritize album artists to track artist then!

[FibreTTP]

Okay, I don't know if I've fully understood these two threads correctly. Is the problem that LMS cannot understand what the "canonical" artist name is on MusicBrainz (for the artist itself)?

If so, consider defining a script for people who use Picard to set a tag to the standardised names of the artists, as specified in the Additional Artists Variables Picard plugin, and reading the tag it creates.

Something like (haven't tested):

$setmulti(albumartistsstandard,%_artists_album_all_std_multi%)
$setmulti(artistsstandard,%_artists_track_all_std_multi%)

This, of course, also becomes outdated when the artist name changes on MusicBrainz (but it deals with the credit issue).

---

And does the artist index problem in Simon's first post still exist?

[epoupon]

Interesting! But LMS should already have all the relevant information in the tags, I just need to adapt some code in the UI

[epoupon]

And does the artist index problem in Simon's first post still exist?

This is now deterministic: the artist name is picked using their latest release

[FibreTTP]

And does the artist index problem in Simon's first post still exist?

Sorry, I meant to refer to the second part of the original post, where an older album uses the artist's name as tagged on the newer album, even though they weren't credited as such on the older one. Does this problem still happen?

But LMS should already have all the relevant information in the tags,

This is now deterministic: the artist name is picked using their latest release

This seems contradictory and un-ideal. I'd assume the artist's name as displayed on the LMS artist page should be the same as what's displayed on their MusicBrainz artist page. There's no information currently in the Picard tagging process that explicitly writes what the artist's name is into the files (only what they have been credited as on releases, tracks, and recordings).

An artist could be named on MusicBrainz as foo, but what I'm gathering is that if you only have one of their albums, one in which they are credited as bar, that they'd be named bar in LMS not only on the album (which is fine and correct), but also on their artist page. The album's tags would never have foo written anywhere for LMS to use.

By extension, if you had any number of foo's albums, but in the latest one they were credited as bar, their artist page would name them as bar, even though their name is foo, and they are known as foo?

Reading an external tag that contains their name as on MB seemingly solves this, and if someone doesn't want that behaviour, e.g:

The problem I'd have with this solution is that the mb canonical name is unrelated to my collection; for example, whilst I do have a couple of Kanye West's early releases I'm unlikely to obtain any more, yet if we were to use the mb logic he'd be indexed under 'Ye'.

They could write an ArtistInfo file for any exceptions (or not write the tag, it's opt-in).

[epoupon]

And does the artist index problem in Simon's first post still exist?

Sorry, I meant to refer to the second part of the original post, where an older album uses the artist's name as tagged on the newer album, even though they weren't credited as such on the older one. Does this problem still happen?

Yes, that's why this issue is still open.

But LMS should already have all the relevant information in the tags,

This is now deterministic: the artist name is picked using their latest release

This seems contradictory and un-ideal. I'd assume the artist's name as displayed on the LMS artist page should be the same as what's displayed on their MusicBrainz artist page.

Definitely!

The artist page does make use on what is put in the ArtistInfo file, falling back to the name used for the last release.

By extension, if you had any number of foo's albums, but in the latest one they were credited as bar, their artist page would name them as bar, even though their name is foo, and they are known as foo?

Not sure if this is a common pattern on MB, do you have examples?

[simonbun]

This is now deterministic: the artist name is picked using their latest release

This seems contradictory and un-ideal. I'd assume the artist's name as displayed on the LMS artist page should be the same as what's displayed on their MusicBrainz artist page.

Assuming that's the desired outcome (not for me personally), the only - sane - way to achieve that would be for LMS to pull it from MusicBrainz directly.

Reading an external tag that contains their name as on MB seemingly solves this

Wouldn't it be easier to run a process that updates ArtistInfo than to refresh your entire collection periodically?

[epoupon]

Making some progress on this:

“Rhapsody” and “Rhapsody of Fire” both point to the same artist page, using the same MBID (“Rhapsody of Fire”). On this artist page, I currently display the artist name for an album only when it differs from the page’s artist name. This differs from how albums are handled at the track level: track artists are shown for all tracks if at least one track has artists that differ from the album artist. Any thoughts on this approach? Am I being too picky? 🙂

Edit: I also have a couple of standalone files that refer to Rhapsody (without an MBID). This artist are not merged, since the current logic only merges artists based on the primary name, not on aliases.

[simonbun]

On this artist page, I currently display the artist name for an album only when it differs from the page’s artist name. This differs from how albums are handled at the track level: track artists are shown for all tracks if at least one track has artists that differ from the album artist.

I guess it's personal preference, but I would prefer that they were all listed if any differed to the canonical name.

Any thoughts on this approach? Am I being too picky?

You can't be too picky :thumbsup:

[epoupon]

This should now be solved. It required required significant changes since display names are now used in both the web interface and the Subsonic API interface (and it actually seems to work fine with DSub and Tempus)

I pushed a docker image 86f45aee (caution: db schema is updated and won't be compatible back with 3.73.0). Any feedback is welcome!

[simonbun]

This should now be solved. It required required significant changes since display names are now used in both the web interface and the Subsonic API interface.

I had thought/assumed the API was already using credited names - because everything looked ok in Symfonium - but I noticed last week that the canonical name was still being used everywhere except displayArtist, so I'm glad you spotted that.

I've had a very quick look at the web-ui using image 86f45aee and everything looks great! I won't get another chance until boxing day now, at which point I'll look at it from the API side of things.

Now I'm being picky, but I was wondering if the hover text should display the credited name or the canonical one (MusicBrainz displays the canonical one).

Happy holidays and congratulations on a truly impressive year of development!

[epoupon]

I had thought/assumed the API was already using credited names - because everything looked ok in Symfonium - but I noticed last week that the canonical name was still being used everywhere except displayArtist, so I'm glad you spotted that.

In the API artists are actually referenced using a pair name+id. For example in https://opensubsonic.netlify.app/docs/responses/child/ there are id and name for each ArtistID3 (the only required fields) In https://opensubsonic.netlify.app/docs/responses/albumid3withsongs/ there are artistId and artist. Now the name can be different for the same id. DSub and Tempus make use of them so it works out of the box. But Symfonium seems to ignore these extra name fields and use the canonical name raised in the search3 endpoint. I told @Tolriq about this.

I've had a very quick look at the web-ui using image 86f45ae and everything looks great! I won't get another chance until boxing day now, at which point I'll look at it from the API side of things.

Looking forward your tests then!

Now I'm being picky, but I was wondering if the hover text should display the credited name or the canonical one (MusicBrainz displays the canonical one).

Noted, that should be easy to change, but what about places where the name is too long and being truncated?

Happy holidays and congratulations on a truly impressive year of development!

Thanks for your kind words, happy holidays to you too!

[simonbun]

I've had a very quick look at the web-ui using image 86f45ae and everything looks great! I won't get another chance until boxing day now, at which point I'll look at it from the API side of things.

Looking forward your tests then!

I've had a look at the main endpoints and everything looks good. As you previously noted, Symfonium is unchanged as it displays the canonical name when presenting links to artists - though that could be by design (similar to how I suggested the hover element could display the canonical name).

Now I'm being picky, but I was wondering if the hover text should display the credited name or the canonical one (MusicBrainz displays the canonical one).

Noted, that should be easy to change, but what about places where the name is too long and being truncated?

Are you currently taking into account the length of the name (as credited) when presenting the hover text, or is this an existing problem?