Emby uses the id3v2.3 separator "/" for multiple artists with id3v2.4 tags

[certuna666 0]

In id3v2.3 the separator for multiple artists is defined as the / character. Clearly this has some unintended consequences with artist names like AC/DC, G/Z/R or K/DA, but that is what it is.

In id3v2.4 the separator was changed to the null character.

However, Emby splits artists by / in both tag formats, so an artist like G/Z/R still gets split in three, even if it's an id3v2.4 tag.

[Abobader 3490]

Hello certuna666,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Carlo 4561]

@Luke

[Luke 42285]

Hi there, can you provide a sample file for testing? Thanks.

[Happy2Play 9814]

@Lukehas this artist been whitelisted?

G/Z/R

Looks like MBZ has G//Z/R

We probably need a running list of artists that have already been whitelisted.

Sure we have this topic.

 

 

Edited March 30, 2021 by Happy2Play

[certuna666 0]

I understand Emby needs a whitelist for dealing with "/" in artists in id3v2.3, but surely for id3v2.4 (where / is not a valid separator) there should never be splitting by / at all?

id3v23.mp3: artist "G/Z/R", gets split in Emby as three artists Z, G and R. This is technically correct, although you might want to have a whitelist to catch popular artists with a / in their name.

id3v24.mp3 artist "G/Z/R", gets split in Emby as three artists Z, G and R. This should not happen since / is not a valid separator in id3v2.4.

id3v23.mp3 id3v24.mp3

Edited April 2, 2021 by certuna666

[Luke 42285]

Based on the data from ffprobe, the only way we have to determine that it's 2.4 is from the comment field. That seems a little flimsy, but if that's what applications are doing then i guess so be it.

@ginjaninja, what do you think, should we use different separators if we can detect that it's 2.4? 

The biggest challenge in this is usually ideal vs. reality. In other words, the spec may say it should be a certain way, but in reality, users may have files that are not following it.

[speechles 2062]

@Luke it is like street signs. When the road changes during construction and people get startled at that point and crash because they didn't read the road signs indicating that some new round abouts had been constructed. They are not following the specification. The road signs and the spec. You cannot protect people from themselves. You have to protect yourself from them. Otherwise you are out of spec. You start down the rabbit hole you wind up in Wonderland. Where things are confusing and mad. You will never stop chasing rabbits. Time where is all the time. Spent maintain that code that is where. Beware the jabberwocky.

Edited April 15, 2021 by speechles

[Guest]

'Got to love the S's...' - Racing reference...

-and don't forget the Hooka smoking caterpillar... The White Knight will be talking backwards... AND NEVER EVER ask Alice while she's ten feet tall..

[ginjaninja 605]

18 hours ago, Luke said:

Based on the data from ffprobe, the only way we have to determine that it's 2.4 is from the comment field. That seems a little flimsy, but if that's what applications are doing then i guess so be it.

@ginjaninja, what do you think, should we use different separators if we can detect that it's 2.4? 

The biggest challenge in this is usually ideal vs. reality. In other words, the spec may say it should be a certain way, but in reality, users may have files that are not following it.

the question may be moot, unless emby would consider moving away from ffprobe for music tag extraction.

https://superuser.com/questions/1282809/is-ffmpeg-able-to-read-multiple-values-in-an-id3v2-4-tag

i dont think ffprobe supports reading multiple values separated by id3v2.4 null character specification

i have just tested it again 3+ years on from when this bug was reported and as far as i can tell ffprobe is still deficient.

i used mp3tag to write an id3v2.4 multivalue artistS tag.

(mp3tag seems to recognise a proper multivalue id3v2.4 tag, but ffprobe only sees the first artists)

i am not experienced in id3v2.4 in general or in mp3tag so someone else might want to try in their favourite tagger. (but my results do seem to match the ffmpeg bug tracker issue.)

this isnt the first time ffprobe has been found wanting for tag extraction iirc.

 

exiftool has no problem reading id3v2.4 multivalue tags for the sample in the ffmpeg bug tracker.

https://exiftool.org/index.html

not that exiftool is reccomended but it does confirm ffprobe has a deficiency in this regard

Edited April 16, 2021 by ginjaninja

[Luke 42285]

Yes that's good info, thanks. We'll have to monitor that ffmpeg ticket.

[certuna666 0]

(apologies for the late reply)

Yes, ffmpeg/ffprobe only reads the first value of a null-separated string (which is how multi-valued tags are implemented in id3v2.4). Exiftool, TagLib and a bunch of other libraries do support it though.

This custom "Artists" field is a bit silly. The regular Artist frame TPE1 can already be multi-valued, but because some apps don't support that, we create another multi-valued frame TXXX:Artists...which also cannot be read by those apps.

But I guess it does cater to one use case: you put "Kanye West and Jay-Z" in TPE1, and "Kanye West<null>Jay-Z" in TXXX:Artists, and hope that 'dumb' old apps read only TPE1, and 'smart' new apps that can handle multi-valued fields read TXXX:Artists . Which I guess is better than putting "Kanye West<null>Jay-Z" in TPE1, since old apps will only read "Kanye West". Still, two fields for the same metadata is a pretty messy solution.