Compressor design issue

[gilzad]

Hi Night, please don't hate me for this

I've been wanting to mention that something is strange about the compressor, but I wasn't sure until I did some exclusive tests.

Put short: The compressor attacks more than it should.

Put long: I'll be talking in absolute values here, just to keep things simple.

In case the compressor is configured this way: Threshold=256, Attack=0, Release=1, Slope=100%
- Then the compressor will duck more than 100%, if the input volume of a sine wave is greater than 356 (that's the original volume + 100). So the output will be quieter than the allowed threshold. This must not happen, if the slope is ==100%. Instead "100%" should be just as much as we need to keep the output volume at 256, so to stay conform with the threshold's limit.

In case Slope is ==40%
- Then the compressor will not compress an absolute loudness of 256+100 so much, that only a loudness of 256 remains. A bit more comes through. I'd say that's okay for a slope of 40%.

But if the input loudness reaches an absolute value of 656 and the Slope is still at 40%
- Then again the compressor's output will become quieter than its threshold allowed. Only at an absolute loudness of 456 (~ original+80%) the compressor won't duck more than its Slope and Threshold allows.

Conclusion is:
If the Sloope is < 100%, you can never compress a static portion of a signal. It's always possible to boost the input so much that the whole signal gets muted. In other words, you can never say "10% of my signal will remain uncompressed".
If the Slope is == 100%, you can never boost quiet parts to the level of the compressor's thresold. Because louder parts will be compressed more than 100%, that's what causes the unusual 'muting' in the compressor.

This example shows how the compressor is working with its default values, except of the Attack time, which is set to 0. It's being fed with a sine wave whose volume level is raising each time from 256, over 356 ... and finally to 656. Don't bother about the peaks that get through. Only the part behind it is important.

This wave file shows how a compressor should manipulate the same fading sine-wave. In a wave editor you'll see how its loudness is kept longer at one level each time.

As always, I'm always there if you should need more info.

[NightRadio]

Hi Gilzad!

The compressor attacks more than it should.

Yes :) Discrete size of the SunVox Compressor is 1 millisecond. So if the Attack is zero, compressor response will reach the listener 1 ms later.
Why it is so?
Because it is 44 times faster than the pure compressor algorithm :)
But i think i can add some option to minimize this discrete in future SunVox updates.

As for the second part of your question - seems that the current algorithm of Gain calculation is not correct in SunVox. I need to check more open source compressors... :)

[NightRadio]

Please remind me what is your system. I want to make a test version with slightly changed compressor.

[gilzad]

Hiya Alex!

So if the Attack is zero, compressor response will reach the listener 1 ms later.

No, no. Sorry, I caused confusion when I wrote "attacks more than it should", I didn't mean "slower". The attack time of 1ms is just normal. The "lookahead" feature (it's not my invention) can be used to overcome this, but it adds delay. Of course it would be great, if the native compressor could control the volume for the very first sample. With only 1ms buffering, that would be a pretty good compressor.

But actually the whole post was about the gain calculation. A field of
[10, 80, 99, 80, 10]
..becomes compressed something like
[10, 79, 70, 79, 10]
..while the threshold was 79 and slope was 100%. So it should be
[10, 79, 79, 79, 10]
edit: ..if attack & release were 0, of course. My explanations suck. :)

Sure, I'd love to do tests! My system is Debian 6, kernel 3.2 rt, amd64 compile.

[NightRadio]

Ah, ok :)

Please test this version: http://warmplace.ru/soft/beta/sunvox_co ... r_test.zip
I changed the gain calculation algorithm.

[gilzad]

Hi Night,

it's perfect! And it has a really high quality for fast release times.
Only a couple of minor things.

1)
If I have attack=500 and threshold=0, I only hear and see an attack time of ~1ms. This seems to be too short for 500 ms, but I am subjective here.
If I have attack=500 and threshold=1, then I can hear and see the long attack time. That's good and how I expected it to be.

2)
I see a "VERS" a entry in the sunvox files. Does SunVox write a version info into the .sunvox songs? Some sort of backward compatibility would be great then. Old songs could be opened with the old compressor, but it would no longer be available in the DSP list, so new songs would be created with the new compressor.

[gilzad]

A bug in the new compressor, that might be related to 1):
If the threshold is at 0 and the compressor is fed from a sidechaining channel, then it will mute the sound for 7 seconds, regardless of the specified release-time. I tested this at 44.1 KHz , with the compile from March 29th.
Here is a demo file that demonstrates the bug.

[NightRadio]

Ok, please try it again
http://warmplace.ru/soft/beta/sunvox_co ... r_test.zip

I see a "VERS" a entry in the sunvox files. Does SunVox write a version info into the .sunvox songs? Some sort of backward compatibility would be great then. Old songs could be opened with the old compressor, but it would no longer be available in the DSP list, so new songs would be created with the new compressor.

Yes :)
And please recreate your test project, because SunVox base version (BVER) has been changed to 1.7.3.2, and this is minimum requirement for the new Compressor algorithm.

[gilzad]

Hi Night & happy Easter!

Cool, you've been thinking of everything :)

I tested the compile of 1st April. The attack behaves correctly now, but in this version sound still comes through, even after the attack (e.g. 500 ms) has passed at a threshold of 0. I would expect that the sound will be faded out during 500 ms until the threshold level is reached. And if the threshold is 0, then the sound should be muted after 500 ms. But even if the Slope is at 200 %, I can still hear a sine wave coming through.

The "classic" compressors I know, don't offer a threshold that senses absolute amplitude levels, thus they are not able to mute. But in Sunvox, if someone really decides to set Slope=100 and threshold=0, then at some point a muted output would make sense. However, maybe the threshold is sensing something else than an absolute amplitude value. Then of course 0 doesn't neccessarily mean that "the output will be reduced to 0".

[NightRadio]

Hi! :)
Here is the new version:
http://warmplace.ru/soft/beta/sunvox_co ... r_test.zip

You are right, unlike other compressors the SunVox one has the Threshold that senses absolute amplitude levels. And here is the main problem :)
Current gain calculation expression is:

Code: Select all

if( Envelope > Threshold )
{
  Gain = Threshold / ( Threshold + ( Envelope - Threshold ) * Slope );
}
// where Envelope is the input sound envelope with attack and release applied

So you can see that if the Threshold is 0, then the Gain is 0 till the Envelope > 0.
But if the Release is not zero ==> Envelope has very long exponential tail ==> Envelope tends to zero, but it is not zero ==> ( Envelope > Threshold ) ==> Sound is muted (Gain=0) for very long period or infinitely (depends on the math precision).

I see two solutions:
1) Set Release to 0, when Threshold is 0
2) Don't allow to set Threshold to 0. Minimum - 0.5, for example.

In the previous test version i used the second solution. And this is why you heard your input signal even with zero Threshold.

[gilzad]

Aaah, that explains why the current version mutes anything at a threshold of 0, regardless of the Slope value. And 0/n=0 as long as input > 0.
If I understand correctly, you separated the time calculation from the gain calculation. Very smart to end up with one gain factor for evrything :)

While it's not very "natural" to the user in that special 0-case, it does well in all other cases. So I'd choose 2) and display "min" or "0.5" as you suggested for the lowest threshold level. That way the compressor works as expected at any value and won't cause confusion. If we really want to mute our sound, we can add the same compressor with a threshold of 1 to a parallel chain, invert its signal and add it to the output of the normal compressor. Then the main compressor will mute the output, if its threshold is set to 1, too. Like in this example.

Tested the multiband limiter with the first test version already - it's really a big and good change.

Thanks for all the attention and effort! Very excited about the next version.
edit: Of course I will still be open for further testings.

[NightRadio]

Hi Gilzad!

Seems that the previous test version was incorrect. Gain envelope was too long in some cases.
But i changed it again :) And here is the new version: http://warmplace.ru/soft/beta/sunvox_co ... r_test.zip
Please test it.
I think that now it is good enough for the final release.
And good news is, now you can set Threshold to 0 if you want to mute the sound :)

[gilzad]

Ah this one is perfect!

Edit: I was trying to suggest a way that would make the Slope work, even if the threshold = 0.

Code: Select all

//assuming that a Slope of 100% is 1.0 in the code
//...
Gain = Threshold / ( Threshold + ( Envelope - Threshold ) * Slope );//doing the gain calculation with its conditions first
//...
if( Threshold == 0 && Gain == 0 )//if threshold was 0 and the gain factor became 0...
{
  Gain = Gain + (1.0 - Slope);//..then restore the gain by the opposite amount of the slope, 0=1 .
  if(Gain < 0)
  {
   Gain = 0;//We can't reduce to less than 0 and we don't want to invert the signal, if the Slope was too high.
  }
}

...But it sucks. The output would become louder than a threshold of 1. This is less natural and my maths is too weak to get this conform with the existing gain calculation.

The compressor is great, you rock! :)

[NightRadio]

Hm... I don't think we can use the Slope parameter when Gain is zero.
But why do you want this?

[gilzad]

Hi,
because a normal user expects only 50% of the input to be muted, if he sets Slope=50% and Threshold=0.
But it's possible to set the Threshold higher and keep the Slope at 100% to get a similar result. So it's not a big issue. :)