reacomp precomp is confusing me!

Tom Drinkwater · 10-20-2012, 08:05 AM

I was having trouble getting the results I expected in reacomp so I did a test with some test tones and saw some very unexpected behavior.

osx, mountain lion, reaper 4.261

I might be mistaken here and there, but there is stuff that seems to be just wrong. I've been assuming it was me for ages, but just couldn't get expected results,which is why i checked.

here's some of the things that puzzled me:

* release times are actually a rate!! actual time varies with threshold or amount of compression or something - so why not state what the control actually is! ie 50ms per 6dB or whatever.

* attack envelopes are a log curve with a very fast start, (with the result that most of the gain reduction happens in the first 1/4 of the specified time) but release envelopes are linear. why? can we control attack and release shapes?

* when precomp is used the gain reduction starts early by the amount of the precomp and follows the attack time envelope, BUT when it gets to the actual start of the event that triggered the gain reduction it does it again, so the attack envelope is visible in the result twice, once before the event and once in the normal place. This seems to subvert the whole point of precomp which is to move the attack artifacts to the quieter/silent bit before the loud event.

* when precomp is used the gain starts to increase again at the precomp time before the end of the loud event, ie the release seems to be moved forward by the precomp amount too. why would anyone want that? BUT it is more complex than that because when the loud event finishes the release happens after it in the normal place AS WELL

* in short pre-comp doesn't just offset the attack by the precomp amount, as expected, it seems to apply a whole separate layer of compression, including release, shifted by the precomp amount, in addition to the normal unshifted behaviour. why?

is all this normal and intended? i find it very confusing, and not helpful for any use scenario I can think of.

Is there a reacomp manual that explains all this clearly? I've read what I can find and none of these issues are clear, or even mentioned.

Tom Drinkwater · 10-20-2012, 08:23 AM

here's my test-tone

and here it is with precomp as per the visible settings in reacomp.

Tom Drinkwater · 10-21-2012, 01:48 PM

wow, no replies at all, does everyone think this is correct behaviour for a lookahead compressor?

run, megalodon · 10-21-2012, 02:32 PM

Weird stuff, especially about the precomp.

dug dog · 10-22-2012, 04:18 AM

If it's behaving the way you describe then, yeah, it's very much a cause for concern.

Even though it's easy to see now, I had a bit of a tough time figuring out how the diagrams relate to what you were describing. It would be much easier to grasp quickly if you were to add a couple of arrows and descriptors on that second shot.

I've been playing a lot with compressors this past week in both Sonar (using their Sonitus comp) and in Reaper. I can't remember which one I was using at the time, but one of them was giving results that didn't make sense to me when I played with short attack times and, in Reacomp, the pre-comp feature. I can't say for certain, but it seems I may have seen similar behavior.

Unfortunately, I don't have time to muck with it further at the moment.

Tom Drinkwater · 10-22-2012, 04:39 AM

I'll do an annotated graphic when i get some more time for it.

to clarify, in the above screenshot, i would have expected the loud (above threshold) section to be dead flat because the attack should have finished before the loud bit starts (the attack time is less than the precomp time) and the release should not start until the loud section ends.

I can't see any musical merit in the precomp time applying to the release as well, as it seems to here, it surely should just apply to the attack.

Since the release time is actually a rate not a fixed time, it is not totally clear to me if the release is being triggered twice or just is very long... but it is clear that it is starting early by the precomp time, which has a certain logic, but no musical merit that I can imagine.

As to why the attack seems to happen again at the actual start of the above threshold section, that just seems like a mistake to me.

pipelineaudio · 10-22-2012, 02:31 PM

This is definitely a problem, it causes certain types of attack destroying effects not to happen at all. ReaComp was meant to be philisophically WYSIWYG and that is certainly not whats happening here

Tom Drinkwater · 10-22-2012, 04:08 PM

I've also just discovered that changing the attack time changes the amount of gain reduction applied to the loud section, even after the attack is totally over.

The shorter the attack time the more the gain is reduced.

WTF?

I'm comparing some other compressors with lookahead, but i don't have many. DMG compassion has the release shifted the same as the attack, but each happens only once, melda MDynamics is more similar to reacomp. so reacomp is not alone in behaving strangely. but none of them do what I would actually want and expect.

karbomusic · 10-22-2012, 04:15 PM

Quote:

Originally Posted by Tom Drinkwater

I've also just discovered that changing the attack time changes the amount of gain reduction applied to the loud section, even after the attack is totally over.

The shorter the attack time the more the gain is reduced.

WTF?

I'm comparing some other compressors with lookahead, but i don't have many. DMG compassion has the release shifted the same as the attack, but each happens only once, melda MDynamics is more similar to reacomp. so reacomp is not alone in behaving strangely. but none of them do what I would actually want and expect.

There is a long article on gearslutz or one of the other audio forums that goes in great depth by a few well known compressor makers and you'd be amazed at how they actually work vs expected. Sorry I don't know where that thread is but I can promise it will answer your questions (maybe).

karbomusic · 10-22-2012, 04:22 PM

I "think" this is that thread, well worth the read, pay particular attention to DRFrankencopter and UBK:

Quote:

Attack is not a one-shot affair where once you're over threshold the attack has happened and doesn't happen again until you dip below threshold and come back over it once again; attack is happening *any time* a signal is increasing in amplitude while over threshold. IOW, if the compressor has to push back against a signal, it is attacking it. The question is how fast is it pushing back (attack) and how hard (ratio).

REF: http://www.gearslutz.com/board/so-mu...mpression.html

run, megalodon · 10-22-2012, 04:26 PM

I did a test and I think it works as expected. You can see that the louder portion which triggered the compressor is flat.

Here are the settings I used:

Maybe the lack of flatness in your test is due to the fact that the attack has not kicked all the way in by the time that the louder portion hits, so the comp continues to compress, which creates the curve. Notice that the compressed portion in front of the burst in your test never really levels out, indicating the attack is still going. Here is a visual comparison:

The only problem here is that in your test, your precomp was longer than your attack, so you would expect the attack to be finished before the burst kicks in. But maybe the attack times are a rate, just like the release. In my test, my attack is set for 3ms, but looking at the waveform it seems it takes 9ms for it to fully kick in. For example, if your ~15ms attack really means 15ms per 6b, and the compresser compressed by around 24db, it would take 60ms for it to take full effect, about twice as long as your precomp, which is what your waveform seems to show.

Tom Drinkwater · 10-22-2012, 04:28 PM

In Compassion I can get what i would regard as normal lookahead behaviour by setting hold to the same as lookahead, that delays the release back to where I would expect.

every compressor should have a gain reduction by time graph over the waveform so you can see what it is really doing! otherwise I'm just wondering why it doesn't sound how I expect.

certainly release is waiting for the signal to drop below the threshold, it is how it affected by lookahead that is weird, and the fact that in reacomp both attack and release seem to happen twice, and the times are not what they say they are.

I can well believe that many (especially hardware) compressors don't do what you'd expect, but it would be nice if they were absolutely clear about what they do do, there seems to be no standard, and many of the controls are either misleading or a mistake. The thing I always liked so much about reacomp is the simple clear interface with specific values in dB and ms, but it seems it doesn't actually do what the interface is saying.

could we have a hold control in reacomp? I don't see that it should be difficult to add.

Tom Drinkwater · 10-22-2012, 04:31 PM

re above quote, that's why i used 2 static levels, so the attack is effectively only triggered once as the level only increases once, and instantaneously at that.

Tom Drinkwater · 10-22-2012, 04:41 PM

megalodon, I've been thinking along the same lines... it makes it very difficult to know what to set the precomp too, how much precomp is enough to ensure the loud bit is all fully compressed, even though the attack is slow.

what you describe with the attack not having finished definitely happens at some settings.

however, if you try setting the rms size to zero as in my example, you'll see that it is not that simple. with a zero rms size the attack definitely retriggers at the start of the loud bit.

with a 5ms rms size I can get something approaching expected behaviour except for the attack and release times being much longer than the settings.

karbomusic · 10-22-2012, 04:42 PM

Quote:

certainly release is waiting for the signal to drop below the threshold .... but it would be nice if they were absolutely clear about what they do do

I gave you a link.

Quote:

The issue is that both attack and release times have an affect on gain reduction while the level is above the threshold. Release is taking affect when the signal level is decreasing and attack is taking affect while the signal level is increasing. Release can continue to affect the output once the signal drops below threshold.

Many people incorrectly believe that release is related to the signal dropping below the threshold, but they are wrong.

run, megalodon · 10-22-2012, 04:47 PM

Quote:

Originally Posted by Tom Drinkwater

however, if you try setting the rms size to zero as in my example, you'll see that it is not that simple. with a zero rms size the attack definitely retriggers at the start of the loud bit.

with a 5ms rms size I can get something approaching expected behaviour except for the attack and release times being much longer than the settings.

Hmmm, why would you set the rms to zero? I'm not completely clear on the definition of rms, but wouldn't that basically be taking the average of no time period? Isn't that asking for weird behavior?

run, megalodon · 10-22-2012, 04:51 PM

Anyway, I have been able to replicate your example with rms set to 0.0; I get another attack at the beginning of the burst, and another release before the end of the burst.

karbomusic · 10-22-2012, 04:52 PM

Quote:

Originally Posted by run, megalodon

Hmmm, why would you set the rms to zero?

To disable it and limit.

Tom Drinkwater · 10-22-2012, 04:54 PM

because i want it compress based on *peak* values not average values. i then use a long enough attack and release time that it doesn't try to actually follow the signal.

run, megalodon · 10-22-2012, 04:55 PM

Quote:

Originally Posted by karbomusic

To disable it and limit.

Ah, Ok. Well maybe it is something in the RMS code when set to zero that causes erratic behavior related to quick level changes? I'll try to test this.

Tom Drinkwater · 10-22-2012, 05:01 PM

karbo, I do understand that attack and release are in effect any time the signal is changing, as long as it is above the threshold, or in the case of release as long as it has been above the threshold recently enough that the compressor is still releasing.

that is why I used a test tone where there is an instantaneous increase in level followed by an instantaneous decrease, this means we can see the attack and release as if they are one shot events, because in response to the totally unnatural signal i created, they become one shot events, the signal is at constant level at both high and low levels so the attack and release should only affect the sound in response to the points where it *changes*. Of course that's not anything like a real signal, but a real signal would not make any of this visible.

what i didn't understand, (amazingly!) is that both attack and release are a rate. In which case it would be nice to know what the rate is, and what shape curve it follows. (and be able to change it)

karbomusic · 10-22-2012, 05:01 PM

Quote:

Originally Posted by run, megalodon

Ah, Ok. Well maybe it is something in the RMS code when set to zero that causes erratic behavior related to quick level changes? I'll try to test this.

I'd check the article I posted. Very enlightening to these exact questions (i think, maybe possibly or not).

Tom Drinkwater · 10-22-2012, 05:03 PM

Quote:

Originally Posted by run, megalodon

Ah, Ok. Well maybe it is something in the RMS code when set to zero that causes erratic behavior related to quick level changes? I'll try to test this.

it does it with very short rms times as well, it is not some sort of divide by zero error....

Tom Drinkwater · 10-22-2012, 05:12 PM

DMG compassion does not do the double attack with rms time set to zero, or any other time unless the attack is longer than the precomp of course.

run, megalodon · 10-22-2012, 05:22 PM

I just did a test with a smooth 10ms linear ramp up to the burst instead of instantaneous, but I still got the artifacts. I'm stumped.

@karbo, I'll read that article, thanks.

I hope Justin chimes in and let's us know. I'm very curious now.

karbomusic · 10-22-2012, 05:30 PM

Stupid question... In one of Tom's screen shots ReaComp appears to be setup as limiter RMS:0, Ratio:inf, Knee:0 and so on... I noticed the limit output checkbox isn't checked. If those settings are actually creating a limiter, what is that checkbox for and what changes if you enable it? Hope you didn't say and I missed it.

Tom Drinkwater · 10-22-2012, 05:32 PM

according to that gearslutz thread the attack or release time should be the time it takes to adjust to 10dB of gain reduction.

with a setting of 14ms release time and approx 5dB of gain reduction I was seeing actual release times of around 25ms. EDIT attack times similar relationship to the amount of comp and the setting, but harder to see, because of the curved envelope.

i suspect reacomp is not calibrated to 10dB per multiple of the attack or release times.

Tom Drinkwater · 10-22-2012, 05:35 PM

Quote:

Originally Posted by karbomusic

Stupid question... In one of Tom's screen shots ReaComp appears to be setup as limiter RMS:0, Ratio:inf, Knee:0 and so on... I noticed the limit output checkbox isn't checked. If those settings are actually creating a limiter, what is that checkbox for and what changes if you enable it? Hope you didn't say and I missed it.

I set it as a limiter for simplicity. I have always presumed that the limit button limits to 0dB or close to it, so in that case it would do nothing since my threshold is -14dB.

EDIT: to clarify, i set ratio to inf to ensure that the compressor target level is the same as the threshold level for ease of measuring.

Tom Drinkwater · 10-22-2012, 05:59 PM

I have the beginning of a theory about the apparent double attack and release. I suspect it is because at short rms times the compressor tries to track the waveform, but does so slowly because of the long attack and release times, nevertheless the interaction of the attack time and the waveform tracking results in a equilibrium being reached only gradually, wheras with higher rms times the target gain reduction is more fixed and it just follows the attack curve to get there.

I'm not sure how this is interacting with the pre-comp. Also not sure why it doesn't happen in Compassion. It is only the beginning of a theory, I'll come back to it tomorrow.

dug dog · 10-24-2012, 04:57 PM

Two weeks ago, I thought I'd made a major break through in my understanding of compression.

Now, my head hurts!

Very interesting stuff, though.

Baer · 10-24-2012, 05:39 PM

The compressor actions are actually pretty straightforward. Don't overthink it. See this old 2008 thread and go to Posts 22 and 23 along with lots of other good info.

http://forum.cockos.com/showthread.php?t=21516

Release and attack times are indeed times, not rates. The rate of compression is determined by the attack time and how far the signal is above the threshold.

Non-zero RMS values simply slow or soften the compression because an average level rather than an instantaneous value is driving the compressor.

Pre-comp is simply a "negative delay" (an early start) and nothing more than that. It's purpose is to tame transients -- if that's not what you want to do, don't use it.

Running these types of tests on different compressors can show you how very much different their behaviors can be.

Tom Drinkwater · 10-25-2012, 07:31 AM

Can you explain why very short rms times result in a double attack when precomp is used?

what do you mean by "the rate of compression"

If attack and release are fixed times, why do their times vary with other settings? If I set the attack to 10ms, i won't get a consistent 10ms attack - it will depend on the other settings.

Tom Drinkwater · 10-25-2012, 08:44 AM

after a lot of thinking, my conclusion is: reacomp needs a hold function. I'll explain how i got there when I have more time.

I still can't adequately explain the double attacks with precomp and low rms values though.

Tom Drinkwater · 10-28-2012, 06:23 AM

I have worked out what it is doing and why, but it will take a long post, an essay even, to explain properly.

I'm working on that.

It is working "correctly" it is just that there are some undesirable and maybe unforeseen consequences when using precomp in combination with 0 rms size. in fact 0 rms size is a problem in general, it is NOT peak tracking, it is whole waveform tracking. I'll explain in detail when i've written my long post, i hope in the next few days.

dug dog · 10-28-2012, 07:33 AM

Your efforts are appreciated.

Reno.thestraws · 10-28-2012, 01:59 PM

Just lokk at this :

1)Original signal

2)FABFILTER PRO C VS REACOMP with same settings (time selectipon is 250msec)

3)Same as 2 but with classic attack enabled on reacomp

4)Same settings as 2 with zoom on release (time selection is 500ms)

5)Fast attack and release

6) Slow attack, slow release - time selection is 500 msec

Tom Drinkwater · 10-28-2012, 03:10 PM

so reacomp and proC have different attack and release envelope shapes. that doesn't especially surprise me. proC has a curved release more like an opto comp is supposed to have. I actually quite like proC - it is the only fabfilter plugin i really like actually.

it would be nice to have selectable shapes in reacomp, thats one of several improvements i will suggest when i get around to writing more.

proC also has a really nice graph showing gain reduction on the actual waveform in real time. no precomp though unfortunately.

is there something else about these I am missing?

Reno.thestraws · 10-28-2012, 03:18 PM

It's the attack time that disturb me

look at pics 2...

the attack time is 250msec on both compressor

The attack of a compressor is the time that take this comp to reach the "full" reduction (based on ratio)

I set the time selection to 250 msec and start it right at the "first sample reaching the treshold)

We clearly see that fabfilter take exactly 250msec to achieve full reduction... Reacomp is much longer...

250 msec must be 250 msec. no matter what the shape is...

Tom Drinkwater · 10-28-2012, 04:01 PM

I see what you mean, but from what I've read there is no agreement between different makers what the attack times should mean.

Reacomp will give a different attack time depending on other settings, even without changing the time setting. According to the gearslutz thread linked to earlier in this thread, attack and release times are usually rates, not absolute times.

Attack and release are NOT usually Xms from no compression to full compression, but Xms to achieve YdB of gain reduction, so the actual attack time will vary depending on how much compression is being applied, which varies with ratio, threshold and signal level, (not to mention signal envelope shape) even without changing the attack time.

I might reinstall ProC, if I can find a demo or something and include it in my own comparisons. It has been a while since I tried it.

Baer · 10-30-2012, 01:58 PM

Quote:

Originally Posted by Tom Drinkwater

... it is NOT peak tracking, it is whole waveform tracking.

This should be obvious -- the compressor is re-calculating the rate of compression at every sample (generally). If you want to easily confirm, use your step increase test with a 1 hz sine wave and ReaComp with a 10 ms attack, 10 ms release, and infinite ratio. You can see the compressor kick in and then out within each cycle of the sine wave.

Quote:

Originally Posted by Tom Drinkwater

... there is no agreement between different makers what the attack times should mean....

Bingo!

I think you are over-analyzing the compressor conept. Don't get too literal in trying to evaluate what's happening. There are different algorithms, different envelopes, different uses of the same parameters, etc. in different designs. Some aren't right while others are wrong -- they're just different designs.

If you really want to go off the deep end with your analysis, run these tests on something like Digital Fishbones' Blockfish.