# Writing of 'gnre' atom in MPEG-4?
**URL:** https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344
**Category:** Support
**Created:** [December 15, 2025, 2:59am UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344 "2025-12-15T02:59:04Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [December 15, 2025, 2:59am UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/1 "2025-12-15T02:59:04Z")
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](https://community.mp3tag.de/t/conflicting-genre-tag-mp3tag-vs-lumin-app/69825/76):
>
> 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](https://atomicparsley.sourceforge.net/mpeg-4files.html) 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](https://en.wikipedia.org/wiki/List_of_ID3v1_genres), '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.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 15, 2025, 6:00am UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/2 "2025-12-15T06:00:36Z")
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`.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [December 17, 2025, 3:20pm UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/3 "2025-12-17T15:20:19Z")
> [@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 `gnre`index is 1-based, instead of 0-based?"
I'd like to add that entry to my bookmark library of tagging documents, for future reference.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [December 17, 2025, 3:39pm UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/4 "2025-12-17T15:39:44Z")
> [@rboss](#):
>
> What was your _source_ to learn that the `gnre`index 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`.
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [December 18, 2025, 12:13am UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/5 "2025-12-18T00:13:02Z")
> [@rboss](#):
>
> What was your _source_ to learn that the `gnre`index 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](https://share.google/aimode/RBwcOQLvhpPzMlUmo).
There was ONE possible rationale for the origin of the 0 `OR` 1-based divergence [here](https://developer.apple.com/documentation/quicktime-file-format/metadata_item_keys_atom), 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](https://www.foobar2000.org/) 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](https://wiki.hydrogenaudio.org/index.php?title=Tag_(metadata)) page, which in turn led to a tag [mappings](https://wiki.hydrogenaudio.org/index.php?title=Tag_Mapping) page, _which in turn_ cited an [QuickTime tags](https://exiftool.org/TagNames/QuickTime.html) 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](https://winamp.com/player) 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](https://en.wikipedia.org/wiki/Chicken_or_the_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. 🙂
---
### Author:  [@rboss](https://community.mp3tag.de/u/rboss)
#### Post date: [December 20, 2025, 6:43pm UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/6 "2025-12-20T18:43:49Z")
> [@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](https://www.scribd.com/document/71943605/iTMF-Specification?language_settings_changed=English), 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. 👍
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [January 19, 2026, 6:44pm UTC](https://community.mp3tag.de/t/writing-of-gnre-atom-in-mpeg-4/70344/7 "2026-01-19T18:44:06Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.