I need some help with compression techniques (I think)

Feb 9, 2014 at 7:43am

I need some help with compression techniques (I think)

So for the longest of times, I thought the problems I encountered with screwed up sound was due to CPU utilization problems, i.e., not enough cycles. The CPU utilization would flicker, sometimes to a really high number, just for a moment when I had a lot of VSTs playing simultaneously.

A few weeks ago I realized the problem might not in fact be a CPU problem but rather, sending the output of many VSTs to a single dac~ is causing clipping.

I tested this (only by ear) by turning down the volumes of the individual VSTs and playing the song again and it sounded perfect.

Therefore, I need some guidance on how to deal with this and would appreciate advice.

1) How can I confirm objectively that this is what is happening? I’m less fluent with building MSP patchers than with Max (MIDI) event-based patchers and so I haven’t figured out how I can keep track of the absolute maximum value numerically so I can see explicitly that the signal is going higher than 1.0

2) What’s the best way to deal with this?

A) I looked at the normalize~ object as it seems like it can scale the sum of an arbitrary number of signals on the fly. The trouble (I think) with that object is that as well as reducing the amplitude of loud sounds, it will also increase the amplitude of soft sounds and that’s no good.

B) Compression? Limiter? Block limiter? If so, what’s the best way to tailor one of these things so that it won’t unnecessarily reduce audio when the material is not too loud?

Thanks for any tips.
D

#280478
Feb 9, 2014 at 8:53am

meter~ and levelmeter~ give visual feedback of audio levels. I use meter~.

My strategy to avoid clipping is setting the gain levels of my individual sources so that my mix in the loudest part of the piece comes close to but stays a couple of dB’s under 0dB. To catch rogue peaks I put a limiter on the outputs. A brickwall limiter at -0.5dB with 0 gain will simply cut off at that amplitude and leave the rest unchanged. You could opt for a compressor plus limiter but my projects don’t call for that.

#280486
Feb 9, 2014 at 10:20am

if you want to be on the safe side you need to lower the volume about 1/n for n source signals between 0. and 1.

so for example when adding 8 vst instruments, you need to do [*~ 0.125] to their sum to make sure you dont exceed 1. at least in theory! there are some instruments, which are louder than 1.0 anway.

so i think the best solution is to add a little mixer in your patch, one which also uses meters to help you see whats going on.

#280497
Feb 9, 2014 at 11:36am

I know that — I already have a mixer in my system but at a higher level. In fact it was from adjusting volumes through the mixer that I realized the problem was more likely a clipping issue than a CPU issue.

But my design (and desired implementation) is such that I need to automate this stuff. The way it works is that I have virtual” ports to which any VST can send audio. Depending on other factors, those virtual ports may get mapped to separate physical outputs (when I’m running in 8-channel mode) or they may all go to one output. In fact there’s often both because there might be a stereo monitoring pair independent of the 8 separate outputs.

The problem with the solution of multiplying by 0.125 when there are 8 VSTs is that those 8 VSTs will most likely not be running simultaneously. So the actual number of non-zero feeds to an output can change on the fly and it will also depend on exactly how loud is each VST at a particular point in time. So what I want is something that will to reduce the overall volume just enough when the sum of instantaneously live outputs will clip. I think a block limiter is what I need but I don’t totally understand the best way to implement that directly in MaxMSP and I think I have to do it that way rather than use yet another plugin.

#280500
Feb 9, 2014 at 12:09pm

Hi
Peter McCulloch recently posted a nice little squasher:

<code>

– Pasted Max Patch, click to expand. –

</code>

Which may be of some use, if strapped across your main output.

Brendan

#280504
Feb 9, 2014 at 1:50pm

hi, hope that works for you(gen compressor with lookahead). Try to stay away from the hard-lim though, it just implements a tanh~ function. (A look up is the safest way to keep levels down but introduces distortion as you know.) Emphasis is also something custom i wouldn’t use if you want a smooth output, it’s just something like and don’t know how to call it.
cheers

please report if you find something not working etc

<code>

– Pasted Max Patch, click to expand. –

</code>

poly guts (save as “newcomp1_1.p.maxpat’):

<code>

– Pasted Max Patch, click to expand. –

</code>

#280512
Feb 9, 2014 at 2:35pm

@Brendan Thank you, I’ll try that out — not sure how well it will work as it seems more like normalization than just reducing stuff that’s going to clip

@Woyteg I’m still using Max 5 for live performance so can’t leverage anything with gen in it. Nevertheless, I appreciate the opportunity to see these alternative solutions.

#280514
Feb 9, 2014 at 2:45pm

really? gen~ is great for compressors, that’s a pitty.

why don’t you use the good ol’ omx, btw?

#280515
Feb 9, 2014 at 3:16pm

a gain controller for every physical output is a must have in any audio application, no matter how creative it looks otherwise. :)

#280523
Feb 9, 2014 at 6:23pm

@Roman Uhmmm, yeah…that’s why I posted the question — but I need something that’s automatic and can handle an arbitrary number of signals going to the output. As I said in my first post, I’m not that fluent with the signal processing side of things.

@Woyteg The omx was one of the options I mentioned in my original post but if that’s the right object, then I don’t know how to best configure it — I’m experimenting with all these things but figured I’d ask for some guidance from people who know it better than me.

#280536
Feb 9, 2014 at 6:31pm

Oh, sorry I didn’t read it completely.
In general, I would say if you can afford the CPU intensity, you should rather limit each (‘dangerous’) channel also. That might yield a bit nicer results.
The OMX has a lot of parameters and I havent looked at it for a while. Also it seems a bit too much for jsut limiting but, anyway, crank up the ratio, threshold near 0 db but below, look for a lookahead feature (does it have one?) and go way down with the attack. The result should be a limiter. cheers

#280537
Feb 9, 2014 at 6:39pm

Thank you — the individual original channels do go through a software max-based mixer and are always well below the threshold. This has only become an issue when I have a lot of VSTs all sending signals to a physical device. It’s my naively connecting them all to a single output and hence just summing them all that screwed me up — I just always put it down to CPU utilization, it only just hit me last week that it was actually a clipping problem.

I’ve started playing with the OMX and yeah, I was a bit concerned about the CPU utilization if I use 10 of those things. Thank you for the configuration suggestions.

#280538
Feb 9, 2014 at 6:46pm

hm so if the individual channels are *always* ok roman made the best suggestion: *1/n
You know you can attenuate the mix simply by an estimate of n, the number of channels. Just before going out the dac. Most signal processing can deal with number over 1. And this will for sure sound better than limiting alot. A limiter on the mix just to be sure is essential though.
cheers
edit:got the division wrong, 5 am.. :)

#280539
Feb 9, 2014 at 7:40pm

Two other things(since I’m into this right now):
I’d rather not put that squasher on a sum. It distorts the signal very similar to the tanh~ function. A bit more with really high levels.

and you asked: how to be sure you are to high?
If you really want to be *sure* you’d need to implement True peak (R 128) because of inter sample clipping. I’ve tried it once but I’m not happy with the result. anybody else had luck with this?

#280542
Feb 10, 2014 at 2:56am

@dhj*3: Well I guess you could automate things by keeping track of how many sources are sending to 1 output and measuring their individual amplitudes to calculate a gain reduction factor. Though I wouldn’t go that route ’cause 1) it’s going to be complicated and 2) you’re going to experience automatic gain changes that might be unwanted in your performance.

Personally I think the standard way of mixing things in the digital domain is most effective: set your individual source levels so that the loudest part will not clip (in your case, including the dynamic routings you do), and add a limiter to prevent accidents. Analog mixing is much more forgiving. Digital clipping is nasty (when you don’t intend it ;) so you really need to control your levels.

#280574
Feb 10, 2014 at 4:03am

The thing is, the individual sources go out to their own independent physical outputs and don’t clip AND there is another mix to stereo for monitoring. I just want to have some automatic limiting on the latter.

#280577
Feb 10, 2014 at 4:14am

if it’s just for monitoring i would definitely try tanh~. It feels a bit analog, you can fear the distortion coming very slowly. (so you get a feeling for how loud you are) and it is very safe and CPU-wise very cheap compared to a nice sounding limiter..

#280580
Feb 10, 2014 at 4:31am

Yeah, I’m going to try that one after I’m done teaching today.

Everyone, I TRULY appreciate all the feedback.

#280582
Feb 10, 2014 at 4:34am

The thing is, the individual sources go out to their own independent physical outputs and don’t clip AND there is another mix to stereo for monitoring. I just want to have some automatic limiting on the latter.

Same still applies. Make sure the send levels (or however you route) to your monitor mix don’t overload the outputs when combined and slap a limiter on it.

#280584

You must be logged in to reply to this topic.