Navidrome: Support multiple artists, with custom separator

[nebula-it]

As discussed here it would be a good idea to implement a setting where end user can select a custom character that will be used to split multiple artist into separate values.

Current Behavior

A song has Contributing Artist value Artist1, Artist2. Navidrome reads the artist as a single value with name "Artist1, Artist2"

Expected Behavior

A song has Contributing Artist value Artist1, Artist2. Navidrome reads the artist and recognizes there are two or multiple artists separated by comma and song show up under the Artist page of Artist1 and Artist2.
The separator character can be selected (comma in the above example) by end user depending on how their library is tagged.

[deluan]

Thanks, I will try to work on this after #211

[ElleshaHackett]

I would like to see this available for multiple custom seperators, not limited to one or several single characters. For uses such as " feat. ", " featuring ", " vs ", " vs." and " versus " and possible " & ", " and ". All should be case insensitive (or optional) and after separation the values should be trimmed.

Maybe we can allow regular expressions for separation? Keep in mind that introduces some possible security implications like ReDoS.

[deluan]

Yes, the idea is to allow multiple words as separators. Not sure if Regex is any good here (and have the security implications as you said)

[certuna]

Bear in mind that there is a standard separator: / for id3v2.3, and the null character (0x00) for id3v2.4. Vorbis Comments (used for FLAC) just has multiple ARTIST tags. Other separators like ;,& are technically nonstandard hacks.

The fancier the separators are, the more chance of false positives. Some examples that get can get split accidentally:

• "Earth, Wind & Fire"
• "AC/DC" - this was cited back in the days as the big reason why id3v2.3 was terrible and the spec change for v2.4 was needed :)
• "Ånd"
• "Angels Versus Animals"
• "Little Feat"

Interesting discussions:
https://hydrogenaud.io/index.php?topic=112634.0
https://emby.media/community/index.php?/topic/5731-question-on-music-tags-and-delimiters/
https://community.mp3tag.de/t/multiple-genres-in-1-genre-tag/17159

[deluan]

ffmpeg (used to extract the tags) does not support id3v2.4 multi-valued tags: https://trac.ffmpeg.org/ticket/6949. I just tested with the latest version and it basically ignore everything after the null separator....

To make this work, I'll need to find an alternative way to read tags (at least id3 tags, have to test with vorbis and mp4), that is robust enough and does not add extra dependencies to the project....

[certuna]

That is pretty terrible actually - three years and still not fixed?

[certuna]

By the looks of it, the ffmpeg devs don't care, so the solution is either find another tag library or write a commit for ffmpeg (how's your C?) - what's the least amount of work?

[deluan]

Both options are huge tasks (for my limited time). I tried replacing ffmpeg before, but could not find a library that would cover all formats and all required info I need from the files (including duration and bitrate). I also use https://github.com/dhowden/tag to extract pictures (and it gets null-separated multi-valued fields correctly), but it does not provide all info required.

I'll take a look in the ffmpeg codebase, but I don't anticipate a easy change to fix this...

[certuna]

So taglib is our new saviour?

[deluan]

@certuna I'm still evaluating it, but it seems to be a better option for extracting metadata. Some of the bugs/annoyances we have with ffmpeg don't exist with taglib. I'm doing more tests with it this week

[certuna]

Is there any reason why there still seems to be (reasonably) recent commits but no releases since 2016?

[certuna]

By the way, I see that Picard has introduced a custom tag for "artists" (TXXX:Artists in id3, ARTISTS in Vorbis) to store multivalued artists, presumably so old/noncompliant players don't choke on multivalued fields in the regular "artist" fields TPE1 and ARTIST . An ugly hack I think, but probably worth including this frame when multivalued fields are implemented.