Have recently switched my workflow over to MP3TAG and have recently completed curating my audio library.
I'm in the process of revisiting the "Genre/Style" meta-tag in an effort to ensure that it is a simplified as possible and adheres (albeit somewhat) to standardization. I figure I'd post some links - most of you probably have already - that I found in case other newcomers to the community are looking for them.
I also have separate text file lists that I can upload in case someone can use them in their workflows.
I would like to clearify that this is MP3tag's representation of a multi-value field (which is not limited to the field GENRE).
MP3tag can read, display and write any of the above multi-genre formats of the various target programs - which is usally no multi-value field but a single field with added characters. MP3tag supports to split single fields into multi-value fields.
Agreed; different applications that provide multi-value field support use different methods to inject multi-values of a meta-tag field.
Using GENRE as an example; adding two genres separated by double backslash instructs MP3Tag to add HEX codes 0D 0A between each instance of GENRE. If I've correctly understood the ID3 standard, it is recommended to use the HEX code for NULL (00) ... as long as the separation method adheres to the standard and the player application (and tag editors) follow said standard, all should be good.
Once my post count goes up, I can upload an MP3Compare (BeyondCompare) screenshot that shows how the metadata header appears if anyone in interested.
When importing the multi-value field in iTunes, only the first instance of GENRE appears which makes sense as the Apple iTunes application only allows for a single field value.
Interesting; I'm set for ID3v2.3 UTF-16 not UD3v2.3 ISO-8859-1. Just had a look at the Help description and the thread you provided. Seems we're back to the age-old most universal format to use problem.
Appreciate the info.
For those curious of how it appears in UTF-16 as written by MP3Tag 3.00:
Yep; I'm seeing NULL as 00 in HEX view as well - so all should be good to implement multi-genre/style should I decide.
Just had a look to see what options are available in BeyondCompare for the MP3Compare built-in plug-in ... none. I'm going to assume MP3Compare is changing HEX: FF FE or HEX: 00 to signify a CR+LF is required in its viewer as a courtesy.