Writing of 'gnre' atom in MPEG-4?

[rboss]

Greetings to all,

Lately I've been playing around with the MPEG-4 container, and I'm having difficulty understanding what I'm seeing, so I'm turning to the community.

I've found a mention of the gnre atom here:

Conflicting Genre Tag - mp3tag vs. Lumin App

Thank you for the example file @g-man-langley ! I've analyzed the issue and it's related to two different ways of storing the genre in the MP4 tag. Mp3tag tries to use the gnre MP4 atom for genres that are part of the ID3v1 standard. This stores the index to the actual genre in this pre-defined genre list. For custom genres, it uses the ©gen MP4 atom, which is what Apple Music seems to expect now. The file in question uses the gnre atom (ID3v1 genre index), which also doesn't seem to be suppo…

but it doesn't seem to be related to the results I'm getting.

As I've done for ID3, I wrote my own tag reader for MPEG-4 in VBA, and while debugging I've noticed the gnre atom for an .m4a file tagged in MP3Tag (v3.33b5), which according to the file structure should contain an uint8 data type integer (which it does) representing a Genre type according to the ID3v1 list of genres.

So, according to the ID3v1 genre table, 'Blues' should be encoded with '00', Classic Rock with '01', and so on.

But looking at a newly tagged file in an hex editor, in the genr atom I'm seeing '01' for 'Blues', '02' for 'Classic Rock', etc.

There's nothing wrong with Mp3Tag; Genre is read and written correctly in the main window, and on music players everything is displayed correctly, so I know there's something wrong on *my* end. But since I'm looking at raw hex data, the value has to be just as it shows (converted to decimal, obviously).

But since it does not match the ID3v1 Genre tables I've searched, and I can't find any documentation on as to why it doesn't, I'm hoping a kind poster might point me in the right direction.

Thank you.

[Florian]

The gnre atom is indeed using the index of the ID3v1 genre table, but instead of being 0-based, it's 1-based, so 'Blues' is encoded with 0x01 instead of 0x00 and 'Rock' is 0x12 instead of 0x11.

[rboss]

@Florian

The gnre atom is indeed using the index of the ID3v1 genre table, but instead of being 0-based, it's 1-based,

Yes, thank you for confirming. I had to arrive at the same conclusion, given the evidences from Mp3Tag and the music players I had tested.

@rboss

But since it does not match the ID3v1 Genre tables I've searched, and I can't find any documentation on as to why it doesn't

But what I'm looking for is a reference. Because whatever documentation I looked, all mention(s) said "follows the ID3v1 convention", not "follows the ID3v1 convention, offset by +1".

Or to put it more simply: "What was your source to learn that the gnreindex is 1-based, instead of 0-based?"

I'd like to add that entry to my bookmark library of tagging documents, for future reference.

[Florian]

@rboss

What was your source to learn that the gnreindex is 1-based, instead of 0-based?

It's an undocumented MP4 atom invented by Apple/iTunes, I learned about this by observing iTunes' output and I don't think that there is any official documentation.

Please also note that Apple Music/iTunes will recognise this atom only if the datatype is set to unknown type 0x00 instead of signed integer 0x15.

[rboss]

@rboss

What was your source to learn that the gnreindex is 1-based, instead of 0-based?

I'm going to leave this particular question unanswered, because the deeper I dug, the weirder things got......

I've found exactly "0" references to a 1-based genre index list, or some kind of valid explanation for the "index+1" adjustment. Without any leads, I found myself forced to resort to....... AI
Which (surprisingly) yielded some results.

There was ONE possible rationale for the origin of the 0 OR 1-based divergence here, where it is stated that metadata keys are to be listed 1-based, and "0" is reserved.

As this wasn't very specific to the gnre atom specifically, I tried a different approach.
Foobar2000 also has its own (internal) tagging tool: using it on an .m4a file, its "traditional-type" genre is also filled with the same atom, but the hex value shows that the Genre index used is still 1-based.

From the fb2k wiki I found a tagging page, which in turn led to a tag mappings page, which in turn cited an QuickTime tags on the ExifTool website (for some reason?....) which in turn hosted a list of "QuickTime GenreID Values"..... that has nothing to do with the ID3v1 listing.

Anyway, because it had been mentioned on several sources that "More genres have been successively introduced in later Winamp versions" I thought to myself that "if anyone would have a player that read tag genres correctly that would be the company that helped to improve said list, right?"

So I installed Winamp, loaded a test .m4a tagged with 'Blues' genre...... and the raw data returned "1"....
- When it should have been "0"....
- On a player whose parent company literally helped create the standard....
- And changing the Genre value using Winamp also returned results from an 1-based index.

.... and at this point I stopped myself out of fear for my own sanity.

My personal conclusion is that this is a chicken and egg situation, where "some" tagging solution developer used the 1-based genre index -for some reason-, and as that tool gained popularity and started being referred to by other developers (and music player developers) it became an unofficial "norm".

And the lack of proper documental support from Apple only made things worse............

My apologies for taking your time on this wild-goose chase @Florian.

[rboss]

@rboss

I'm going to leave this particular question unanswered

Except not! I came across a mention of an internal Apple document called "iTunes Metadata Format Specification", of which I found a copy posted on Scribd, where -regarding the Genre index table- it clearly states

And this is the origin of the "offset by 1" indexes in the gnre atom.

Now, as for the reason why such an important document would not be publicly available in an official Apple knowledge library....... I'll think about that another day.

My thanks to all who helped me in this topic.