[X] BUG: something amiss with genre fields in m4a/mp4

i normally deal in mp3 and flac, and i don't have many m4a/mp4 files, so i didn't notice this until now.

however, at some point a few winamp versions back i standardized all my files with winamp to a set list of genre tag possible values. np, winamp seemed to do it fine.

so whats the problem you say? everything seems to be as intended...

well, i was doing some routine maint on the collection, so i ran everything thru mp3tag 2.52, and suddenly i notice some strange values in the genres for some of these files. some are correct, meaning what i set, but some are values i don't use, and that DON'T appear in winamp AT ALL.

i do "extended tags" and indeed, i only see what mp3tag reports, not what winamp and other apps report.

so the question is which is wrong? what i can't fathom, is how both apps are divergent, even after specifically told to "refresh" whats displayed?

if it is "multiple frames" why don't i see the winamp values in mp3tags extended tags?





in depth discussion where winamp devs claim mp3tag is to blame:


The problem here is the files have two sets of tags (like ID3v2 and APE on mp3).
The itunes tags is what most programs can only read.

But there are also tags most likely written by foobar+nero aac encoder which I think only foobar and Mp3tag can read and also prefer to display.
But there are no settings to disable them or to remove them.

(Only your first example file is affected by this, the others seem to be fine. They are duplicates btw)

To get rid of the nero tags add a DISCNUMBER tag in Mp3tag or remove the TOTALDISCS tag.
Then Mp3tag will remove the nero tags because they are no longer needed.
It rewrites the itunes tags with nero tag values so you might have to correct them.


thx for the reply as i know you to be quite knowledgeable.

however regarding mp3tag this is very confusing to say the least. with mp3, dual tags is noted in the tag column:

%_tag_read%[ (%_tag%)]

so why would mp3tag not indicate this circumstance with mp4/m4a as it does with mp3?

also, why would mp3tag not have the option to remove them? obviously the easy workaround is to just use them and make them congruent with the "normal" tag most apps use, but this feels inappropriate, as they could be updated again, and ergo again become divergent.

the bigger issue is i can't know which files may have the issue, b/c the issue is easily concealed. i could have files with the issue right now that just aren't making it obvious.

imo, mp3tag should address this properly.

i don't follow you here at all. what duplicates? those are three different files, and three different songs, two of which have the problem.

  1. smithereens, everything i have is blue, incorrectly showing "Alternative & Punk" as the genre, should be "Classic Rock"
  2. monkees, the girl i knew somewhere, correctly showing "Adult Pop"
  3. monkees, you just may be the one, incorrectly showing "Pop-Rock Oldies" should be "Adult Pop"

(the second file was my "control group" file in the winamp thread)

i have some other problem files i could post if desired?

i am confused by this... why does mp3tag operate like that? why overwrite the existing data (if there) in the other tag? if you are deleting the bad version, why does mp3tag assume the data in it is better than the other tags existing data?

this is risky... so i either do my workaround, which means i could have data become divergent again, or i use your solution, and risk bad data overwriting good data, b/c i can not be sure what values will win out, what was merged, etc...

I'm sorry I didn't notice I clicked one link twice. So no problem with the downloads.
File 1 and 3 have the issue, File 2 is fine.

I made two tables where you can compare the tag differences...

aac_nero_tags.rar (2.08 KB)

thank you, and i find this interesting. but i have the feeling you want me to glean a point from this, that i'm afraid i'm missing...? i'm curious what you think of mp3tags behavior with such cases?

also, i've been reminded that mp3tag doesn't show when a FLAC has an id3v1.x tag in it, only v2.x, so a somewhat similar issue.


look at this thread:


i think maybe i have misunderstood you. i took what you said to mean that "Totaldiscs" is to be found ONLY in nero type tags, and so removing it would revert to itunes type tags.

however, this seems to be mistaken, in that itunes does create and use that field.

so why does your fix work? and do you have any ideas as to the guys problem in the winamp thread?


No, your problem was because you only had the Totaldiscs tag and no Discnumber tag.
These two are internally one tag like a x/y format.

So if you only have the Totaldiscs tag, the program can't write it as a normal itunes tag and it has to add the nero tags.
If you later add a discnumber tag it does not need the nero tags anymore. Or if you delete the Totaldiscs tag.

I don't know about that other issue. I doesn't look like there are nero tags inolved.

So what would the proper behavior be for the apps so it can be fixed and congruent?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.