GNOME Bugzilla – Bug 494499
replaygain analysis slowdown on low volume (denormals)
Last modified: 2007-11-13 07:50:17 UTC
The RG analysis is awfully slowing down on low volume content. Usual case: "hidden" tracks on CDs with content after a few minutes of near-silent. This is caused by denormal handling on x86 cpu. Different easy fixes are possible: #1: always add a small value to the computation, small enough to not significantly change the overall result. This is, as an example, done in MPC and LAME: http://svn.musepack.net/libreplaygain/src/gain_analysis.c http://lame.cvs.sourceforge.net/lame/lame/libmp3lame/gain_analysis.c?view=markup #2: if values are small, clear result to 0. This is done in WavPack: http://svn.slomosnail.de/wavpack/trunk/cli/wvgain.c (in every source code linked, search for "denormals")
This is a known problem, I'll provide a patch this evening.
Created attachment 98985 [details] [review] Avoid slowdown from denormals when processing near-silence input * gst/replaygain/rganalysis.c (yule_filter): Avoid slowdown from denormals when processing near-silence input data. Spotted by Gabriel Bouvigne.
Thanks, committed: 2007-11-12 Sebastian Dröge <slomo@circular-chaos.org> Patch by: René Stadler <mail at renestadler dot de> * gst/replaygain/rganalysis.c: (yule_filter): Avoid slowdown from denormals when processing near-silence input data. Spotted by Gabriel Bouvigne. Fixes #494499. PS: AFAIK one can set a FPU flag on x86 to treat denormals as zero. I'll investigate and maybe we can use this in core somewhere to prevent things like this.
FPU flag: it could be done this way, but then you have to be sure that either the component is running within its own thread, or that every component is aware of the FPU being comfigured this way. In the very specific context of this ReplayGain element, the current fix can probably be considered safe and correct, as we are using it for years within Lame.