Help - Search - Members - Calendar
Full Version: [X] Weird values for ITUNNORM field at M4A files
Mp3tag Forums > Mp3tag - International > Bug Reports > No Bugs
TechUser
btw, I don't know if this is incorrect, but when displaying ITUNNORMAL as a column
(%itunnormal%) on m4a files, it repeats the same 8-digit value ten times. (I don't know or care about this value, except to make sure it exists.)
dano
That's the typical value for this field.
TechUser
in m4 files I've also noticed bugs when users create two identically named fields (i.e. Vorbis style tags). That causes diffiiculties both in removing them and in getting all their values to display.

--update: only a display issue, shows only the first value (I was not able to re-create the m4a tag editing issue when I tried again).
TechUser
QUOTE (dano @ Jan 28 2009, 15:57) *
That's the typical value for this field.

Thank you--could you answer one more question about it: When I check in the ITUNNORM field created by apple's itunes, the ten subparts always have DIFFERENT values. But in mp3 tag, the ten subparts all have the SAME value. (I don't know how the ITUNNORM (soundcheck) system works, so perhaps that is correct, but I can't offhand see why they would always be the same in mp3tag and always be different in iTunes.)

(p.s. I realize now this question should have been a separate thread--this part may not be a bug at all, but the issue of multiple values in tags is.)
Florian
I'm not sure whether this is the case, but maybe the soundcheck data from iTunes isn't written to the files tag yet (but instead stored in the internal database).

I just did some tests and I'm getting different values. Btw, which application did you use to check the values?
Florian
QUOTE (TechUser @ Jan 29 2009, 10:32) *
in m4 files I've also noticed bugs when users create two identically named fields (i.e. Vorbis style tags). That causes diffiiculties both in removing them and in getting all their values to display.

What bugs are you talking about? Please be a little bit more specific, e.g., providing a test case to reproduce the issue.
TechUser
QUOTE (Florian @ Jan 29 2009, 15:59) *
I'm not sure whether this is the case, but maybe the soundcheck data from iTunes isn't written to the files tag yet (but instead stored in the internal database).

I just did some tests and I'm getting different values. Btw, which application did you use to check the values?

I used iTunes and mp3tag to check the values. (It might not be a bug. Just as a reminder to myself, there are two separate questions to check: 1. itunes values stored in itunes database vs itunes stored in file values, 2. mp3tag created value for soundcheck, and itunes created value for soundcheck. --minor discrepancy wouldn't matter, but it seems entirely different set of values.

(p.s. iTunes is a pain, so I may ditch it, but I think one needs itunes to make m4a files gapless for ipod playback--unless there's a switch in mp3tag to do the trick.)
TechUser
QUOTE (Florian @ Jan 29 2009, 16:11) *
What bugs are you talking about? Please be a little bit more specific, e.g., providing a test case to reproduce the issue.

Add two identically named custom tags to a m4a file with different values (under extended tags). Save. Then go to regular list display. only one of the values shows up (after you add it with customize columns). That may be by design; however, note that it is different from multiple values stored in one tag. Also note that it shows whatever tag happens to come first physically under extended tags, not what is first by alphabetic value of contents (not necessarily undesirable, but thought I should mention it).
--The editing bug I can't re-create now (seems to work fine now), so please ignore until (if) I can duplicate again. (My apologies.)
TechUser
On the ITTUNNORM field:
This is a follow-up to clarify a few points (all concerning m4a files):
1. I can confirm that the apple library is not at issue--I'm looking at the ITUNNORM tag (with mp3tag), the one created by iTunes and then the one created by mp3tag.
2. I use this action to have mp3tag create the ITUNNORM field (format action on ITUNNORM field):
$if($eql(%_extension%,'m4a'),$rg2sc(%REPLAYGAIN_TRACK_GAIN%),)
3. In iTunes, I have create soundcheck on.
4. iTunes creates a field that is a series of ten different subvalues for itunnorm, mp3tag always creates ten identical subvalues.
5. I haven't tested yet on an iPod.
garym
In mp3tag, look at the values for track replaygain and album replaygain. Sounds to me as if your track replaygain values are actually album values (which would all be the same for the same album). I can create ITUNNORM fields in mp3tag for AAC using your approach and it seems to work OK. Again, you should confirm that the replaygain track values are indeed different.

QUOTE (TechUser @ Feb 4 2009, 19:42) *
On the ITTUNNORM field:
This is a follow-up to clarify a few points (all concerning m4a files):
1. I can confirm that the apple library is not at issue--I'm looking at the ITUNNORM tag (with mp3tag), the one created by iTunes and then the one created by mp3tag.
2. I use this action to have mp3tag create the ITUNNORM field (format action on ITUNNORM field):
$if($eql(%_extension%,'m4a'),$rg2sc(%REPLAYGAIN_TRACK_GAIN%),)
3. In iTunes, I have create soundcheck on.
4. iTunes creates a field that is a series of ten different subvalues for itunnorm, mp3tag always creates ten identical subvalues.
5. I haven't tested yet on an iPod.
TechUser
Thanks. I checked--I do not use album replay gain, and I do not actually have any values for album replay gain. I have values only for track replay gain. Would this explain what's happening?

QUOTE (garym @ Feb 5 2009, 11:18) *
In mp3tag, look at the values for track replaygain and album replaygain. Sounds to me as if your track replaygain values are actually album values (which would all be the same for the same album). I can create ITUNNORM fields in mp3tag for AAC using your approach and it seems to work OK. Again, you should confirm that the replaygain track values are indeed different.
garym
QUOTE (TechUser @ Feb 5 2009, 21:51) *
Thanks. I checked--I do not use album replay gain, and I do not actually have any values for album replay gain. I have values only for track replay gain. Would this explain what's happening?


I don't think so. Odd. Can you post a screen shot (or listing of some sort) that shows a listing of files that includes the replaygain track value and the ITUNNORM value.
TechUser
QUOTE (garym @ Feb 5 2009, 18:20) *
I don't think so. Odd. Can you post a screen shot (or listing of some sort) that shows a listing of files that includes the replaygain track value and the ITUNNORM value.

Here are a few sample tracks:
RG track gain: -3.35 dB
RGpeak: 0.829680
ITUNNORM: 00000872 00000872 etc. (repeated ten times)

track 2:
+0.12db
0.813560
000003CC 000003CC etc.

track 3:
-3.21db
0.782561
0000082E 0000082E etc.
garym
perhaps I'm misunderstanding your question. this all looks normal to me. each track has a different replaygain value and a different itunnorm value. The itunnorm values are always a very long string of numbers/letters. Maybe you're saying that the itunnorm value is repeated many, many times for a single track. There should be some repeats (see one of my examples below). If you think your itunnorm values are messed up, the best thing to do is simply delete the ITUNNORM field in mass, then rerun your mp3tag action on all the files to create new itunnorm tags from the replaygain values. Or simply delete files from itunes, then readd files. it will then create new itunnorm values automatically.

here's an example of a correct ITUNNORM value from one of my AAC files:
00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789




by the way, why are you bothering to convert replaygain values to itunnorm in mp3tag. I do this so I can make the soundcheck values "album gain". but the regular soundcheck track values are virtually identical to what you are getting with replaygain track values.

QUOTE (TechUser @ Feb 6 2009, 19:01) *
Here are a few sample tracks:
RG track gain: -3.35 dB
RGpeak: 0.829680
ITUNNORM: 00000872 00000872 etc. (repeated ten times)

track 2:
+0.12db
0.813560
000003CC 000003CC etc.

track 3:
-3.21db
0.782561
0000082E 0000082E etc.
TechUser
Thank you. iTunes creates an iTunNorm value that is completely different from the one that mp3tag creates for the same track (iTunes creates different subvalues, mp3tag always creates ten identical subvalues). Rerunning the mp3tag action doesn't make a difference (it just creates the same values again, always ten identical numbers).

For example, here is the itunes value for iTunNorm on one track:
000003A6 00000000 00001039 00000000 00015FC8 00000000 00003D9C 00000000 00015F9A 00000000
mp3tag gives that identical track an iTunNorm value of (from replaygaintrack):
00000872 00000872 etc. (repeated ten times)

I'm not saying this is incorrect, but it would be good to know what the reason for the difference is, and if that indicates I should use iTunes instead. The reason why I use mp3tag is simple: I don't want to deal with itunes at all if I can avoid it.

QUOTE (garym @ Feb 6 2009, 13:32) *
perhaps I'm misunderstanding your question. this all looks normal to me. each track has a different replaygain value and a different itunnorm value. The itunnorm values are always a very long string of numbers/letters. Maybe you're saying that the itunnorm value is repeated many, many times for a single track. There should be some repeats (see one of my examples below). If you think your itunnorm values are messed up, the best thing to do is simply delete the ITUNNORM field in mass, then rerun your mp3tag action on all the files to create new itunnorm tags from the replaygain values. Or simply delete files from itunes, then readd files. it will then create new itunnorm values automatically.

here's an example of a correct ITUNNORM value from one of my AAC files:
00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789 00001789
by the way, why are you bothering to convert replaygain values to itunnorm in mp3tag. I do this so I can make the soundcheck values "album gain". but the regular soundcheck track values are virtually identical to what you are getting with replaygain track values.
dano
The reason is simple. Only Apple knows the meaning of all these digits.
When people tried to reproduce the soundcheck algorithm they found out that only the first group of digits tetermines the volume. The function of the other digits is unknown but they don't seem to affect the volume.
So the first group is simply repeated.
Moonbase
The iTunNORM tag consists of 5 value pairs. These 10 values are encoded as ASCII Hex values of 8 characters each inside the tag (plus a space as prefix).

The tag can be found in MP3, AIFF, AAC and Apple Lossless files.

The relevant information is what is encoded in these 5 value pairs. The first value of each pair is for the left audio channel, the second value of each pair is for the right channel.
  • 0/1: Volume adjustment in milliWatt/dBm*
  • 2/3: Same as 0/1, but not based on 1/1000 Watt but 1/2500 Watt.
  • 4/5: Not sure, but always the same values for songs that only differ in volume - so maybe the »listenability index«**.
  • 6/7: The peak value (maximum sample) as absolute (positive) value; therefore up to 32768 (for songs using 16-Bit samples).
  • 8/9: Not sure, same as for 4/5**.
* = The value 0 is special, the equation is not used and it is treated as "no Soundcheck". Otherwise: X = 1000 * 10 ^ (-0.1 * Y) where Y is the adjustment value in dB and X is the value that goes into the SoundCheck field.

** = Probably another place to hide the »listenability index«, a complex algorithm that factors in a wide range of values to determine if your songs have »maximum listenability«. This is to insure that certain songs get played more often than others. Apple secretly kowtowing to corporate interests and their desire to control our listening habits. Maybe we should find out how to set a value that prefers our songs instead. (Suggestion: Make it an optional second parameter in $rg2sc().)

iTunes is choosing the maximum value of the both first pairs (of the first 4 values) to adjust the whole song. (This is also why Mp3tag’s »brute-force all values same« succeeds: n/1000 is always more than n/2500.)

Would be nice to see this in $rg2sc() and $sc2rg(), eventually … cool.gif (So I wouldn’t have to do this stuff in Perl all the time …) I guess Mp3tag could easily fill in value pairs 0/1, 2/3 and 6/7 with the correct values.

Keep in mind that iTunes SoundCheck normalizes based on the loudest audio sample in each track, so its not a real ReplayGain value! iGain and iVolume (3rd-party apps) make a better value since both are using the ReplayGain algorithms instead.

Maybe this is the reason why Florian made $rg2sc() a »one-way route« (by not implementing $sc2rg()). One should always prefer ReplayGain over SoundCheck — it gives the much better results. (So converting from RG to SC is a good thing, while converting from SC to RG is a bad thing — you’re better off recalculating the RG in this case.)

Anyhow, it’s still better to use RG in general because you have the choice between using the »Radio« (track) and »Audiophile« (album) settings in the player. iTunes SoundCheck only stores one set of settings, so you would have to decide before storing the tags (like with MP3Gain if applying RG).
TechUser
Thank you for that complete & conclusive explanation. I think I will go ahead and use aacGain/iGain. (Also, I assume my car's player would do nothing with soundcheck--unless I used it as an ipod receiver.) It's too bad apple hasn't been providing documentation on its m4a/qt tags (and the alac format), but you've more than answered my questions about iTunNorm.
pueblo funky
w00t.gif
QUOTE (Moonbase @ Feb 7 2009, 17:25) *
The iTunNORM tag ...


Thanks god that I don't use iTunes walkman.gif
RichieB
I just wrote a ReplayGain to SoundCheck converter perl script (for mp3) since I could not find a solution for Linux, and found this thread when searching for the syntax of the iTunNORM tag. Since mp3tag is not available for Linux, I thought it might be good to post it here.
Florian
QUOTE (RichieB @ Apr 12 2009, 20:04) *
Since mp3tag is not available for Linux, I thought it might be good to post it here.
It's not available natively but works fine under Wine. Anyway, thanks for sharing!
chrizoo
QUOTE (Moonbase @ Feb 7 2009, 16:25) *
** = Probably another place to hide the »listenability index«, a complex algorithm that factors in a wide range of values to determine if your songs have »maximum listenability«. This is to insure that certain songs get played more often than others. Apple secretly kowtowing to corporate interests and their desire to control our listening habits. Maybe we should find out how to set a value that prefers our songs instead. (Suggestion: Make it an optional second parameter in $rg2sc().)

very unlikely. I rather think the value is something like an audio footprint of the music, by which the user can tell iTunes to play similar songs (to the current one).
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.