Upwards software compressor

[SouthSIDE Glen]

Glen, I finally understand your definition better from that last post. It's also in line with Chibi's algorithm. Most people use parallel comp and upward compression interchangeably.

Only amongst the cliquish brotherhood of music audio engineers.

That's not *my* definition of upward compression, that is *THE* definition of upward compression in general and understood much easier in just about any engineering field dealing with analog signal processing and analog information theory outside of the relatively small one of audio engineering.

But unfortunately, in audio engineering folks have become so biased into thinking that "compression" means downward compression that they try to find Rube Goldberg ways to use downward compression to synthesize everything. Hence the belief that parallel compression is really upwards compression, because that's what a few name brand engineers called it in an originally slang-ish way because it kinda sorta resembled a form of real upwards compression.

Again it's just like "normalization", where a colloquial use of the term common strictly to our narrow little racket has led folks to believe that "normalization" means something close-to-but-not-quite-really what it actually does mean. (And don't even get me started on "phase inverter" switches on track channel strips . )

Yeah, to a degree it's just semantics, but on the whole it's more than that. These colloquial "slang" uses of otherwise common engineering terms lead to misunderstanding and miseducation of the real mature of what's going on.

G.

 

[SouthSIDE Glen]

A slight mod to what Chibi posted:

s = signal
t = threshold
r = ratio
o = output
g = gain increase

if (s>=t) {
g=0
}
else {
g = s*r
}
o = s + g (Southside Glen)

That's still trying to view upward compression as a form of downward compression plus gain. It's not.

Once again, whether we're talking compression or expansion, "downward" and "upward" are simply mirror image processes of each other.

I'd write the whole companding pseudocode something like this:

s = signal
t = threshold
r = ratio
o = output
p = process type


if (p = 'Downward Compression'){
if (s >= t){
o = s - ((s - t) - ((s - t) / r))
}
}

if (p = 'Upward Compression'){
if (s <= t){
o = s + ((t - s) - ((t - s) / r))
}
}

if (p = 'Downward expansion'){
if (s <= t){
o = s - ((t - s) * r)
}
}

if (p = 'Upward expansion'){
if (s >= t){
o = s + ((s - t) * r)
}
}

This code ignores zone boundaries other than threshold, which are typical in most upward compressing tools, but they could easily be put in. I wanted here to concentrate more on the nature of the companding processes themselves than worry about the boundary conditions.

G.

 

[Waltz Mastering]

Yeah, to a degree it's just semantics, but on the whole it's more than that. These colloquial "slang" uses of otherwise common engineering terms lead to misunderstanding and miseducation of the real mature of what's going on.

fwiw. I think Ted Fletcher (designer) might of been one of the first to coin the phrase "parallel compression" and incorporate it (blend knob) into his compressor products.

 

[SouthSIDE Glen]

fwiw. I think Ted Fletcher (designer) might of been one of the first to coin the phrase "parallel compression" and incorporate it (blend knob) into his compressor products.

It's not "parallel compression" where the confusion comes in, it's the calling it "upwards compression", because that gives "upwards compression" two different definitions.

It's like the terms "producer" or "beat", which mean something somewhat different in the hip hop world than they do in the rest of the music production world.

G.

 

[masteringhouse]

That's still trying to view upward compression as a form of downward compression plus gain. It's not.

Once again, whether we're talking compression or expansion, "downward" and "upward" are simply mirror image processes of each other.

I'd write the whole companding pseudocode something like this:

s = signal
t = threshold
r = ratio
o = output
p = process type


if (p = 'Downward Compression'){
if (s >= t){
o = s - ((s - t) - ((s - t) / r))
}
}

if (p = 'Upward Compression'){
if (s <= t){
o = s + ((t - s) - ((t - s) / r))
}
}

if (p = 'Downward expansion'){
if (s <= t){
o = s - ((t - s) * r)
}
}

if (p = 'Upward expansion'){
if (s >= t){
o = s + ((s - t) * r)
}
}

This code ignores zone boundaries other than threshold, which are typical in most upward compressing tools, but they could easily be put in. I wanted here to concentrate more on the nature of the companding processes themselves than worry about the boundary conditions.

G.

Glen, I think that we are using "r" differently.

When specifying a 2:1 ratio I was using r=.5 I think that in the equations above you would be using r=2?

It's kinda screwy that a few equations make more sense and remove the ambiguity (other than the confusion in variables) of a 100 word essay on what a term means. Or maybe I've been watching "The Big Bang Theory" too much on TV.

 

[The Cancers]

Ok, so everybody's apparently on the same page as to what's going on here.
Now, I had a thought while considering the DBX technology that Glen brought up as an example.

Upwards compression contains an element that downards compression doesn't, namely the noise floor.
I'm having trouble visualizing it, but won't that constant signal way out there past the threshold cause some sort of problems?

If an upwards compressor is truly just a mirror image along the threshold of a downwards compressor, then wouldn't the downwards compression analog of the noise floor be like having a constant sound much higher in volume than any of your peaks?

I could see how designing the compressor to become linear again some set distance below the threshold could solve the problem, but maybe they do it differently.

I dunno, in practice, does anybody know how or if the noise floor creates problems and/or how or if these problems are rectified in an upwards compressor?

 

[SouthSIDE Glen]

Glen, I think that we are using "r" differently.

When specifying a 2:1 ratio I was using r=.5 I think that in the equations above you would be using r=2?

Yeah, you're right, Tom. I didn't catch that difference. Sorry about that.

I understand your use of the .5 as meaning that you're dividing the input above threshold in half, but I wasn't thinking that way because of the temptation to interpret a "ratio" of .5 as meaning .5:1, or 1:2, which actually indicates expansion. That's just a problem in none of us defining our variables specifically enough.

The funny irony there is that in that case it was a case of us using too few words to define the variables .

It's kinda screwy that a few equations make more sense and remove the ambiguity (other than the confusion in variables) of a 100 word essay on what a term means. Or maybe I've been watching "The Big Bang Theory" too much on TV.

Well, look at the bright side; you could be watching "Two and a Half Men" instead, in which case this thread would have just been a bunch of unfunny dysfunctional insults

G.

 

[SouthSIDE Glen]

Ok, so everybody's apparently on the same page as to what's going on here.
Now, I had a thought while considering the DBX technology that Glen brought up as an example.

Upwards compression contains an element that downards compression doesn't, namely the noise floor.
I'm having trouble visualizing it, but won't that constant signal way out there past the threshold cause some sort of problems?

If an upwards compressor is truly just a mirror image along the threshold of a downwards compressor, then wouldn't the downwards compression analog of the noise floor be like having a constant sound much higher in volume than any of your peaks?

The short answer is, "Yes, the noise floor can be a problem in upwards compreession".

The longer answer is that almost all the tools that I know of that offer all the types of companding, including upward compression, allow you to put a range limit on just what is being expanded or compressed. To go back to that sample image from Neodynum, the lighter orange area on the bottom represents the zone I set up for upwards compression:

The left side represents the input range, the right side the output range. Note that I set it up (in this hypothetical case) so that it was only upward compressing that part of the signal with an input signal level between -10 and -20dBFS. Nothing below -20dBFS will be touched in that setup.

In that way, yes there is a difference between such dynamics plugs and the analog downward compressors we're all used to, because those down compressors have only the threshold, but have no "anti-threshold" (so to speak) on the other side of the range at which they stop working. But that's just a difference in the implementation of the tool, not in the actual compression processes themselves.

With the dbx companders, they are not designed to worry about analog noise that's already in the signal before they hit the tape (which is represented in that dbx schematic by the lower yellow line as the bottom of the signal's dynamic range). They are only designed to worry about the noise added by the tape itself (the red line.) So when the signal is decoded on playback, it has (ideally) exactly the same amount of analog noise in it that hit has before it went to tape. It just takes care of the tape hiss itself.

G.

 

[masteringhouse]

My apologies to the OP, but some of the posts here inspired my inner geek. And isn't that what this forum is partly about?

Anyway for Chibi and Glen I found this code for a downward compressor:

http://www.musicdsp.org/archive.php?classid=4#169

The important lines for the topic here are:

For a downward compressor:

// the very easy hard knee 1:N compressor
double gain = 1.0;
if (env > threshold)
gain = gain - (env - threshold) * slope;

// result - two hard kneed compressed channels...
float leftchannel = wav[0] * gain;
float rightchannel = wav[1] * gain;

For an upward compressor I believe it would be:

if (env < threshold)
gain = gain + (threshold - env) * slope;

// result - two hard kneed compressed channels...
float leftchannel = wav[0] * gain;
float rightchannel = wav[1] * gain;


Chibi you were pretty close to this same same algorithm, you have the job!

 

[philbagg]

Are people actually gearing up to build one?

 

[masteringhouse]

Are people actually gearing up to build one?

At some point I would like to take a stab at an AU or VST plug-in. But even if not, I think that it really helps to increase knowledge on the principles of how they work and the complexities involved behind them.

Currently I'm mostly interested in seeing if there is a way to reproduce this through a chain of analog gear or standard compressor/expander plug-ins. Doing things that way usually gives you many more possibilities than just buying an off-the-shelf plug-in.

 

[philbagg]

At some point I would like to take a stab at an AU or VST plug-in. But even if not, I think that it really helps to increase knowledge on the principles of how they work and the complexities involved behind them.

How about RTAS?

 

[The Cancers]

Absolutely.

I think G. answered the OP by halfway through the first page, but it doesn't mean the rest of this wasn't fascinating.

 

[masteringhouse]

How about RTAS?

Digi is very proprietary and will not make their software development kit public. Basically you have to show them what you are going to develop and for whom and then they make the decision if you are worthy.

Core audio/AU and VST are public.

Absolutely.

I think G. answered the OP by halfway through the first page, but it doesn't mean the rest of this wasn't fascinating.

Yep and your answer was good as well. Personally I just didn't feel as if I was getting a full picture, different perspectives shed light on other parts of the image. Even robots with amplifiers and light bulbs are useful.

 

[philbagg]

Absolutely.

I think G. answered the OP by halfway through the first page, but it doesn't mean the rest of this wasn't fascinating.

Agreed. And the OP doesn't mind the trail off (yet still on) topic

 

[masteringhouse]

Ok, so definition aside. If you run parallel compression with a brickwall limiter after the compressor set to the threshold where you do not want to affect, is this the same as simple upward compression?

 

[masteringhouse]

Ok, so definition aside. If you run parallel compression with a brickwall limiter after the compressor set to the threshold where you do not want to affect, is this the same as simple upward compression?

No, but still looking ...

A cool puzzle. This would take care of increasing the gain of low level signals below threshold, but how do you extract the component of the audio that's being added above threshold and limited?

 

[philbagg]

No, but still looking ...

A cool puzzle. This would take care of increasing the gain of low level signals below threshold, but how do you extract the component of the audio that's being added above threshold and limited?

How about this (just an idea):

1. Duplicate the track (Track A and B)

2. Use strip silence (Pro Tools) or an equivalent to remove any audio below a
set threshold (almost like a rendered gate, but on an editing level) on Track A,
so you have only the peaks. (Track A = Peaks only)

3. Use strip silence to remove any audio above a set threshold on Track B, so
that you have everything but the peaks. (Track B = No peaks)

4. Leave Track A (peaks) untouched (like the idea of upwards compression).

5. Compress Track B and apply make-up gain to taste in comparison with
track A.

Result in theory: The lower level signal is compressed and brought closer
in level to the peaks without using downward compression on the peaks.

I'd imagine you'd have to use a fairly transparent compressor (used lightly) so
that the transition in character between Track A and Track B goes unnoticed.

What do you guys think? I know it's not TRUE upward compression, but it
should yield a similar result.

 

[SouthSIDE Glen]

Ok, so definition aside. If you run parallel compression with a brickwall limiter after the compressor set to the threshold where you do not want to affect, is this the same as simple upward compression?

I would think offhand that brick wall limiting would not remove the upper signal, it would only force it down to the threshold; i.e. the entire signal would be below or at the threshold value, wouldn't it? It's really nothing more than extremely high-ratio compression.

But even if/once you removed the above-the thrshold stuff, the main thing I'm unsure of there is how well one can control the shape and slope of the compression curve below the threshold with a parallel setup.

Sure, one can set up the compressed track to the compression ratio they want, but the eventual curve - the one that gives parallel compression it's "preference" for the lower amplitude stuff - is the product of the summing of the compressed and uncompressed signal. I don't know how the math actually works there myself; is it content-dependent or is it a fairly linear formula? And then when you add in the extra variable of wet/dry mix ratio, that's probably going to change it too.

Unless there's already some formulas out there for calculating that stuff I'd imagine that it might take a little lab work to plot some curves and see how that plays out.

A cool puzzle. This would take care of increasing the gain of low level signals below threshold, but how do you extract the component of the audio that's being added above threshold and limited?

I'm only speculating here, Tom, but I'd think that there must be some method for filtering the signal by amplitude, in a kind of amplitude version of what a Fourier transform does for frequency. How to code that, I don't know (frankly I never thought about it much before now); but there are obviously ways of detecting/determining amplitude of compound signals (see any dynamics processor or spectral display), so if they can be detected, displayed and even manipulated, they can be ignored.

Which makes me wonder, Tom; if you can find code for downward compression, I'm wondering if there's open source out there for a dynamics processor, seeing as how that seems to be such a ubiquitous tool. Tthat should give you the code you'd need for that question.

BTW, @philbagg : So how did you wind actually attacking your OP problem with the piano? Did/does PT have a dynamics processor tool?

G.

 

[noisewreck]

Sorry, haven't read some of the posts, but am aware of the discussion about what constitutes of upward compression vs parallel compresson vs downward compression.

However, my comment/question is related more to the OP. Wouldn't applying upward compression to bring up some weak notes affect the overall sound envelope/decay of the piano sound? This would be something to watch out for in this instance.