.

Context?

idk, maybe some hardware emulations insert noise even when not compressing ?
 
Just a guess.
 
Seems reasonable that at 0 db gain reduction it's transparent. If they are oversampling and then downsampling, perhaps it's a feature that they don't dither at 0 dB gain reduction?
 
Seems like something technical that came from the VST designers to the marketing team and the marketing team, having no idea what it meant, put it in verbatim without explanation. 

gswitzSeems like something technical that came from the VST designers to the marketing team and the marketing team, having no idea what it meant, put it in verbatim without explanation.

Oh no, I don't have (or want) a marketing team. I had to register on my own. :)
 
Good audio dynamics compression needs to be properly antialiased, or it will sound bad. This is very difficult to do at 44.1kHz and 48kHz, because every dynamic device operating on the full input bandwidth has to multiply the original signal with another dynamic control "voltage". This leads to a serious problem, because this operation extends the original bandwidth (very similar to a ring modulator). But a 44.1kHz system is not able to represent say, 30kHz and will directly produce aliases in the audible band (= not good).

Some plugins resample the input to a higher rate, process and resample back to the original rate in order to handle the bandwidth extension and thus, avoid aliasing artefacts. This works fine, but comes at a price: The resampling filters will have to sit between in and outs of the plugin.
 
Kotelnikov does similar, but only resamples what he "changes", and not the original signal. This doesn't restrict the original bandwidth (and doesn't extend it either!) and offers a few more advantages. This is essentially what the sentence means.
 
Most available anti-aliased compressors audibly restrict the original bandwidth (beside other bad stuff resampling filters can do). Kotelnikov allows to enjoy the advantage of oversampling with the typical drawbacks. :)
 
Check the manual for a whole chapter about the topic.

Thanks for the answer @FabienTDR.
 
It sounds like parallel anti-aliasing work where anti-aliasing efforts are only executed when necessary (similar to parallel compression where you have the 'mix' nob to adjust the amount of the original track to merge with the compressed track).
 
The up-sample and down-sample only happens for signal the plugin actually compresses.
 
Mike, you know how lots of plugs have that 'Mix' nob? I'm thinking that this plug auto flips the Mix nob to 0/off unless some compression is happening... in a way, bypassing the plugin unless it should be impacting the signal.
 
I'm totally thinking some of our math experts on the forum would say that with proper gain staging the dither from the down sample shouldn't be audible, but it does seem like a nice feature - especially if it makes it more efficient from a computing perspective.
 
Further, listening to @FabienTDR, it sounds like the trigger to determine whether to compress happens before the upsample, so the upsample-downsample only happens when necessary. This might save a little on processing power in the PC. It wouldn't be 'always-on'. It would come on for a second and be off for a second and flip on for a second and go off for a second. I'm imagining it only upsampling from when the snare hits to the end of the release time. Something like that.

I see where you're coming from, Mike. Oversampling with no gain reduction is like advertising a really, really high-fidelity piece of straight wire.
 
It's a communication issue. Fabien is a genuine expert in the field, guru to the gurus, someone I always stop and listen to. But English is not his first language so sometimes his explanations require further contemplation before they make complete sense (e.g. "Kotelnikov allows to enjoy the advantage of oversampling with the typical drawbacks"). 
 
Some of the concepts Fabien has talked about are rather advanced, and would be a challenge to express even in one's own native language. I may be about to prove that point as I attempt to re-phrase it in my own native tongue...
 
What he's saying is that oversampling compromises perfect fidelity due to the required filters, even when the plugin isn't actually doing anything else other than just oversampling/downsampling. The input and output of an oversampled plugin will therefore never null. 
 
Kotelnikov takes a unique approach to mitigating this effect. It subtracts the output from the input to determine what's changed, then adds the difference back in to the input to create the final output, and that's what you hear. Because only the difference between input and output is oversampled, the lower the gain reduction the less effect oversampling will have on the final output. By the time you get all the way down to zero gain reduction, there is no more difference and therefore no oversampling, and you've achieved perfect nullability between input and output. No other compressor can make this claim.
 
I confirmed this oversampling-doesn't-null phenomenon for myself through experimentation. I used a high-quality plugin (FabFilter Pro-MB) with no processing enabled, and then used null tests to confirm that the output was identical to the input with oversampling turned off, but that they no longer nulled completely when oversampling was turned on.
 
However, the difference was too small to see in SONAR, even with the zoom all the way up. I had to use an audio editor (Adobe Audition) to actually see the data. It was very small, with a peak sample value of 6.3, which Audition reported as -74dB. I verified in AA that the sum signal with oversampling disabled was a true flat line - zeroes all the way across, to make sure this tiny difference wasn't just noise (e.g. accidental dithering).
 
So Fabien's right. Conventional oversampling does in fact cause a minute loss of fidelity. However, I gotta say that anything that close to the noise floor isn't something I'm gonna worry about. It does reflect the extraordinary lengths he went to in this plugin's design to make it as transparent as possible.

It's freakin' free!!

Hey bitflipper, this is a somewhat nerdy "feature" indeed. But definitely an important facet of the concept, because the issues of the standard approach can quickly stack up in chains. If every nonlinear device does this, it's easy to end up with serious damage due to the successive bandwidth restriction (chaining a few of these oversampling plugs makes it more obvious). This is probably not super relevant for many ppl's workflows, though. In particular for typical mix-bus work. But the advantage can become easily audible given a wideband high quality source such as a HQ pre-master.
 
@gswitz: The delta signal is absolutely continuous, there's no on/off (this would produce distortion). It's just that the delta signal often drops to zero, and in this case, cancels out any (negative) effect of the resampling filters. Put differently, the resampling filters can only damage the "distortion", not the original "meat".
 
@mike: :D
 
Many thanks to everybody for the compliments! :)

May I use these on Linux? I notice Linux isn't a supported OS.
 
I'd be interested to know if I can use them with Ardour.
https://ardour.org/features.html
 
I should add that it's fine if it is not supported, just wondering if the paid Gentleman's versions can work.
 

The Ardour Manual
A Plea To Plugin Manufacturers
Please consider porting your plugins so that users can enjoy them on Linux too. Several other commercial plugin developers have already done this. You can choose between using "Linux VST" (which is what Loomer and others have done) - you will find toolkits like JUCE that help to make this fairly easy - or using LV2 format which is ultimately more flexible but probably more work. We have users - thousands of users - on Linux who would like to use your plugins.
[/quote/]
http://manual.ardour.org/working-with-plugins/windows-vst-support/
 

post edited by gswitz - 2015/02/01 21:52:21