Bugzilla – Bug 15257
Sound Check conversion to db doesn't match iTunes
Last modified: 2011-10-17 06:03:43 UTC
Created attachment 6363 [details] Sound Check: iTunes vs. SB The current Sound Check conversion to db uses the the first two pairs of values in the iTunNORM tag. The assumption is that the first pair is for 1/1000 watts while the second pair is for 1/2500 watts. Thus, the second pair is first normalized to 1/1000 watts and then the largest of the four values is chosen for conversion to db. What I've seen is that the resultant db in SB is quite different than what iTunes displays for the same tracks. Digging into the code and playing around, I found that using just the first pair results in an almost perfect match for the value in iTunes. See attached spreadsheet. However, there are a few cases where iTunes is still different. My theory is that iTunes adjusts the normalization to avoid clipping, but I can't nail down exactly how they do it. I've found some anecdotal evidence suggesting that Sound Check interpretation may have changed around iTunes 8: http://radiologikusers.com/forum/comments.php?DiscussionID=113#CommentBody_640 In any case, using only the first pair matches iTunes much more closely that the current logic. Please update the code accordingly.
Success! In addition to normalization based on the first pair of values in the iTunNorm tag, iTunes also ensures that the peak value is at or below -1db. I assume this is to provide headroom for the equalizer and avoid clipping. Information on the algorithm is below and I'll attach an updated spreadsheet momentarily. I have a small sample size so independent verification on a larger sample would be appreciated. Note that extracting the iTunNORM tag is as simple as using strings (here with some cleanup and conversion as well): $ for ff in <files>; do echo -n "$ff,"; strings "$ff" | grep -A2 iTunNORM | grep '^ ' | perl -ne 'print join(",",map{hex($_)}split()),"\n";'; done <file1>,640,426,9028,6694,49946,49946,32768,26455,21942,45255 <file2>,943,996,9781,10541,145054,145054,28304,27838,128847,128847 I will follow up with a patch to the code/docs when I have time; please add a comment if you're planning to work on it. From the SoundCheck.pm documentation on the iTunNorm tag: ************************************************** 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 6/7: The peak value (maximum sample) as absolute (positive) value; therefore up to 32768 (for songs using 16-Bit samples). ************************************************** The normalization uses the max of the first pair (fields 0/1): NORM=-LOG10(MAX(<0/1>)/1000)*10 Here's the absolute value of -1db relative to the maximum sample of 32768 (it's ~29204.5): MINUS1DB=(10^(-1/20))*32768 The peak normalization uses the max of the fourth pair (fields 6/7): PEAKNORM=LOG10(MINUS1DB/MAX(<6/7>))*20 The volume adjustment is simply the MIN of those two normalizations: VOLADJ=MIN(NORM,PEAKNORM)
Created attachment 6382 [details] [SOLVED] Sound Check: iTunes vs. SB
Steven is not convinced that using this latest library is the right thing to do. We will continue looking at it.
The current Sound Check conversion logic used by Squeezebox Server is demonstrably inaccurate. The difference between Squeezebox Server and the correct volume adjustment varies from -1.25 dB to -10.56 dB for the songs I tested. This inaccuracy coupled with its variance effectively *denormalizes* the volume and results in much more pronounced volume differences between tracks. In other words, the current Squeezebox Server Sound Check code does the opposite of its intent. The new logic I laid out is correct for all 65 songs I've tested...
Andy, is this change something that could be done easily in Squeezebox Server?
Thanks for doing this research. Since you understand it the best, would you be able to work on a patch to the SoundCheck.pm module?
Andy to investigate.