If you have a problem or need to report a bug please email : support@dsprobotics.com
There are 3 sections to this support area:
DOWNLOADS: access to product manuals, support files and drivers
HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects
USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here
NEW REGISTRATIONS - please contact us if you wish to register on the forum
Users are reminded of the forum rules they sign up to which prohibits any activity that violates any laws including posting material covered by copyright
K2 - Peak Compressor
43 posts
• Page 1 of 5 • 1, 2, 3, 4, 5
K2 - Peak Compressor
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
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
- Rocko
- Posts: 186
- Joined: Tue May 15, 2012 12:42 pm
Re: K2 - Peak Compressor
Hey all,
Any user comments would be welcomed...
Any user comments would be welcomed...
- Rocko
- Posts: 186
- Joined: Tue May 15, 2012 12:42 pm
Re: K2 - Peak Compressor
Uhm, yeah, the article is quite informative. So how did you implement K2? If you post your schematic you'll probably get more response.
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
Re: K2 - Peak Compressor
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
-
Spogg - Posts: 3358
- Joined: Thu Nov 20, 2014 4:24 pm
- Location: Birmingham, England
Re: K2 - Peak Compressor
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
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
- Attachments
-
- K2_PEAK_STEREO.fsm
- (9.66 KiB) Downloaded 1387 times
- Rocko
- Posts: 186
- Joined: Tue May 15, 2012 12:42 pm
Re: K2 - Peak Compressor
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
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
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
Re: K2 - Peak Compressor
Hi,
Thanks for the answers.
Regarding this point:
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
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
- Rocko
- Posts: 186
- Joined: Tue May 15, 2012 12:42 pm
Re: K2 - Peak Compressor
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.
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.
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
Re: K2 - Peak Compressor
Hi,
This is getting interesting, thanks !
Topic_A:
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?
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?
- Rocko
- Posts: 186
- Joined: Tue May 15, 2012 12:42 pm
Re: K2 - Peak Compressor
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.
I should probably provide some examples.
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.
I should probably provide some examples.
-
martinvicanek - Posts: 1328
- Joined: Sat Jun 22, 2013 8:28 pm
43 posts
• Page 1 of 5 • 1, 2, 3, 4, 5
Who is online
Users browsing this forum: No registered users and 8 guests