OK fair enough. I can work the Knee and Dry with envelopes then - I thought I had an idea for a minute ! :)
ED: One more thing for general comment - I wasn't meaning to single out Polysquasher in particular. Right now it's my most transparent compressor that can handle a severe repair job, like the one I described above, smoothly. With the automation trick I can perform even deeper surgery very transparantly. The general idea of stretching PDC to other knobs of a compressor is a generic one regardless of the model. Now that I have my control surface working I can use that to automate the params of my VST compressors also along with the Blue Cat tool.
Hi Aleksey - going back to the vocal example I used earlier where the singer moves off-axis and out of proximity - then in a moment of passion & bad mic technique (hehe) comes back on axis and into a proximity zone...of course this is usually the best take - with the worst engineering and mic technique.
I have a vocal track with a verse that has an average rms of -29dBFS, maximum rms of -7db, and a peak of -3dB to give you an idea of the wave 'crest' as Bob Katz calls it. That's a dynamic range of 26dB over the course of an entire verse. There is a short vocal phrase within the verse that accounts for the huge dynamic range where the average rms is at -32dB (w/peak -17dB) then the next phrase jumps up to an average rms of -20db (w/peak -3dB). This all happens within about 1/2 second, 540ms. That's too much dynamics within too short of an integration time for Mr. Ear I think. And aside from the statistics when I listen to the track the difference between the average level of the preceding phrase and the peak level of the next phrase (that goes to peak in 540ms) is way too much to fit into the mix.
I have a number of different compressors that can tame peaks and level dynamics but the one I chose for this job (because it sounded the best and most transparent) was Polysquasher. Polysquasher can reduce the dynamic range 6dB easily with no sweat - without artifacts or that over-compressed sound. A couple of my better compressors will do a 6dB gain reduction without artifacts so this is typical in my tool bag.
So I can get 6dB of gain reduction from the compressor 'batch settings' that I have statically set on the threshold, ratio, knee, and dry params - these all ride the envelope along the course of the entire song and must be set accordingly in an average type of fashion. What about the more extreme dynamics that need to be tamed? I need at least 6dB more gain reduction without getting a squished over-compressed sound (in this case).
This is where manipulating the Polysquasher knee and dry params comes into play - in the extreme case. Knee normal position during this scenario is very low, maybe 3dB or Hard (off). Just before the extreme and fast dynamic peak hits my automation raises Knee to about 25dB or so - this lets compression begin to take affect at a lower dynamic level than normal (thanks to Polysquasher Knee curve I think) and prevent a peak from getting squashed too fast (too Hard) while at the same time preserving program material that doesn't need any compression because knee is dropped back down after the peak (about 250ms later). The same can be done with the dry knob. Once the nominal, average or 'sweet' setting is found for the entire program exception cases can be handled using automation envelopes. An inverse peak envelope would turn the dry knob down a bit (for maybe 200-300ms) - forcing Polysquasher to output a more compressed program during extreme peak conditions. This actually sounds very smooth and can level out some seriously rough spots that normal 'static' compressor settings can't while preserving much of the program that doesn't require compression.
Anyway - that's about it. Sorry for so many words - I don't know how to say it any shorter!
Kyle, I understood your idea for the most part. But how should such compressor handle very fast volume swings? The problem with any kind of dynamic processing is that it handles incoming transients poorly because it cannot predict what should be there later. Releases are performed better usually, but then again an unexpected signal peak can destroy the smooth release stage.
I mean that such detector won't be able to adjust the knee setting prior to the unexpected peak level.
How about a bit reduction plug so that the music sounds really bad.
That way when I'm working with a band and they say to me that the recording doesn't sound good, I can bring this plug up and show them how bad it could really sound. The design would just be a panel with one button that is labeled "suck". That way I can push the suck button anytime I want:)
Aleksey, you said:
"But how should such compressor handle very fast volume swings? The problem with any kind of dynamic processing is that it handles incoming transients poorly because it cannot predict what should be there later. Releases are performed better usually, but then again an unexpected signal peak can destroy the smooth release stage.
I mean that such detector won't be able to adjust the knee setting prior to the unexpected peak level."
I think you're right Aleksey. The detector wouldn't be able to know the future unless it looked-ahead. I suppose that might be a possibility in a host with PDC like Sonar. That changes things though I think trying to get Polysquasher to do this in real time. I took a closer look at the automated envelope I'm getting from the Blue Cat plugin, the envelope anticipates the actual audio slope by some milliseconds because (I think) I have Redunoise inserted which is causing Sonar's PDC to let Blue Cat plugin see the audio sooner (?), side-affect is some kind of look-ahead I guess. That's probably accounting for the new smoothness when running the automation envelopes on Polysquasher, the envelope hasn't been delay compensated. So this is an off-line thing impossible in real time without latency... that would be OK for me though!
Aleksey - I confirmed that Blue Cat's ability to see into the future is directly related to the latency in Sonar. Some of it comes from the settings in the mixing latency buffer size (currently 1.5ms the fastest for me) and plugins that introduce PDC may account for it too.
A compressor plugin like Polysquasher could have an option to introduce latency (assuming the host could do PDC), see into the future, and allow Knee and Dry to have program dependent settings that correspond to threshold, attack, and release AND be able to respond to fast transients. It might take getting used to the advanced level of settings since they would not correspond to non-latency type settings - in other words the release would probably need to be a lot slower depending on how much latency was set.
Well I guess that's about it - I just wanted to complete the thought. Maybe it's easier doing this with envelopes after all. Since you can see the envelope it might be less confusing anyway and cut down on bug reports from confused customers (like me!).
Thanks for the discussion! Sorry to be such a windbag in your thread drjee, hehe!
This topic was last updated 180 days ago, and thus it was archived. Replying is disabled for this topic.