Genre Tags under Album show as expected: screenshot
Genre Tags under Artists do not honor the “/” separator and show as one big tag: screenshot
If there is a space and sometimes a hypen in the tag (Hip Hop for example) in the Album genre section, Plex will not honor the separator and show all tags as one big tag.
1 - Is this “expected” behavior?
2 - Should I use a different separator? (I have tried “;” "; " “/” “,”)
3 - What are the best practices for genre tags in Plex? Considering I want plex to use my embedded data.
4 - If there is nothing I can do on my side to make it work correctly, is “/” a good separator for the genre tags considering future updates?
At first sight I have not been able to understand why tags are not showing as I expected. Any input that might lead to me better understating Plex Music Genre Tags is very welcome. Thanks!
“/” should be fine. I believe it’s what the ID3 spec calls for. I think Plex also normally honors the semicolon as well. I use “/” and it seems to work well. My OS is also linux (Mint 20), so we have some common ground.
Considering the link you shared, my local media assets agent for artists was not in the correct order. I will do a metadata refresh with the new settings and see if that resolves the problem.
Full metadata refresh with your suggested settings just finished. The problem persists. I have noticed the separator is not honored in the Album and Artist sections but it happens with less frequency with Albums.
Here are some screenshots after the metadata refresh.
Well, that’s a little baffling. I have one more thought, but this may be completely irrelevant. It’s way out of my expertise, and I don’t know if Plex’s code even cares about this. I may be talking nonsense.
I wonder if it’s possible that beets is encoding the tags in a way that Plex is having trouble reading. I found some threads about beets and UTF-8 encoding vs. ANSI. I don’t know what Plex needs, or if it cares at all, but if, for example, beets is writing in ANSI and Plex needs UTF-8, it might yield inconsistent results?
That’s probably going to require insights from one of the ninjas - coming from me it’s a huge shot in the dark, but I’ve got nothing else.
Couldn’t find any reference about how Plex wants the text in my tags to be encoded. Beets does encode text using UTF-8. I did find posts talking about text encoding in subtitles. From what I have read, UTF-8 encoding for subtitles is ok for Plex.
“/” should be fine. I believe it’s what the ID3 spec calls for. I think Plex also normally honors the semicolon as well.
id3v2.3 doesn’t allow any Genre separators. “Roles” fields like Artist and Composer can be separated by / (which led to much displeasure from AC/DC fans), but not Genre. This has not stopped people from doing it anyway (with ; or / or \\) nor has it stopped various music players, including Plex, from supporting that.
id3v2.4 has the null character as the separator for all text fields, including Genre
FLAC normally uses Vorbis tags, there you can have multiple GENRE tags, no separators. So GENRE "Rock" and GENRE "Pop", not GENRE "Rock / Pop". You can technically tag FLAC with id3 tags instead of Vorbis, but it’s rare and will likely cause problems with apps that don’t expect it.
id3v2.3 only allows UTF16, id3v2.4 allows both UTF8 and UTF16 (correction: UTF-8 and latin1 ISO-8859-1)
Long story short: if you have multi-value Genre tags set correctly in id3v2.4 or Vorbis, Plex will pick up multiple genres. Some of the non-standard ways (id3v2.3, using slashes or semicolons in Vorbis, etc) might work in Plex, some might not.
It’s a shame, id3v2.3 really should’ve disappeared quickly, it’s an incomplete standard that has lived on way too long after its main shortcomings were fixed in id3v2.4. It has continued to be a total nuisance for developers, and has confused users for twenty years. I mainly blame Microsoft
I understand this is a linux thread, but I often use MP3Tag on Windows (not available for Linux) to tag my music files.
I use \\ (two backslashes) to separate genres. The program is configured to use ID3v2.3 meta tags and UTF-16 text encoding as suggested by @OttoKerner, and Plex picks up the multiple genre tags properly every time. The multiple tags are honored properly in both the Artist and Album fields. That is there is no “Blues/Rock/Country/Instrumental” genre any place, only separate genres of Blues, Rock, Country or Instrumental. Artists and albums can have multiple genres.
MP3Tag may write the tags in a non-conforming method, but Plex reads them as expected.
I also use MusicBrainz Picard (most of the time), configured to use id3v2.4, which allows multiple genre tags, and Plex picks up all of those tags properly too.
Here’s an example: The album “Road Tested” by Bonnie Raitt. It has four genres picked up by the embedded tags.
Thanks for the clarification. This is info definitely made a difference in my troubleshooting. Now we know there is a conflict between Beets default (v2.4/UTF-8) and Plex expectations (v2.3/UTF-16). One thing that is still intriguing is why plex parses the tags for artist in a different manner that it parses tags for Albums. Also, I noticed that Plexamp honors the “/” separator even if encoded by Beets defaults (v.2.4/UTF-8). It would be very much appreciated if you could shed some ninja lights on the parsing inconsistencies between Album, Artist, Plexamp.
So it seems your hunch was spot on
My issue is still not solved but at least we now know more about how Plex wants to read its tags.
According to id3 standard id3v2.4 allows UFT-8 and latin1 (ISO-8859-1).
well… I dont know much about the story of text enconding, but right now I am upset at plex devs for suggesting using an ancient standard for tagging my music.
By default Beets uses UTF-8 and id3v2.4 for tags. So considering your comment I can see there is light in the end of the tunnel. Thanks! I might not have to force Beets to use UTF-16. Later on tonight I will try using “\” as a separator and see if that makes a difference in my use case.
You are completely right, apologies. UTF-16 probably wouldn’t work with the multi-value functionality in v2.4, since that doesn’t do null terminated strings. UTF-16 in general has been faded out mostly everywhere, including the web (where it is actively warned against due to security issues).
Unfortunately, I’m just reading here that things might be an even bigger mess wrt text encoding:
Picard saves 2.4 tags with ISO-8859-1, UTF-8, or UTF-16 encoding depending on whether the tag includes unicode characters and its current encoding.
Mp3tag saves 2.4 tags in UTF-8 format only.
iTunes saves 2.4 tags in ISO-8859-1 encoding by default, or UTF-16 if the tag includes characters that require unicode.
well… I dont know much about the story of text enconding
It wasn’t so much about text encoding, Microsoft waited an excruciating 15 years to support id3v2.4 in File Explorer/Windows Media Player/etc, long after everyone else did (iTunes 5.0 from 2005 was one of the last big players to add it), leading to the situation where every tagger app needlessly had to keep writing v2.3 tags by default because it was the only version that worked everywhere, locking everyone into a format that doesn’t support multiple genres (without resorting to nonstandard hacks).
If MS had added it in WinXP or even Vista, I’m convinced v2.3 would’ve been long gone like v2.2, and all these issues with people inserting non-standard separators would have been avoided. This is not just Plex, there are tons of other libraries/servers/players that even in 2020 still have trouble parsing or storing multi-value fields - even something as basic as ffmpeg doesn’t support the actual specs.
q - Text encoding restrictions
0 No restrictions
1 Strings are only encoded with ISO-8859-1 [ISO-8859-1] or
UTF-8 [UTF-8].
And then you can use (section 4):
Frames that allow different types of text encoding contains a text
encoding description byte. Possible encodings:
$00 ISO-8859-1 [ISO-8859-1]. Terminated with $00.
$01 UTF-16 [UTF-16] encoded Unicode [UNICODE] with BOM. All
strings in the same frame SHALL have the same byteorder.
Terminated with $00 00.
$02 UTF-16BE [UTF-16] encoded Unicode [UNICODE] without BOM.
Terminated with $00 00.
$03 UTF-8 [UTF-8] encoded Unicode [UNICODE]. Terminated with $00.
