Rockbox Development > Feature Ideas

Compressor

(1/1)

Transmogrifox:
First -- greetings to all.  This is my first post, so I thought I would use this as an opportunity to extend a thanks and kudos to those who have worked to develop and improve Rockbox.  It seems to be an active project perpetually improving.

Now to business ;)

After having tried using the compressor I stopped using it because it takes away clarity and causes music to sound wooly.
I have looked into the code and created a laundry list of ideas to help improve the clarity of the sound:
1)  Attack time parameter. 
>> Currently the attack time is 0ms, or rather, a leaky peak detector.  This clips an onset and smears transients.

2)  Sidechain EQ.  Application of sidechain high-pass filtering similar to what is found in the JoeMeek compressor will help reduce compression on low frequency material thereby reducing distortion and preserving high-frequency content.

3)  Exponential attack & decay characteristic.  This will require a first order digital filter (y[n] = a*x[n] + b*y[n-1]) creating two multiplication terms as compared to the single addition for linear release.  However, the linear release sounds very mechanical to my ears.
(1), (2) and (3) are a bare minimum for an industry standard compressor.

(4)  Delay line for a certain amount of look-ahead compression.  I'm thinking attack times of 5ms to 20ms and a delay line on the same order of magnitude, so it will not be a severe memory hog.

I am working slowly on coding some of these things myself, but certainly I will need to take more time to learn how the rest of the system treats settings and the user interface.  The only "new" thing added to the user interface would be Attack time parameter, so it should be pretty simple.  The rest would be hard-coded, automagic (unless people started requesting EQ presets for the sidechain).  I think selecting an EQ curve and hard-coding it will be more than adequate to improve clarity.

I have hard-coded the linear attack at 15ms, and this makes a difference in the clarity of the transients, enough that the compressor is tolerable enough to use.  Of course, there will be clipping when the transient exceeds 0dB, but it's much more transient headroom than the current algorithm.

I would like to make sure if the original developer of the compressor is reading this that it is clear that I think it is a well-written piece of code -- things are done very efficiently and it does not waste hardware resources.  I am suggesting features that will push the hardware requirement/performance balance more in the direction of performance. 

Of course, even if these suggestions are never implemented in the distribution of Rockbox, one can be assured I will always have a compressor that is perfect for me, so thanks for the giant shoulders on which to stand :)

saratoga:
If you have questions, IRC is a good place to ask. 

Transmogrifox:
Saratoga -- thanks for the heads-up. 
I will probably show up in IRC when I get past the low-level DSP stuff and start asking myself questions about how to adjust it through the user interface.

Transmogrifox:
I have put some code in gerrit.  I apologize for the multiple commits and all that comes with my being new to gerrit and Rockbox for that matter.
 I thought I would at least post something here so there is indication of activity on this front.

At the moment #3 (exponential attack and release) is implemented.  In its current form, it has a hard-coded attack time.

As for me, I think it makes my music sound a little more "open".  A look-ahead function will be my next target.  That is easy to implement, and it will reduce the initial transient overshoot (prevent clipping).

Navigation

[0] Message Index