sampsyo/beets — pull request #65 by azmd (2012-11-08 16:40:15+00:00)
Title: Fixed 'replaygain_track_peak' and 'replaygain_album_peak' calculation

The new replaygain implementation calculates the peak values incorrectly.
mp3gain output needs to be divided by 32768 so you don't put extremely high
peak tags into your mp3s, which e.g. make mpd just output a hiss.

Compare the current calculation results:

replaygain: analyzing 6 files
replaygain: analysis finished
replaygain: applied track gain -8.86, peak 38043.429833
replaygain: applied track gain -8.38, peak 33895.81121
replaygain: applied track gain -10.37, peak 35210.236455
replaygain: applied track gain -7.4, peak 35696.008207
replaygain: applied track gain -9.13, peak 38770.289432
replaygain: applied track gain -10.52, peak 34468.498939
replaygain: applied album gain -9.59, peak 38770.289432

to those I think are correct:

replaygain: analyzing 6 files
replaygain: analysis finished
replaygain: applied track gain -8.86, peak 1.160993
replaygain: applied track gain -8.38, peak 1.034418
replaygain: applied track gain -10.37, peak 1.074531
replaygain: applied track gain -7.4, peak 1.089356
replaygain: applied track gain -9.13, peak 1.183175
replaygain: applied track gain -10.52, peak 1.051895
replaygain: applied album gain -9.59, peak 1.183175

According to the specification
http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_1.0_specification

"Peak levels are specified textually as a positive decimal. Peak level is a
dimensionless quantity with 1.000000 representing full scale. No suffix is
included on peak values. The integer field (c) is typically 1 or 0. Six numeric
digits in the decimal field (dddddd) is adequate to accurately represent peak
values for 16-bit audio data."