reacomp precomp is confusing me!

[Tom Drinkwater]

Originally Posted by Baer

This should be obvious -- the compressor is re-calculating the rate of compression at every sample (generally).

yes it is obvious, however, people use 0 rms size to do peak based compression or limiting, when a slower envelope would be more appropriate.

0rms size and slow attack/release times for smoothing is not a substitute for an actual peak following envelope. A hold time parameter would go along way towards this, but en envelope that intelligently followed peaks without tracking the waveform would be even better, an i think there are ways to do it more subtle than just a simple time constant / frequency filter

0rms size, with very fast or 0 attack and release times and infinite threshold actually clips the wave to the threshold.

I'm having trouble confirming my explanation of why we see double attacks and release with precomp in reacomp - when i'm more sure i will post.

I don't think there is any such thing as too literal in what should be an entirely deterministic and predictable process.

since compressors are not consistent one to the next in how they work it is all the more important that their creators describe the controls accurately.

[karbomusic]

I look forward to the follow up but these waters will always be muddy and inconsistent IMHO because the moment it doesn't sound the way the settings look is the moment how it looks and the math becomes irrelevant. I know that it would be nice to expect ~n reduction based on ~n criteria but in this audio world, turning the knob until it sounds right always trumps the math.

[Banned]

But then there should not be any misleading information on the GUI. You can also simply put "fast" and "slow" on opposite sides of the scale if the numbers are meaningless. Some compressors don't even do that (e.g. 1176, 670). If a delay *says* it is at 10 ms I also expect it to be at exactly 10 ms. If it's a rate rather than absolute time, it should be mentioned as such (e.g. ms/10dB).

PS: music *is* maths. Watch Donald in Math Magic Land again if in doubt.

[karbomusic]

If it's a rate rather than absolute time, it should be mentioned as such (e.g. ms/10dB).

As far as I know it has always been a rate. Music being math is a construct of describing it to the left side of the brain; to the right side its completely meaningless. Anything can be reduced to math so its slightly moot. I agree on the delay time but I'm just saying that in the world of compressors you won't find much consistency when attempting to verify all the numbers for obvious reasons.

[Banned]

I understand that many work differently. My point is simply that effects should not put numbers on their knobs that suggest something else than what they actually do (so if ReaComp actually uses a rate, then it should rather show ms/10dB or similar as a unit, not ms). I don't mind inconsistency nearly as much as consistently misleading information.

[karbomusic]

Originally Posted by Banned

I understand that many work differently. My point is simply that effects should not put numbers on their knobs that suggest something else than what they actually do (so if ReaComp actually uses a rate, then it should rather show ms/10dB or similar as a unit, not ms). I don't mind inconsistency nearly as much as consistently misleading information.

Fair enough. Let me poke fun that ms might not be so incorrect if everyone knew the definition of attack. I think the fact that it is a rate is a given based on the definition but it is rarely explained in these terms; rather more in "how do I use this thang" terms:

Attack * Attack time refers to the time it takes the compressor to start compressing after threshold has been reached.

~MixOnline.Com

But if you look at the technical definition...

The length of each period is determined by the rate of change and the required change in gain. For more intuitive operation, a compressor's attack and release controls are labeled as a unit of time (often milliseconds). This is the amount of time it will take for the gain to change a set amount of dB, decided by the manufacturer, very often 10 dB.

Don't take me too seriously here, just splitting hairs for fun. I do agree that it should at least be in the manual if the spec is outside of the very often 10db.

[Tom Drinkwater]

Originally Posted by karbomusic

I look forward to the follow up but these waters will always be muddy and inconsistent IMHO because the moment it doesn't sound the way the settings look is the moment how it looks and the math becomes irrelevant. I know that it would be nice to expect ~n reduction based on ~n criteria but in this audio world, turning the knob until it sounds right always trumps the math.

this is fine if you are using compression as a creative effect, or to even out subjective levels, but if you are trying to achieve a specific technical outcome, like using the compressor for peak control with specific target output levels, it is just frustrating.

It is especially important that controls are explained and labeled correctly because otherwise you might spend hours trying to get the tool to do something it just can't do. I always assume it is me at fault at first, but very often I eventually find i want something the tool can't do.

I like confirmation at every stage between what I hear and what the controls and meters say (i don't trust software to not be buggy, and I don't trust my ears and brain to hear everything first time..) - I can't get that feedback and correlation if I don't understand how to interpret the meters and controls, they become almost useless, they might as well be labeled "more parrots" and "alcohol content" - sure it forces experimentation and listening, but it's a time waster if you have a specific goal.

for example, there is simply no way to make reacomp respond to peak levels rather than RMS, but not track the waveform. It is just not the right tool for that job, though with some minor changes it could be. But this is not apparent to the casual user, you have to have gone through the learning process i have spent the last few days on before being able to know this. If more accurate and complete information was available on how it works this would be much quicker. I can't even find a manual for reacomp, the little bit in the reaper manual is totally inadequate.

Incidentally the input meter needs to make it clear whether it is showing peak levels, or the rms level that the compressor is actually responding to. Ideally it would show both. Likewise the threshold level is presumably RMS? so short peaks above threshold will not be compressed?

[Tom Drinkwater]

that mixonline quote is just plain wrong! the compressor STARTS compressing right away. (unless the there is an attack hold function). The attack time is how fast it applies the compression, not how long before it applies it. It is like runners in a race, they all start when the starting gun goes, but their accelerations differ.

It is this sort of misinformation that makes it all the more important that the creators actually explain what is really happening.

[karbomusic]

that mixonline quote is just plain wrong! the compressor STARTS compressing right away.

I know! Crazy isn't it? I just used that as an example to show why there is likely soooo much misunderstanding on compressors and how they work. Fascinating if you think about it.

[Tom Drinkwater]

Ok, in the interests of getting this out there while people are still interested, here is what I have written... it is in 2 parts - 1. background and 2. explanation of weird precomp behaviour.

It may be wrong in detail or in concept, but no-one else has even tried to explain why this happens so here goes:

Part 1, Background.

A compressor reacts to and modifies the level of a signal. But what actually is the level of a signal? it can mean different things, depending on how it is measured.

A compressor, before it even begins to do anything, must create a model of the how the level of the waveform changes over time. This is the all-important detector circuit in analogue compressors, but in digital, it could be any algorithm we can think of.

At an instantaneous random moment in time, the level of the signal could be anything, you could measure one sample and it could happen to be zero because the waveform is at a zero crossing at that moment, but the peaks could be at full scale. So level is only meaningful in the normal sense if we specify something about time as well as the value of the sample we are measuring.

Rms values are one way of doing this. The rms level is the average power level of the waveform over a specified period of time. For a static sine wave that is 71% of the peak level, but for other waves the relationship can vary a lot, for a square wave the rms and peak level are the same, but for a narrow pulse the rms level is much lower than the peak. Rms level can be usefully thought off as equivalent to the area under the waveform. (or more correctly the area under the rectified waveform, or the area created between the waveform and the 0 line)

Rms level is useful because it approximately corresponds to power and therefore to perceived loudness.

BUT rms level is not the whole story. A mostly quiet signal with a brief loud peak that only takes up a tiny fraction of the rms time will not register much rms level, so rms level is not very useful for controlling peaks or preventing clipping.

For that we have to measure peak level. But how do we do that? As in the initial example, if we take one random sample it is unlikely to be a peak. So again we have to set a window of time, and look for the loudest sample in that window. This can be deceived if the window is too short since it might fall between the peaks we wish to capture, but if it is too long it will capture multiple peaks, and model the level as the highest of them, ignoring the others and over simplifying the model of the level changes.

There are 2 ways we might go about measuring peak level, one is to set a window of time like we do for rms levels and take the highest peak as the peak level for that window. This is problematic because if it is set too short it will just track the waveform, how short is too short depends on frequency; it may be impossible to avoid tracking the wave of a bass note, and also model a short transient with the same settings. So - the other way is to set a bunch of criteria for what constitutes a peak, for example off the top of my head some possible criteria to think about - a sample could be a peak if:

* the level has been rising before it and is dropping after it.

* and the rise and fall are more than just a tiny wobble on the waveform (a time constant might creep in again here, but it could be much shorter in combination with the other criteria)

* another peak cannot be said to occur unless the waveform has crossed zero since the last peak, OR the new peak is higher than the last peak.

these criteria are tricky, but it should be possible to do peak modelling that can both avoid tracking bass waves and model sharp transients responsively.

Reacomp does not do either (or any) sort of peak modelling, it only works on an rms paradigm. If you want to detect peak levels at all you have to set it to 0 rms time, and then the model of the level of the waveform IS the waveform. The problem with that is that it is a rapidly moving target and the attack and release times are actively seeking new steady states at every sample along the waveform, oscillating at audio frequencies.

This means that the steady state that the compressor will end up at is a function of the shape of the wave, the length and shape of both the attack and the release times , as well as the parameters that you actually want to control the steady state level, which are the threshold and ratio. In other words the compressor will try to compress every peak more than every low level point in the wave, even in a static wave, rather than model the wave as a level and compress it all evenly. How effectively it tracks the wave depends on the length and shape of the attack and release envelopes, if they are very long the effect will be less noticeable, but it will still happen. This leads to distortion of the shape of the wave as the compressor works harder on the wave the further from 0 it gets. The compressor becomes a waveshaper - Effectively a new waveform is superimposed on the wave consisting of the beginning of the attack and release envelopes.

So even with rms at 0 you don’t have clear and transparent control of peaks.

There are 2 ways this could be solved - 1. introduce a hold function, which delays the release by one cycle of the waveform or more so that it doesn’t begin to release on every cycle, distorting the wave with it’s own envelope shape, or 2. model peaks in the detector circuit/algorithm in some way as described earlier, so that the compressor follows the model of the wave rather than the actual wave. Of course rms detection also achieves a smooth level model, but at the expense of not tracking peaks at all.

As mentioned in my earlier post input metering needs to show peak, plus model/rms meter

[Tom Drinkwater]

Section 2

Why does reacomp show apparent double attack and release curves with pre comp turned on and rms=0?

When rms is greater than the period of the waveform we see the behaviour I would expect. There are no apparent double attacks or releases, and compression is applied early by exactly the pre comp amount, but the release is NOT early, it happens in the normal place. The attack is moved earlier in time, but the release is not. This may be a simplistic analysis, we’ll see. Attack and release interact, they are not separate triggered events as we might think from this sort of simplified example, but rather they are the rates of response of the compressor, in fact the amount of gain reduction is constantly updating taking both attack and release into account.

So we know reacomp is applying a sensible rule to pre comp. the compression is applied early, but it is not released early as that would result in the end of a static note becoming louder at the pre comp time before the end. We do not see this with rms values of one cycle or more.

When rms is 0 the detector will be following the waveform exactly and distorting it according to the attack and release times and shapes. With rms=0 the amount of peak compression visible is actually created not only by the ratio and threshold, but by the interaction of the attack and release times and shapes with the shape of the input waveform which they are trying to track exactly. Sure enough experimenting with the attack and release times shows that the amount of compression applied even in the middle of a static section varies according to attack and release when RMS=0.

We know that the attack time is calculated based on tracking the wave, not at the point where it is actually applied, but earlier by the precomp time. However I suspect that the release time is calculated by tracking the wave at the normal time. So the attack and release times are tracking the wave at different times from each other, before being combined with ratio and threshold to determine the total gain change. So we can expect to see a change in the amount of peak compression visible not only at the precomp time before an input change, but also at the input change itself. Needless to say this subverts the intention of precomp.

So at the precomp time before the level increase the compressor senses the level increase and calculates the gain change to apply based on the louder wave for the purposes of attack time, and threshold, but calculates the release time based on the current quieter position. At the actual level change it is still tracking the higher level wave for the purposes of the attack time, but now the release time is also tracking an (earlier) part of the higher level wave. The result is a convergence on a new peak level based on both attack and release tracking the higher level wave.

There should also be an interaction between the frequency of the wave and the precomp time separating the attack and release tracking affecting the phase relationship of the parts of the wave tracked by attack and release. Indeed if you change just the precomp time and nothing else you see changes in the overall amount of compression applied, presumably because of this effect.

At the precomp time before the level decrease the attack time begins tracking the lower level wave, resulting in a new equilibrium gradually being found, then at the actual level decrease point the release time also begins tracking the lower level wave, resulting in a fairly conventional release shape. (since the attack time is still tracking the same static wave but further along.)

The solution could be some sort of hold function. DMG Compassion, when precomp is turned on, pre-releases as well as preattacks, creating louder ends of notes as described above that we wouldn’t want. However it also has a hold function, and when this is set to the same as the precomp time, the attack and release behave sensibly without the artefacts that look like double attack and release as described here. Perhaps this could be a solution for reacomp. I haven’t tested Compassion for whether the hold function overcomes the other problems with rms=0 detection.

[Baer]

Originally Posted by Tom Drinkwater

this is fine if you are using compression as a creative effect, or to even out subjective levels, but if you are trying to achieve a specific technical outcome, like using the compressor for peak control with specific target output levels, it is just frustrating.

... but very often I eventually find i want something the tool can't do.

... for example, there is simply no way to make reacomp respond to peak levels rather than RMS, but not track the waveform. It is just not the right tool for that job, ...

This is correct. You are expecting a compressor to do something compressors don't do. When my wrench doesn't cut wood, I don't keep arguing about how faulty it is.

Originally Posted by Tom Drinkwater

Incidentally the input meter needs to make it clear whether it is showing peak levels, or the rms level that the compressor is actually responding to. Ideally it would show both. Likewise the threshold level is presumably RMS? so short peaks above threshold will not be compressed?

The input meter shows whatever signal you are telling the compressor to use to determine the compression level. If RMS=0, it's the incoming signal. If RMS>0, it shows the current averaged incoming signal.

The threshold level is a constant (or envelop based if you've assigned it as such) -- RMS doesn't affect it.

[Tom Drinkwater]

Originally Posted by Baer

This is correct. You are expecting a compressor to do something compressors don't do. When my wrench doesn't cut wood, I don't keep arguing about how faulty it is.

There is no other tool provided with reaper that does either. There is no reapeak plugin. Controlling dynamics based on peak rather than rms levels is not an unreasonable thing to want to do.

[Tom Drinkwater]

Originally Posted by Baer

The input meter shows whatever signal you are telling the compressor to use to determine the compression level. If RMS=0, it's the incoming signal. If RMS>0, it shows the current averaged incoming signal.

yes it's very sensible, but nowhere does it say that that is what it is doing, so you'll see a different level on that meter than you will on the track with FX bypassed, which is confusing unless you know what is going on.

[Baer]

Originally Posted by Tom Drinkwater

There is no other tool provided with reaper that does either. There is no reapeak plugin. Controlling dynamics based on peak rather than rms levels is not an unreasonable thing to want to do.

That is a feature request, not a bug report.

[Baer]

Originally Posted by Tom Drinkwater

yes it's very sensible, but nowhere does it say that that is what it is doing, so you'll see a different level on that meter than you will on the track with FX bypassed, which is confusing unless you know what is going on.

There is only one signal controlling the compression. That is the input signal which is shown. It could be affected by a hundred different things such as side-chaining, compressor RMS settings, effects application. etc, so it would be silly to label it as anything other than simply the input signal.

Also not worthy of the term "bug report".

[Tom Drinkwater]

Originally Posted by Baer

There is only one signal controlling the compression. That is the input signal which is shown. It could be affected by a hundred different things such as side-chaining, compressor RMS settings, effects application. etc, so it would be silly to label it as anything other than simply the input signal.

Also not worthy of the term "bug report".

The signal controlling the compression is NOT the input signal. It is a control signal. It is the compressors model of the input signal, in this case arrived at through rms averaging, though it might be arrived at in other ways. A perfectly sensible thing to meter, but not the same as the input signal.

I think it was quite clear from my original post that I could not tell if there was a bug or not. No-one except myself has attempted to explain why the behaviour observed is not a bug.

None of the issues you mention are the actual main topic of this thread that needs explanation. The topic is the counter intuitive behaviour with apparent double attack and release when using 0rms and precomp.

I think I have maybe explained why it is not a bug, but rather an unexpected but logical consequence of those settings. However I am not 100% sure that my explanation is correct.

So yes, maybe this shouldn't be in this section, if a moderator wants to move it that's fine.

Regardless of whether there is a bug or not, I do think that this is a valid and useful discussion. It has exposed a lot of misinformation and misunderstanding both mine and others. The fact that no-one leaped in and explained that the observed behaviour is not a bug and why, in itself makes it relevant to a discussion of bugs.

The fact that attack and release are rates not fixed times was made clear by others early in the thread, but no-one has done the same for the precomp and 0rms.

I'd like to make it clear that I have few preconceptions about what a compressor does - I'm not that interested in modeling analog technology, or limiting a plugin to historical precedents. In fact other compressors do things that reacomp can't, and there is no god-given list of things that compressors inherently do or don't do. For a plugin based on first principles such as reacomp, there is no reason for it to do or not do any specific thing, as long as it relates to dynamics processing.

There are certainly several feature requests I would like to make for reacomp now that I understand it better, but that is not the purpose of this thread, except in passing.

If everyone agrees with my explanation of why reacomp behaves as it does then we are finished with the original topic, apparent bug is explained and turned out to not be a bug, just a limitation and a counterintuitive effect. In that case I might start another thread for discussion of what I'd like to see in a dynamics processor.

But if anyone has anything to add about the specific behaviour observed or my attempt to explain it I'd like to hear it!

[karbomusic]

Regardless of whether there is a bug or not, I do think that this is a valid and useful discussion.

I agree, its a thread chocked full of great information about compression and how it works. We have already proven the general knowledge of compression is severely, severely lacking (almost embarrassingly). I'm all about "if it sounds good it is good" but it is also a good thing to occasionally educate one's self about how things actually work, especially if they are the tools you use for your craft (duh). When its time to just make music and use my ears that's what I do, other times I like to learn things about how the world around me works.

Thanks for the hard work btw. Much appreciated.

[Baer]

Tom, you’re right that I should have used the term “controlling signal” rather than "input signal" in my earlier post.

You arrived at a lot of correct statements despite starting this thread with some incorrect assertions. But you’ve made this simple concept sound so complicated. Let me make a couple statements which may be restating some of your conclusions.

First, the RMS parameter is completely independent of the Attack, Release, and Precomp parameters. It forces the compressor to use an average value of the controlling signal over the past x ms rather than using the instantaneous value in determining its compression or de-compression values. Its behavior is not affected by PreComp settings.

PreComp simply starts compression early. That’s all it does. It only affects the timing of Attack, it does not affect the timing of Release, although its use may cause an early Attack which may preempt a Release – see the next point.

ReaComp does not Attack and Release concurrently. It’s either compressing, releasing, or doing nothing. Compression takes precedence over releasing. If a Release is in process when the controlling signal reaches a state where Attack should start, Release stops and Attack starts. This applies regardless of the use or non-use of PreComp. This is a point which I believe differs from your conclusions. Attack and Release may be constantly switching on and off, but at any instant, only one of them is in play.

[Tom Drinkwater]

Originally Posted by Baer

Tom, you’re right that I should have used the term “controlling signal” rather than "input signal" in my earlier post.

You arrived at a lot of correct statements despite starting this thread with some incorrect assertions. But you’ve made this simple concept sound so complicated. Let me make a couple statements which may be restating some of your conclusions.

the concept is simple enough, but I (and most others) managed to misunderstand it for years, partly due to the many incorrect "explanations" that float around out there, and in this specific case the lack of a manual for reacomp. Additionally there are consequences of some settings that are not simple at all, and I'm still struggling to visualise and understand.

There are certainly things I didn't understand when I started the thread, but I don't know where you think I made incorrect assertions.

Originally Posted by Baer

First, the RMS parameter is completely independent of the Attack, Release, and Precomp parameters. It forces the compressor to use an average value of the controlling signal over the past x ms rather than using the instantaneous value in determining its compression or de-compression values. Its behavior is not affected by PreComp settings.

I agree with all that and I don't think I've suggested otherwise. However turning rms off does cause interaction between the precomp settings and the waveform itself.

Originally Posted by Baer

PreComp simply starts compression early. That’s all it does. It only affects the timing of Attack, it does not affect the timing of Release, although its use may cause an early Attack which may preempt a Release – see the next point.


ReaComp does not Attack and Release concurrently. It’s either compressing, releasing, or doing nothing. Compression takes precedence over releasing. If a Release is in process when the controlling signal reaches a state where Attack should start, Release stops and Attack starts. This applies regardless of the use or non-use of PreComp. This is a point which I believe differs from your conclusions. Attack and Release may be constantly switching on and off, but at any instant, only one of them is in play.

Yes this is true, and I didn't explain that a compressor cannot be attacking and releasing at the same time. I certainly never meant to suggest otherwise. It can however switch very quickly between attacking and releasing, and with rms=0 will do this on every cycle. Fast switching between 2 different things can be quite a lot like them both happening at once.

Even with my long explanation it is still not 100% clear what happens with precomp turned on and rms turned off. The compressor is monitoring the signal at 2 different places at once, at the current time and at the precomp time.

It is improbable that the waveform will be in phase with itself over such a delay, even if it is artificially static such as a test tone.

Since the attack is driven by the detector monitoring the future signal, and the release is driven by the current signal, and the signal will cross the threshold in either direction at unrelated times to each other, then with precomp turned on there will inevitably arise a situation where the attack thinks it should be attacking and the release thinks it should be releasing at the same time. Presumably in that case the attack behaviour takes precedence.

However since the wave is crossing the threshold every cycle, the attack and release are pumping on every cycle, but they are not pumping in the pattern you would expect if there was no precomp, but in a complex interaction with the 2 different signals separated by the precomp time. It is very difficult to visualise. I think that this complexity is what gives rise to the apparent double attacks and release, but I cannot say predict the shape that they will take. As I mentioned in my long explanation, the amount of peak compression visible in this exceptional circumstance is dependent on the relative phase of the current and lookahead signal, which of course depends on the length of the precomp, as well as changes in the wave itself. Changing the precomp thus has the rather surprising effect of seeming to change the amount of compression applied even to a signal with no level changes, since it changes the point at which the attack and release switch over.

This all arises from simple rules of how a compressor works, but I hope no-one is saying that the behaviour is itself simple to understand! I'm still not sure that I know exactly what rules are being applied when precomp is active. It seems like there must be 2 independent detector circuits at work.

[Baer]

Tom, instead of relying on my memory of compressor testing I did years ago, I ran some tests to put an end to the questions of how PreComp affects the compressor results. And we (you and I) were wrong about one issue. Before getting to that, let me reiterate that the Pre-Comp and RMS parameters are unrelated. RMS affects the controlling signal. Pre-Comp affects the timing of the application of the gain reduction. Any correct conclusions about how Pre-Comp works are valid whether RMS=0 or RMS=500. Any changes in compression seen by changing an RMS value are due to the controlling signal changing, not because Pre-Comp acts differently when RMS=0.

Next …

Originally Posted by Tom Drinkwater

... Even with my long explanation it is still not 100% clear what happens with precomp turned on and rms turned off. The compressor is monitoring the signal at 2 different places at once, at the current time and at the precomp time.

... there will inevitably arise a situation where the attack thinks it should be attacking and the release thinks it should be releasing at the same time. Presumably in that case the attack behaviour takes precedence.

... It seems like there must be 2 independent detector circuits at work.

Attack does take precedence, and there is only one detector running. Here’s my take on basically what’s happening. At any instant it’s asking “Should I be compressing the signal?” It takes the relevant info (Pre-Comp if non-zero, current signal level, threshold value, “has compression already started and should it continue?”, etc.) to answer “Yes” or “No”. If the answer is yes, it starts or continues compression. If the answer is no and it was compressing the previous sample, it starts releasing. If the answer is no and the last release is complete, it does nothing. And if during a release or period of no action, the answer changes to yes, it starts another attack.

Now re-read that last paragraph, carefully this time. It's important to what's coming up next.

Now to the error in our thinking.

Pre-Comp simply starts compression early. No exceptions. We were wrong in thinking Pre-Comp doesn’t start release early. It may or may not depending on various things. See the following graphics showing an input signal with two step increases and then various compression results to that input signal. Ignore the second step increase; focus on the first.

https://stash.reaper.fm/14480/PreComp...%20Summary.pdf

Cases 1 and 2 show the input signal and the results after compression with Pre-Comp=0 and the Attack set to the width of the first step increase. Note the compression is not complete after 250 ms when the step ends and the Release kicks in.

In Case 3, Pre-Comp was set to the width of the first step increase, so 250 ms before the step increase, the compression starts. After another 250 ms, the step increase occurs but the compression is still not complete (see Case 2). At that instant the signal level is ABOVE the threshold, and the compression attack has been on-going but has not completed. So when the ReaComp asks “Should I be compressing the signal?”, the answer is yes, so it CONTINUES the existing attack through another 250 ms. Note the lower, already compressed start of the step.

Cases 4 and 5 are the interesting ones. In Case 4 Pre-Comp is still 250 ms but the width of the step increase has been shortened to 200 ms. Compression starts 250 ms before the step increase, but after 200 ms (the width of the step) the signal level is BELOW the threshold, and the compression attack has been on-going for a time interval equivalent to the width of the step ending the compression attack due to the step. So when the ReaComp asks “Should I be compressing the signal?”, the answer is no, and the Release starts. The release ends just as the real step increase starts, so ReaComp sees this instant as “I wasn’t compressing just prior to this and the signal just passed through the threshold, so I need to start a new compression Attack.”

Case 5 makes the result a little clearer. It is the same as Case 4 except the width of the first step increase has been further shortened to 150 ms. Pre-Comp start the compression 250 ms before the step, compression continues for 150 ms followed by Release for another 50 ms leaving 50 ms of original signal right before the real step increase. Again, ReaComp sees this real step increase as the condition to start a new Attack.

So this shows a situation in which the use of Pre-Comp has moved not just the Attack but also the Release. It also confirms the original post comment about two attacks and two releases from the same ReaComp trigger. (And I’ll be the first to admit I thought that was bull$#!^ when I first read it.)

But to close, please let me request that everyone stop saying that the Attack parameter in ReaComp is a rate, not a time. It is a time. It is not the time over which the compression attack completes, but it is a time in milliseconds which is used to calculate the compression rate.

[Tom Drinkwater]

this is a very interesting test.

it has a number of useful features.

by using steps rather than a wave you completely avoid the complex behaviour caused by attack and release pumping on a wave and the interaction of the precomp time with the wave period.

It seems to indicate to me that there are 2 compressors at work with precomp on, one using lookahead and one not, which was my initial impression, but that seemed to be contradicted by the results with rms times of 5ms and up. I think the test would show more clearly if the attack times were shorter relative to the step times. I don't have reliable internet for a few days, but i'll do some thinking about what this means.

re whether the attack is a time or a rate thing, attack time is the time taken for the compressor to apply X dB of compression, so in that sense it is a time, just as speed is defined by the time it takes to travel a certain distance. But to describe attack as only a time is like saying I'm traveling at one minute, but not specifying the distance covered, when you mean you are taking one minute to travel one mile, thus traveling at 60mph. So to be meaningful attack speed should be specified in some sort of term that combines ms and dB.

could you post your session and test signal?

[Baer]

Originally Posted by Tom Drinkwater

It seems to indicate to me that there are 2 compressors at work with precomp on, one using lookahead and one not, which was my initial impression, but that seemed to be contradicted by the results with rms times of 5ms and up.

There is only one compressor at work, and it is operating on the current sample. But when it decides what, if anything, to do to the current sample, it takes into account the Pre-Comp parameter setting and, if applicable, data from future samples.

Originally Posted by Tom Drinkwater

re whether the attack is a time or a rate thing, attack time is the time taken for the compressor to apply X dB of compression, so in that sense it is a time, ....

I can agree that “attack” (the general compression process) could be discussed as a rate, but “Attack” (the specific parameter in ReaComp) is a time. It’s even labeled “ms” for milliseconds. I fully understand your point, but the whole reason I started participating in this thread was to further the correct understanding of ReaComp. And I am (unfortunately) a stickler for details sometimes.

I’ve posted the project and the rendered files used for the screenshots in the following zip file.


https://stash.reaper.fm/14492/ReaComp...omp%20Test.zip


I didn’t actually use a test signal from a .wav file. Track 1 of the Project includes a tone generator which creates a very long wavelength signal (0.0001 hz) which is essentially a DC signal. This goes through a volume envelope in Track 2 which creates the step increases. This then goes to both Tracks 3 and 4. Track 3 does nothing other than give me a label for a rendering a file of the “input signal” which became Track 5 for the purpose of the screen shot. Track 4 is has the compressor and is used to render the compressed signal files which became Tracks 6 through 9 for the other screenshots. Could have been done more efficiently, but I was after quick results.

[Tom Drinkwater]

i've done some tests of my own, and I'm stumped.

they correspond to the tests you just did but with a wave.

the results are essentially the same.

when I say there are 2 compressors, maybe it would be better to say the compressor is responding twice to the same stimulus.

when the precomp time is longer than the pulse, the whole compression process is applied to the signal twice. you see an attack and release occur before the pulse, but triggered by the pulse, then again to the actual pulse as if there was no precomp. I have a hard time regarding that as correct. this happens regardless of rms settings.

when the precomp time is shorter than the pulse, then it also applies the compression twice, but this time you see 2 attacks and then 2 releases. This is consistent with the previous result, although still , to my mind, wrong.

BUT here's the weird bit, the last example above is only true with rms=0. When the precomp is shorter than the pulse, as in the last example, but the rms setting is 5ms or similar (more than one cycle) then the attack and release only happen once, the attack at the precomp time and the release at the normal time.

EDIT, this last effect can only be seen with a wave signal, with DC signals it does a single attack and release regardless of the rms setting.

[Tom Drinkwater]

Originally Posted by Baer

I can agree that “attack” (the general compression process) could be discussed as a rate, but “Attack” (the specific parameter in ReaComp) is a time. It’s even labeled “ms” for milliseconds. I fully understand your point, but the whole reason I started participating in this thread was to further the correct understanding of ReaComp. And I am (unfortunately) a stickler for details sometimes.

I don't understand what you are saying here. What events mark the beginning and end of the specified time?

I wrote some more but I have deleted as I suspect it is wrong , at least as regards reacomp. I will test reacomp for attack and decay times and report. So far reacomp does NOT behave the way the gearslutz thread people asserted.

[Tom Drinkwater]

I have tested and actual attack and release time vary with threshold, but NOT with ratio/amount of gain reduction applied.

high ratio high threshold resulting in 6dB of gain reduction gives a totally different (shorter) attack and release time from low ratio low threshold also resulting in 6dB gain reduction.

however 6dB gain reduction and 10dB gain reduction can have the same attack times if they have the same threshold and only the ratio is changed. This is NOT what i understood from the gearslutz thread. Did i misunderstand or does reaper work differently from "standard"? (or are the gearslutz folks wrong)

is the attack/release time missing/unspecified factor actually the amount of signal over threshold?

[Tom Drinkwater]

not only are the attack and release envelopes different shapes, they are different lengths, even when set to the same length.

presumably the unknown factor that changes the length affects attack and release differently?

[Tom Drinkwater]

theres something wrong/strange with the meter and threshold labeling.

with a sine wave input, the meter reads a lower level with rms than with 0rms , as you would expect. However if you line up the slider with the meter level, the slider will display the peak level in dB in numbers (same as the channel meter shows) even though it is lined up with a meter showing the lower rms level.

the threshold seems to be working on the rms level and the meter seems to be showing the rms level so the slider tag should also be in rms level.

[Tom Drinkwater]

Originally Posted by Baer

Cases 4 and 5 are the interesting ones. In Case 4 Pre-Comp is still 250 ms but the width of the step increase has been shortened to 200 ms. Compression starts 250 ms before the step increase, but after 200 ms (the width of the step) the signal level is BELOW the threshold, and the compression attack has been on-going for a time interval equivalent to the width of the step ending the compression attack due to the step. So when the ReaComp asks “Should I be compressing the signal?”, the answer is no, and the Release starts. The release ends just as the real step increase starts, so ReaComp sees this instant as “I wasn’t compressing just prior to this and the signal just passed through the threshold, so I need to start a new compression Attack.”

Case 5 makes the result a little clearer. It is the same as Case 4 except the width of the first step increase has been further shortened to 150 ms. Pre-Comp start the compression 250 ms before the step, compression continues for 150 ms followed by Release for another 50 ms leaving 50 ms of original signal right before the real step increase. Again, ReaComp sees this real step increase as the condition to start a new Attack.

Why is reacomp even looking at the current position? it is set to lookahead, it should only be looking at the future position. This is what i mean by 2 detector circuits, it is looking at both the future and current positions and making decisions about which to use based on criteria that are still obscure (to me at least)

[Baer]

Tom, did you say “Why?’ to your Mother all the time when you were a kid?

I’m just kidding – I know you’re just trying to understand how it works. But be careful about getting to literal about this stuff. It’s just a bunch of parameters that get used to make gain reduction happen. Pretend you’re using a hardware compressor where the numbers on the knobs are approximations of things. Not enough of something? Turn it up. Too much? Turn it down.

ReaComp itself actually is two very different compressors. There is a flag in the middle of the ReaComp screen called “Classic Attack”. Turn that on and run some of these tests. The results will be different and you will be more confused than you were two days ago. But it’s not wrong, it’s just a different approach. When ReaComp was first written, it had a more complicated approach to determining the gain reduction envelope which apparently used the shape of the signal prior to passing through the threshold along with all the other parameters to determine the attack approach. Using tests like we’re running here, we were questioning the apparent delay in the onset of the attack. It wasn’t wrong, just abnormal. So it was labeled the “Classic Attack” and a more “normal” approach became the standard for ReaComp.

I will try to answer some of your questions in upcoming posts.

[Baer]

Originally Posted by Tom Drinkwater

when I say there are 2 compressors, maybe it would be better to say the compressor is responding twice to the same stimulus.

That is a correct interpretation of something that occurs under some test conditions but would hardly ever occur in real use.

Originally Posted by Tom Drinkwater

when the precomp time is longer than the pulse, the whole compression process is applied to the signal twice. you see an attack and release occur before the pulse, but triggered by the pulse, then again to the actual pulse as if there was no precomp. I have a hard time regarding that as correct. this happens regardless of rms settings.

Think about it in simple terms. The compressor’s job is to reduce gain if certain conditions are met. The primary condition is the signal level is over the threshold. ReaComp has a bunch of parameters/tools to determine when and how to apply the compression. The design may also include some rules. Pre-Comp is one of the tools. And it appears the ruleset includes the following hierarchy of rules applied in this order.

1. At the current instant, am I in the middle of a compression cycle previously triggered (via Pre-Comp or normal conditions)--? If yes, have I reached a release condition FOR THAT CYCLE? If yes there is a release condition, start releasing. If no there is no release condition, CONTINUE the attack already in process.

2. If not in the middle of applying compression previously triggered, should I apply compression at this point because a Pre-Comp condition is met? If yes, INITIATE a compression attack.

3. If there is no Pre-Comp condition, should I apply compression because the signal is over the threshold? If yes, INITIATE a compression attack.

4. If not, am I in a Release cycle? If yes, continue the Release.

5. If not, do nothing.

This may not be exactly correct, but it is close.

Originally Posted by Tom Drinkwater

when the precomp time is shorter than the pulse, then it also applies the compression twice, but this time you see 2 attacks and then 2 releases.

I disagree. In this case, like in Case 3 of yesterday’s post, there is one compression cycle which starts at the Pre-Comp initiation point and continues through the step increase. There is one release cycle at the end of the pulse.

Originally Posted by Tom Drinkwater

BUT here's the weird bit, the last example above is only true with rms=0. When the precomp is shorter than the pulse, as in the last example, but the rms setting is 5ms or similar (more than one cycle) then the attack and release only happen once, the attack at the precomp time and the release at the normal time.

EDIT, this last effect can only be seen with a wave signal, with DC signals it does a single attack and release regardless of the rms setting.

Without seeing your specific example, I can’t offer a specific explanation. But I will suggest that the difference is entirely due to the controlling signal being altered by the RMS setting and is not due to RMS=0 affecting the way the Pre-Comp parameter is applied.

Recognize that when using RMS values, you are in effect slowing down the dynamics of the controlling signal. If you zoom in on the timeline and compare equivalent tests where one case uses RMS=0 and another uses RMS=5, I would expect compression to start slightly later than in the non-zero case. Why? With RMS=0, when the increasing signal reaches the threshold, compression starts. With RMS=5, when the increasing signal reaches the threshold, the value of the signal averaged over the last 5 ms will be less than threshold for another 2 to 3 ms depending on the slope changes if the curve.

[Baer]

Originally Posted by Tom Drinkwater

I don't understand what you are saying here. What events mark the beginning and end of the specified time?

Don't think of it as being mapped to events. Think of it as a parameter that gets used in some equation to determine how steep the compression rate will be. And it's defined such that after that increment of time, the compression will be close to reaching it gain reduction goal. How close? Depends on all the other factors and parameters going into the equation.

[Baer]

Originally Posted by Tom Drinkwater

however 6dB gain reduction and 10dB gain reduction can have the same attack times if they have the same threshold and only the ratio is changed. This is NOT what i understood from the gearslutz thread. Did i misunderstand or does reaper work differently from "standard"? (or are the gearslutz folks wrong)

is the attack/release time missing/unspecified factor actually the amount of signal over threshold?

I would say the first sentence is generally true of standard compressor behavior assuming there is 6db or 10db reduction available (your signal is at least 6db or 10db over the threshold) and you're talking about test conditions. Once you talk about real-world conditions, all sorts of things could be happening.

I believe Reaper is using a standard approach with perhaps a few more bells and whistles than many others. Don't know if you misunderstood or Gearslutz misled you. There are some very knowledgable people there. Of course there are also a few misdirected and misdirecting folks as well.

Not sure what you mean in the last sentence. The amount the signal is over the threshold is certainly a factor (along with Attack, Ratio, RMS, etc.) used to determine the rate at which compression will be applied. For example, if you peak at 10db above the threshold, you will have to reduce at a quicker rate than if you peaked at 4 db above the threshold, all other parmeters being the same.

[Baer]

Originally Posted by Tom Drinkwater

Why is reacomp even looking at the current position? it is set to lookahead, it should only be looking at the future position. This is what i mean by 2 detector circuits, it is looking at both the future and current positions and making decisions about which to use based on criteria that are still obscure (to me at least)

It is standing at the current position trying to decide what to do to the current sample. If Pre-Comp is non-zero, it will have to look at future data to decide what to do. And even if Pre-Comp is non-zero, it may still take action based on the current position conditions. See Rule 3 a couple posts ago (Post # 71).

[Tom Drinkwater]

i'll think more about it, but i agree that your rule 3 (and the others) seems to be a reasonable approximation of what reacomp is doing. However i don't agree that it is a sensible design or in any way what you might reasonably expect the controls given to do. To me precomp means that it is not considering the current signal at all, I certainly don't want it to be, except perhaps for release. If it is somehow considering both current and future signals the criteria or formula by which it combines them really needs to be published. I don't see a purpose in it.

EDIT i removed some stuff i wrote that was partly incorrect.

[Tom Drinkwater]

Originally Posted by Baer

Don't think of it as being mapped to events. Think of it as a parameter that gets used in some equation to determine how steep the compression rate will be. And it's defined such that after that increment of time, the compression will be close to reaching it gain reduction goal. How close? Depends on all the other factors and parameters going into the equation.

that's way too opaque for me. if the equation is so complex that it can't be discerned then there had better be a really good reason for it.

if i set a time with the slider i need to know what to expect, otherwise it would be better and more honest just to label it "faster" and "slower" which some compressors do. For me part of the appeal of reacomp is the specific numbers on things. - but if the results are not readily discernable from those numbers it would be better not to have them.

I asked what events, because it in the most general case imaginable it makes no sense to specify a time unless it is a time between 2 things happening, if you don't specify what those things are it means nothing.

[Tom Drinkwater]

Originally Posted by Baer

I disagree. In this case, like in Case 3 of yesterday’s post, there is one compression cycle which starts at the Pre-Comp initiation point and continues through the step increase. There is one release cycle at the end of the pulse.

if you make the attack and release times short relative to the pulse time and the precomp time you will see that there are 2 separate attacks and 2 separate releases, it is NOT just that the first attack hasn't finished when the pulse starts and so continues. this is consistent with the 2 separate "compression cycles" visible when the precomp time is longer than the pulse.

[Baer]

Originally Posted by Tom Drinkwater

i'll think more about it, but i agree that your rule 3 (and the others) seems to be a reasonable approximation of what reacomp is doing. However i don't agree that it is a sensible design or in any way what you might reasonably expect the controls given to do. To me precomp means that it is not considering the current signal at all, I certainly don't want it to be, except perhaps for release. If it is somehow considering both current and future signals the criteria or formula by which it combines them really needs to be published. I don't see a purpose in it.

To me it makes lots of sense. Without it, if you were using Pre-Comp, you may see an extreme spike which will go uncompressed because the offset location requires no compression.

Originally Posted by Tom Drinkwater

I don't really buy the idea of a 'compression cycle', sure that's what it looks like in terms of one shot high level events, but it seems to me that there is no inherent cycle - if its over the threshold it is attacking or has reached full compression, and if it under it is releasing or released.

if it goes a bit over the threshold it attacks until it reaches the specified compression ratio, if the level then goes higher it attacks more (but not again since that doesn't really mean anything) and if it goes lower it is still attacking (but more slowly) until it reaches the specified ratio until/unless it drops below the threshold at which point it starts releasing until it reaches the threshold again. There's no cycle in any of that it just follows the waveform.

I don't really see how else a compressor can work on a real signal.

I think your description is exactly what it’s doing. Maybe my use of the term “cycle” was confusing things. Once compression starts, it continues until there is a release condition. And I think that’s consistent with the ruleset/decision tree in Post # 71.

[karbomusic]

I asked what events, because it in the most general case imaginable it makes no sense to specify a time unless it is a time between 2 things happening, if you don't specify what those things are it mean nothing.

For anything other than academic purposes it is sadly irrelevant if making the changes results in a desired audial result.

Pretend you’re using a hardware compressor where the numbers on the knobs are approximations of things. Not enough of something? Turn it up. Too much? Turn it down.

Hopefully we are now realizing why many compressors' labeling tends to be "more/less/faster/slower" to begin with. As I hinted before, its musical content, trying to calculate what one expects to hear instead of just moving the slider until it sounds correct will quickly spiral into confusion and wasted time. And even if it all did match, it still takes a back seat to how it sounds. It matters no more than looking at a FFT graph to confirm if a mix sounds good.

[Tom Drinkwater]

Originally Posted by Baer

To me it makes lots of sense. Without it, if you were using Pre-Comp, you may see an extreme spike which will go uncompressed because the offset location requires no compression.

I think your description is exactly what it’s doing. Maybe my use of the term “cycle” was confusing things. Once compression starts, it continues until there is a release condition. And I think that’s consistent with the ruleset/decision tree in Post # 71.

I deleted the text you quoted, because i realised it was slightly wrong in that when the level drops from a high above threshold condition to a lower above threshold condition, that is actually a release. (i check reacomps behaviour in this situation and it applies a release curve)

however we agree that a compression cycle can in some situations be a misleading way to think about it.