When importing music files, what delimiter(s) will Plex use in multiple value fields - in particular Genre, but it would be daft to use different delimiters in different fields.
I know this has come up before and I’ve read most of it, but I have not found a definitive answer, just anecdotal experience from different users.
ID3v2.3 I believe used ‘/’ as the delimiter, but this has changed in v2.4 to the NULL character and I think AAC files use the same (but could be wrong on that). I have read that Plex will use ‘/’ and I’ve also read that ‘/’ does NOT work. Not that I want to use ‘/’ as it’s a bad choice, but it’s hard to figure out the facts. Will Plex use NULL?
Somewhere in Plex, there is code that specifies the EXACT character(s) that Plex will use as a delimiter. What is/are those characters and why do they apparently try to hide this fundamental facet of Plex usage?
Some posts on this forum suggest ‘;’ (semi colon) works as a delimiter in Plex. Does it? I’d be happy to use that, but as NULL is actually the tag standard, then I rather think that would be better. Does Plex support the NULL delimiter?
Would appreciate if someone could shed some hard (i.e. real) light on this. What character(s) is Plex actually programmed to treat as multi value delimiters?
Have a look at Only one embedded genre tag being read and the various threads linked off it. They’ll help you understand what’s happening and how to mitigate.
Thanks, read all through that and other related threads, but it still seems there is no definitive documentation about how Plex deals with this.
It looks like there is a fix in the offing that will again correctly deal with NULL delimited multi value tags, but not all file formats use that method.
I also use Apple’s Music.app and Apple have never supported multi value tags/fields. So for me, the idea of using ‘;’ delimited multi values makes sense if Plex can split them appropriately as Music would also display them all in an acceptable manner. However I’m still not 100% clear on how Plex works.
Let’s take for example a genre of “Pop;Rock;Country” (no arguing about whether such a combination could exist). If that is stored as a single value (i.e. just a text string) it will display like that in Music, whatever the file type. What about Plex?
Would Plex split that string into multiple genres if such a single tag was contained in MP3 (ID3v2.3 and ID3v2.4), AAC (m4a)? Also perhaps OGG, FLAC, ALAC, although not important to me at this time.
I would prefer to be able to use the standard NULL delimited values, but Music will not display all the genres. So for the sake of compatibility, it makes sense to combine into a single string with a simple character delimiter and the semi colon is looking like the best option for that. But…
Does Plex correctly split a ‘;’ delimited single string into multiple values?
If you use the tag Pop;Rock:Country Plex will split it into multiple values.
However, the multiple value will only appear appear at the album level, based on the genre(s) of the first track. Basically, all of the tracks on the album will be considered all of those multiple values. That is, even if the second track is only one of those genres, or a completely different genre (Blues;Jazz for example) Plex does not recognize that track as a different genre than the first one.
If you tag all of the tracks on your album with the same genre string, Plex works great. If you mix and match genres within an album, or you have an artist that fits into several different genres, and you expect to generate a playlist by genre, you might be disappointed.
I thought they’d recently fixed that and v2.4 now works?
I have to use v2.4 as v2.3 screws up any non regular ascii characters, like accented characters in artists’ or composers’ names. In iTunes (and maybe Music) the text may look ok, but open the file in Yate (or MediaInfo) and the encoding is screwy with weird characters inserted. It does seem to be Apple’s apps causing the problem, but it never occurred when using ID3v2.4, only starting after converting to v2.3 which I seemed to need for an in-car player to read. But that turned out not to be the final solution and due to experiencing repeated corruption (only in the ‘Sort’ version of tags strangely) in v2.3 tags, I switched back to v2.4 and it is not reoccurring.
I read in another thread that this was considered a bug and they will (eventually) fix it so genres will work as before.
What Plex needs to do is grasp the concept that genre is a requirement for both albums and track and deal with that fact appropriately. Genre and Year also as they can both vary between tracks of an album.
In truth I use genre very little. But I do want it to be RIGHT.
Nope. A patch has been submitted to ffmpeg but last I checked it was not reviewed, approved or merged. The issue is a ffmpeg and not really a plex one.
Plex are working on their own workaround which is currently scoped to genre and has not been confirmed to be included in other tags, like releasetype which also suffers from this.
For now I would shy away from ID3v2.4 and stay with ID3v2.3 if you want multi value tags to be imported within plex.
ID3v2.3 is out of the question for me. I have spent way too long chasing text corruption to consider going back to that.
What about MPEG4, i.e. AAC/M4A audio and MP4 video. They use the same tagging scheme with multiple tags of the same type to handle multiple values, but will Plex correctly split a ‘;’ delimited string in a single tag of these file types?
An album, as well as the artist for the album, used to inherit all of the genres from all of the individual tracks. Presently, it’s just the first track of an album. I believe they are looking a that bug, hopefully others.
Plex released a test version of the server, that did read v2.4 tags properly. Those fixes have not been included in recent updates to the Beta or Public versions of the software. If you update the server software to one of the latest versions, the multiple v2.4 tags are not read, and regular maintenance periods revert all of the genres to a single tag again.
I think if you tag your MP3’s with v2.3 and configure the editor to use UTF-16 rather than UTF-8 format, the accented characters will appear correctly.
Yes, I’m aware of the ffmpeg bug, but as I understand it, that affects ffmpeg’s parsing of tags that contain multiple values delimited by null. From reading all the other threads about this, I thought that if there’s just a single tag containing a single value (text string) that happens to contain semicolons, then ffmpeg will simply pass that on to Plex which will happily split it up by ‘;’ into multiple actual values as this is what Plex is actually wanting from ffmpeg anyway.
It’s the nulls causing the ffmpeg problem and a single text string should get through to Plex without issue, for any file type and Plex wants a ‘;’ delimited string to represent multiple values.
Is that not the case? Are there other issues of which I am unaware?
I have a test library where I threw in albums of just about every file format. I’m pretty sure Plex reads multiple tags for genre, etc even when they are separated with the null character for almost almost everything except MP3 audio.
Thing is, I’m not storing multiple values using the standard mode for the file formats. As I understand it:-
ID3v2.3 doesn’t handle multiple values, so Plex just works on ‘;’ delimited strings and is happy with that and it works.
v2.4 uses null delimited strings and this gets screwed by ffmpeg that only passes on the first value. But if that value is just a single text string delimited by ‘;’ then it should work same as for v2.3.
MPEG4 files use multiple tags/items and not multiple values in a single tag. Either way, I have read that Plex configures ffmpeg to forward each tag as a ‘;’ delimited string of multiple values.
So, if instead of trying to use the default mechanism for each type of file (which ffmpeg mangles), using a single tag with a single value (‘;’ delimited text string) WILL be forwarded by ffmpeg and correctly handled by Plex as that is what it is expecting.
From the copious reading I have been doing on this forum about this subject, it appears to me that the problems with ID3v2.4 are when v2.4s standard mechanism of null delimited strings is used, but if instead a single ‘;’ delimited string is used, it will work.
A ‘;’ delimited string works well for me also as Apple’s apps do not handle multiple tags and just take the first one, so Music.app will simply display the original ‘;’ delimited string which it will see as a single value. But that works fine for me as it’s way better than dropping everything except the first value.
The awaited fix in Plex is to make it correctly handle null delimited multiple values as specified for ID3v2.4, but that is not relevant to me - nor anyone else who wants their multiple tags to be visible in Apple’s apps.
I wish Plex published complete and accurate documentation about all this so we all know what to expect.
That info about the ffmpeg problem was mentioned in another thread on this problem by I think Certuna who posted the exact reason for why it fails with null delimited tags. It’s not an assumption I’ve made, but what I have read and makes sense as a reason why it fails. In fact the precise details are of course identified in the ffmpeg bug report which is where I think the details in the post came from.
That doesn’t of course mean that’s the only problem Plex is suffering, but I also seem to recall reading a Plex employee stating that ‘;’ delimited strings would work as that is how Plex configures ffmpeg - to parse the tags in whatever format and forward them to Plex as a ‘;’ delimited string which it then splits into individual tag values. So Plex is using ffmpeg (if it worked) to munge all different multi tag methodologies into the same ‘;’ delimited string which it then can easily deal with and since a single text string in any file format is forwarded to Plex, then it seems logical that using ‘;’ delimited strings is the current solution.
Not only would that suit me for the aforementioned reasons of Apple’s apps, but my understanding from the multitude of posts is that it should indeed work.
When you say you cannot get v2.4 to work, how are you preparing the files to test? Many tagging apps will represent the multivalves as a ‘;’ delimited string, but actually write them as null delimited as that is the v2.4 standard. But they substitute the ‘;’ for null in the display as you can’t see null.
One thing that became very apparent in all the other threads is the frequent misunderstanding and mixing up of what is displayed when tagging the files, compared to what is actually written to the file as that may not be the same.
I only use musicbrainz picard to tag my media, nothing else. When I test switching between v2.3 and v2.4 I use the setting charge in the app and update all the tags.
Sorry, just re-read your post and the assumption you mention is indeed mine that a single ‘;’ delimited string will work. My reply was about the ffmpeg problem, so my mistake.
However I have read that ‘;’ should work so it wasn’t just my assumption. I’ll just have to try it out I guess. I try to avoid testing things like this, preferring to first get the low down from ‘those in the know’ as usually more reliable than simple testing that may send you on a wild goose chase for other reasons.
