[X] Weird values for ITUNNORM field at M4A files

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 … :sunglasses: (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).