Page 1 of 5

K2 - Peak Compressor

PostPosted: Mon Dec 26, 2016 10:14 am
by Rocko
Hi all,

Following the 'K1 RMS compressor' I'd like to share with you the next example, this time a PEAK compressor.

K1 RMS compressor:
http://www.dsprobotics.com/support/viewtopic.php?f=3&t=5976&p=28462#p28462

As discussed on the former thread (K1 Compressor) any compressor needs an ED (Energy Detector) to activate its 'Side chain' or 'gain computing channel'. These can be divides into RMS or PEAK based.

RMS based ED's mimic the way that the human ear perceives SPL changes and is good for 'normalizing' tracks, flatennning the SPL changes between different sources and overall SPL control. An RMS detector is designed to ignore short peaks, causing the whole compressor to 'miss them out' (for good or bad).

A PEAK detector is designed to catch these short peaks, so naturally it is more recommended for controlling fast transients and specific instruments (drums, kicks, plucks). Peak compressors also serve better for De-Essing tasks.

The design itself is based on the following article (already mentioned on this forum):
https://www.eecs.qmul.ac.uk/~josh/documents/GiannoulisMassbergReiss-dynamicrangecompression-JAES2012.pdf

K2's ED is designed as a 'smooth peak detector', placed in the log domain, just after the TF (Transfer function). See the article itself for more details...

For me, it was very interesting to run both designs (K1 and K2) on similar musical material and audition how they act completly different. I invite you to do the same and share with us any interesting findings.

I do plan to share the code itself, once more mileage is done with this design.
{next steps: GUI design with sliders, Wet/Dry knob, Look ahead buffer}

Please do send your remarks !

Rocko

Re: K2 - Peak Compressor

PostPosted: Tue Jan 10, 2017 2:30 pm
by Rocko
Hey all,

Any user comments would be welcomed...

Re: K2 - Peak Compressor

PostPosted: Wed Jan 11, 2017 7:51 pm
by martinvicanek
Uhm, yeah, the article is quite informative. So how did you implement K2? If you post your schematic you'll probably get more response. ;)

Re: K2 - Peak Compressor

PostPosted: Thu Jan 12, 2017 9:56 am
by Spogg
martinvicanek wrote:Uhm, yeah, the article is quite informative. So how did you implement K2? If you post your schematic you'll probably get more response. ;)


+1 here. My main interest in seeing others' work is to learn something from it. And, of course, "borrow" bits and pieces for my own projects if I find something interesting for me that I can make use of.

Cheers

Spogg

Re: K2 - Peak Compressor

PostPosted: Sat Jan 14, 2017 6:20 pm
by Rocko
Understood. Here it is.

Notes:
1. Minimal GUI at this stage. I keep GUI's for last.

2. Stereo version. Notice the approach to stereo detector.
It first runs 'abs' on each of the input channels and then finds the maximum.
I'm sure there are better implementations for stereo detection as 'abs' is not really continues and finding the
maximum of any of the channels is not continous either (based on input of course).
Do you have any suggestions for a smarter stereo detector and input files to test this topic?

3. I wonder about the need for 'DeZippers' for the time constants. After all, changing a time constant (attack or release) value, will only go into a first-order formula such as: Y = Yn1 * Alpha + (1- Alpha) * x
So these changes are smoothed anyway.
(I hope I explained myself well).

4. No limiter as I trust the user to add a brick-wall limiter at the end of the process chain/buss. I'm trying to mimic 'pro audio' processors (not a synth) and those come without internal limiters. Any comments are welcomed.

5. Any comments are welcomed. soundwise, logic wise or other...

6. Future fetures: Look ahead, Wet/Dry, GUI

Rocko

Re: K2 - Peak Compressor

PostPosted: Sun Jan 15, 2017 8:23 pm
by martinvicanek
2. I think it is natural for a peak compressor to take abs of left and right channel and then max, (For an RMS compressor you would add the squares of left and right.)

3. Basically correct, however, the dezipper uses very little CPU so if in doubt just throw it in.

5. I'd change the processing order like this:

a) max(abs(L), abs(R))
b) compute envelope with attack/release
c) compute transfer curve with threshold and ratio
d) apply compression

Re: K2 - Peak Compressor

PostPosted: Sun Jan 15, 2017 8:56 pm
by Rocko
Hi,

Thanks for the answers.

Regarding this point:
5. I'd change the processing order9 like this:


That article I had mentioned is pretty convincing on why to use that specific order of processing to achieve lower THD.
Notice that my other suggested compressor (K1 RMS) is based on this order: ED --> EF--> TF. As you suggest.

Rocko

Re: K2 - Peak Compressor

PostPosted: Mon Jan 16, 2017 8:13 am
by martinvicanek
Rocko, that's interesting. I realize the advantage of smoothing the control signal rather than the controlling signal, i.e. place the averaging further down in the processing chain. Note, however, that smoothing in the log domain will underrate peaks. Let me take a rather drastic example to illustrate the point:

Suppose that your signal has a strong 40 dB peak (100 times the amplitude) for half of the smoothing interval. Placing the peak detector in the log domain will register a peak of only 20 dB. In contrast, a peak detector before the log domain would detect a peak of factor 50.5 equivalent to 34 dB.

So I'm not sure about the peak detector in the log domain. Have you done some testing in that regard?

P.s. Harmonic distortion is another important consideration, yes. In my compressor design, I am approaching this by replacing the common one-pole smoothing filter by one with a much steeper falloff at high frequencies. The trick is to keep latency low.

Re: K2 - Peak Compressor

PostPosted: Sun Jan 22, 2017 11:22 am
by Rocko
Hi,

This is getting interesting, thanks !

Topic_A:
Suppose that your signal has a strong 40 dB peak (100 times the amplitude) for half of the smoothing interval. Placing the peak detector in the log domain will register a peak of only 20 dB. In contrast, a peak detector before the log domain would detect a peak of factor 50.5 equivalent to 34 dB.

So I'm not sure about the peak detector in the log domain. Have you done some testing in that regard?


Well, no - I have not tested the system with such a demanding signal. I'd like to build such a signal for testing it.
Here is my test procedure, please do mention if you agree/recommend:

1. Build a similar compressor with envelope follower BEFORE the log domain.
2. With a DAW, build a test-file with complete ZEROs and change just one sample to full-scale. (DIRAC IMPULSE ?)
3. Set the compressor to Thrsehold = (-40 dB) and Ratio = 99
4. Add a 'maximum' readout to enevelope follower of both tested compressors.
5. Log the maximum readout as well as recrded output signal.

Would this be to harsh a test (to fast)? Any other recommendations for testing?

Topic_B:
Can you please explain?

Re: K2 - Peak Compressor

PostPosted: Sun Jan 22, 2017 11:40 pm
by martinvicanek
Topic B: harmonic distortion.
The point is that if you have ripples on your envelope follower, these will modulate onto the compressed signal, resulting in harmonic distortion. You can suppress the ripples by lowpass filtering, but the stronger the filter, the more latency you end up with. The trick is to find the sweet spot. I have found that a FIR filter with a steep passband-stopband transition performs well. Another advantage of a (linear phase) FIR filter is that you have a well-defined delay, so you can choose a consistent look-ahead time.
:roll:
I should probably provide some examples.