This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#10612 - Dynamic Range Compressor
Attached to Project:
Rockbox
Opened by Jeffrey Goode (Blue_Dude) - Tuesday, 22 September 2009, 18:15 GMT+2
Last edited by Jeffrey Goode (Blue_Dude) - Saturday, 03 October 2009, 03:59 GMT+2
Opened by Jeffrey Goode (Blue_Dude) - Tuesday, 22 September 2009, 18:15 GMT+2
Last edited by Jeffrey Goode (Blue_Dude) - Saturday, 03 October 2009, 03:59 GMT+2
|
DetailsThis patch replaces the limiter, which was, well, limited. A new sub-menu opens in the place of the limiter preamp which contains the following settings: threshold, ratio, makeup gain, knee, attack time, release time, and auto peak.
Threshold ranges from Off to -30db in 3db steps. It controls the level at which the compressor starts to work. Ratio is in 5 steps: 2:1, 4:1, 10:1, 20:1, and 60:1. This controls how much the signal is compressed above the threshold. At 2:1, the signal is mildly compressed. At 60:1 it is essentially a limiter, and the signal is reduced in gain to such an extent that its not allowed to rise above the threshold. Makeup gain ranges from 0 to 20. It applies this gain to the signal after compression to "make up" for volume loss. Knee has two setting: hard knee and soft knee. Hard knee engages full compression exactly at the threshold. Soft knee engages compression gradually from -3db to +3db of the threshold. Attack time ranges from 2.0 to 6.5 ms. It looks ahead this amount to compress the signal slightly before it's required. Release time ranges from 20ms to 200ms. It slowly reduces the amount of compression after it's required. Attack and release work together to reduce distortion and volume "pumping". Auto peak, when enabled, overrides the makeup gain setting and raises it to its maximum to just avoid clipping. This version removes reference to IRAM settings for everything except a single buffer that gets a lot of use, so there's a big RAM hit. This is due to running out of IRAM on some targets when I included everything. I would appreciate testing on different targets, especially Coldfire targets like the h100/120, to see if this results in an unacceptable performance hit. If the performance is acceptable, I will probably do something like the timestretch feature does and only allocate the buffers if this feature is specifically enabled, which would fix the RAM hit. Currently, the compressor is triggered with peak sensing only. Incorporating an RMS sensing feature is possible but I suspect that performance would suffer enormously. Feedback, feature suggestions, and testing (with test_codec) would be greatly appreciated. |
This task depends upon
Closed by Jeffrey Goode (Blue_Dude)
Saturday, 03 October 2009, 03:59 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed in r22832 / r22834
Saturday, 03 October 2009, 03:59 GMT+2
Reason for closing: Accepted
Additional comments about closing: Committed in r22832 / r22834
This version is probably 99% complete.