On Sat, 20 Aug 2005 11:49:07 +0100, Chris Stiles wrote:

Is there a particularly sample/bit rate or rate limit that the various VST and
plugin manufacturers optimise their plugins for in terms of sonic quality?

I've variously heard people say that lots of commercial plugins are optimised
for either 16bit 44.1khz or 16bit 48khz and start sounding grainy when used
above these rates.

All audio communication to a VST plugin is always 32bit float between -1
and +1. The bit depth of your recorded audio is irrelevant as virtually
all DAWs work at 32bit float for their internal mixing and routing.

The host informs the plugin of sample rate changes via setSampleRate, and
the plugin should accept any sample rate required.

I've had a few old plugins do strange things or crash when I try to use
them at 96k, but that's pretty rare nowadays. If the plugin sounds strange
at 96k then it's not optimized for lower rates, but broken at higher ones.

Chris Stiles wrote:

Is there a particularly sample/bit rate or rate limit that the various VST and
plugin manufacturers optimise their plugins for in terms of sonic quality?

I've variously heard people say that lots of commercial plugins are optimised
for either 16bit 44.1khz or 16bit 48khz and start sounding grainy when used
above these rates.



VST plugins are 32 bit float internally, and samplerate
should not matter. There are methods published in the SDK
for discovering the SR, and properly coded ones will
work with any possible SR.

Some ActiveX plugins offer 32 or 64 bit,
at least on the little GUIs for 'em, so I'd conclude they can
be bigword.

If people are coding them to 16 bit, they actually run the risk
of being somewhat slower - it ain't real mode no more....

--
Les Cargill

"Les Cargill" wrote in message
...
I've variously heard people say that lots of commercial plugins are
optimised
for either 16bit 44.1khz or 16bit 48khz and start sounding grainy when
used
above these rates.


I've never heard of this "optimization".

Chris Stiles wrote:
But - and this is a question rather than a statement - 32 bits internally
isn't likely to be enough if you are dealing with 24bits and above, right?

It should be sufficient for almost all cases, which is why they've
pretty much standardized on 32.

Remember that you're feeding 24 fixed-point into a 32 floating-point
process. The high bits of the 24 are going to be zero on most samples;
the low bits are going to be noise on most samples; losing a bit of
precision during floating processing is probably less significant than
the losses you'd have experienced in an analog studio. Yes, if you put
the signal through enough processing stages error can accumulate, but
this is in the category of "if it hurts when you do that..."

Also remember that your final product's going to be 16 bits. You record
at 24 precisely because that *does* give you room to play.

Also remember that your final product's going to be 16 bits. You record
at 24 precisely because that *does* give you room to play.

Excuse me for being green, but . . .

Does this mean that if I use an interface capable of a 192kHz sample
rate, the quality of my final track will be determioned by the sample
rates of any plug-ins or DSP effects I use?

oldhead wrote:
Does this mean that if I use an interface capable of a 192kHz sample
rate, the quality of my final track will be determioned by the sample
rates of any plug-ins or DSP effects I use?

I believe software effects adjust for sample rate. However, running an
effect (or a DAW generally) at a higher sample rate burns more CPU,
which may limit how many tracks with how much processing you can
actually handle.

Chris Stiles wrote:

Les Cargill writes:

VST plugins are 32 bit float internally, and samplerate
should not matter. There are methods published in the SDK
for discovering the SR, and properly coded ones will
work with any possible SR.


But - and this is a question rather than a statement - 32 bits internally
isn't likely to be enough if you are dealing with 24bits and above, right?

It is very likely to be more than enough. 32 bit float
is 22 bits of fraction, 10ish of exponent. And the internal
registers they're twiddling are bigger.

Coders in floating point have to be EXTREMELY mindful of
range/domain issues, but it ain't rocket surgery.
The afilure modes are usually prettv obvious, too...

In the simple case of some step that uses multiplication and then division of
two 24bit numbers you'll end up 'losing' some of the lower order bits.


The mathco embedded on Intel boxes (at least)
uses some larger (48? 64? 128?) bit internal
registers.

The noise figure* for quant. noise for 32 bit float
is some ridiculous thing like +10 on the Kelvin scale.
Less noisy than space halfway between the Earth and
Moon or something I'm being silly, but it's
like that...

*it's not really a scalar....

In terms of sample rate what about plugins that convolve the input with some
waveform ? Or will they have that waveform stored at all the sampling rates
that the plugin supports?



I don't think we can improve on a case by case basis,
here. Ask the manufacturer. I'd make you convert 'em
external to the plugin, if I were coding it. SRC is
not easy.

And geez, we're talkin' CONVOLUTION here. The Fourier
transform they use to get it faster than O(n*m)
multiplies will leave fingerprints. Just think how
much worse that will be at 64 bit...

If you are Seriously Concerned, convolve
a single 0dBFS sample with an impulse and
compare the output and impulse files. I've always
gotten 100% correlation, that way...

"You worry too much" - Scott Dorsey.

--
Les Cargill

oldhead wrote:

Also remember that your final product's going to be 16 bits. You record
at 24 precisely because that *does* give you room to play.


Excuse me for being green, but . . .

Does this mean that if I use an interface capable of a 192kHz sample
rate, the quality of my final track will be determioned by the sample
rates of any plug-ins or DSP effects I use?



The things that you are doing willingly *with* the
plugins will have a much greater impact than the
arithmetic overhead of the plugins themselves.

Unfortunately, I do not know that mixed sample
rates are a fact in any plugins. I know that the
VST SDK publishes the sample rate via a method in
the SDK, and I figure the coders have to make their
own choices. I do not use a DAW that allows mixed
sample rates; if I had one, I would not trust it
to do that correctly without considerable evidence.

There is only amplitude and time in plugins. Any phase
or frequency information is inferred by integration of
the current sample with the context of the samples that came
before. All those transforms pretty much have sample rate
as a "furniture" variable - a manifest constant, if you
will. A "#define".

I see no reason that a plugin with a lower sample rate should
work any less well than one with a higher sample rate - indeed,
it should just require smaller buffers. That really
depends on how much data the transforms need to be well behaved.
SFAIK, that ain't muc for most. Delay/amplitude transforms,
which include compression, echo and reverb require no context
beyond things like the time constants. EQ? That's a filters
thing, and I'm not qualified. I don't think an FFT filter
costs that much preload-data. And the sample rate would cancel out
with the time constants fo the filter, anyway...

I wish there was a published, well vetted metric of operational
quality for plugins, but there ain't. That's too bad...

--
Les Cargill