To crossfeed or not to crossfeed? That is the question...

[ironmine]

I'm NOT implying that up/down sampling is always harmless

I am sorry, but you implied it when you wrote (let me quote you):

"those few [plugins] which do [benefit from a higher sample rate] now simply up/down sample where necessary".
"Your fear of up/down sampling ... is unwarranted."

Looks like, for you, whatever happens in a plugin, including upsampling/downsampling, is harmless/beneficial. But when I propose to do the same upsampling outside plugins, you are against it. Why such prejudice?

you haven't explained why adding trailing zeros one step early "improves accuracy"

I already told you. It's not me who "adds zeros". It's the upsampler which increases the bitrate from 16 to 32 in the process of upsampling. Look - you take 44/16 and feed it to the 32-bit upsampler and choose to upsample the signal x2 and, presto, you end up with 88/32 on your hands. That's simple. Going from 16-bit to 32-bit is the natural result of upsampling in the dBpoweramp/SSRC upsampler. What do you expect me to do? Truncate the upsampled signal back to 16-bit? It's not reasonable to do so, because now these extra bits are not zeros any more, they contain useful info.

or how doubling the data and bandwidth, where no frequencies exist, "improves accuracy".

The sample rate is doubled not for the purpose of recreating frequencies which don't exist. You know it perfectly well. Let me quote you:

"Those plugins which do legitimately upsample would do so at x2 (either 88.2 or 96kHz) as any theoretical benefits of filters and any non-linear processes are perfectly addressed by those sample rates" and "I sometimes used to run sessions at 96kHz as many plugins operated audibly better at that rate, many/most soft-synths, compressors, some EQs and various others."

The sample rate is doubled to improve the precision and accuracy of computations and to sound, in your words, "audibly better".

Why don't you ask plugin makers why they oversample inside their plugins? Don't these naive fools know that "there are no frequencies"?

Until you do, there is no basis for your advice to others!

No. Until you prove (to me and also to Bob Katz and to Aleskey Vaneyev) that re-sampling up and down, up and down, many times, when the audio data are transmitted from one plugin to another, is better than upsampling it once before entering a chain of vst-plugins, you should refrain from discouraging users to use the dBpoweramp/SSRC upsampler in Foobar.

However, you cannot make that assumption! Those plugins which do legitimately upsample would do so at x2 (either 88.2 or 96kHz) as any theoretical benefits of filters and any non-linear processes are perfectly addressed by those sample rates

Ok! Let's suppose plugins oversample x2. I mean, if the signal 88 or 96 or higher (176 or 192), they just operate at these rates. But if the incoming signal is 44 or 48, then they oversample by 2.

This is what happens if you follow my advice and upsample in Foobar prior to feeding the signal to a vst-host (Foobar is 32bit and vst-host is also 32bit):

And this is how it looks if I follow your advice:

 

[gregorio]

[1] Looks like, for you, whatever happens in a plugin, including upsampling/downsampling, is harmless/beneficial. [2] But when I propose to do the same upsampling outside plugins, you are against it. Why such prejudice?

1. No, it is not harmless but it is/should be inaudible!
2. Why do it when it's unnecessary? Increasing sample rate just for the sake of increasing sample rate does not improve accuracy/precision, if anything it decreases accuracy!

I already told you. It's not me who "adds zeros". It's the upsampler which increases the bitrate from 16 to 32 in the process of upsampling.

Huh? Who is it who is inserting the upsampler? I've already covered bit depth and explained why there is absolutely no point in adding this additional process to your chain!

The sample rate is doubled to improve the precision and accuracy of computations and to sound, in your words, "audibly better".

No, doubling the sample rate does NOT improve precision or accuracy. You are either not reading what I'm posting, not understanding it or deliberately misrepresenting it, which is it? I said that many years ago there were numerous plugins which sounded "audibly better" at higher sample rates. How many plugins are you and others using which have not been updated in a decade? I also stated that there are very few plugins which benefit from upsampling and those which do, upsample for specific reasons, NOT because of computational precision or accuracy! For the third time (!), those few plugins which perform non-linear processes AND create frequencies above 22.05kHz, such as a modelled analog compressor which creates IMD as part of that modelling process. Such plugins will therefore up/down sample internally to temporarily increase frequency bandwidth, it has nothing to do with your supposed increase in accuracy/precision!

[1] Why don't you ask plugin makers why they oversample inside their plugins? Don't these naive fools know that "there are no frequencies"?

1. Duh, I have, how do you think I know what I'm stating, you think maybe I'm just making it all up because I have some irrational hatred of upsamplers? I've spoken with some of the very best, most respected developers in the business and in fact some of the same people from whom Bob Katz gets his information. AGAIN, I did NOT disagree with what Bob wrote, WHEN he wrote it. I disagree that what he said 15 years ago is still applicable today and I would think he does too! AGAIN, how many plugins do you use which have not been updated in a decade or so?

2. These "naive fools" you're talking about have shaped the industry. I think it's clear who the "naive fool" is here!

For everyone else: You do not need an upsampler as part of your plugin chain. Very few plugins benefit from upsampling and those that do, will do it themselves, if necessary. If you have some burning desire to insert a dedicated upsampler then by all means do so but you are costing yourself double or quadruple the processing resources for absolutely no benefit. If, by some chance, you do detect an actual audible benefit from inserting a dedicated upsampler, then examine your processing chain, you are using an incompetently coded/designed plugin. Generally, I wouldn't need to state that last sentence but I'm aware some audiophiles use free plugins and while there are some excellent developers whose business model allows for high quality plugins which are free, this isn't always the case and there's certainly some shoddy/inexperienced/poor plugin developers out there. And of course, just because a plugin is not free isn't an absolute guarantee that it's competently coded/designed.

G

 

[castleofargh]

I am sorry, but you implied it when you wrote (let me quote you):

"those few [plugins] which do [benefit from a higher sample rate] now simply up/down sample where necessary".
"Your fear of up/down sampling ... is unwarranted."

Looks like, for you, whatever happens in a plugin, including upsampling/downsampling, is harmless/beneficial. But when I propose to do the same upsampling outside plugins, you are against it. Why such prejudice?



I already told you. It's not me who "adds zeros". It's the upsampler which increases the bitrate from 16 to 32 in the process of upsampling. Look - you take 44/16 and feed it to the 32-bit upsampler and choose to upsample the signal x2 and, presto, you end up with 88/32 on your hands. That's simple. Going from 16-bit to 32-bit is the natural result of upsampling in the dBpoweramp/SSRC upsampler. What do you expect me to do? Truncate the upsampled signal back to 16-bit? It's not reasonable to do so, because now these extra bits are not zeros any more, they contain useful info.



The sample rate is doubled not for the purpose of recreating frequencies which don't exist. You know it perfectly well. Let me quote you:

"Those plugins which do legitimately upsample would do so at x2 (either 88.2 or 96kHz) as any theoretical benefits of filters and any non-linear processes are perfectly addressed by those sample rates" and "I sometimes used to run sessions at 96kHz as many plugins operated audibly better at that rate, many/most soft-synths, compressors, some EQs and various others."

The sample rate is doubled to improve the precision and accuracy of computations and to sound, in your words, "audibly better".

Why don't you ask plugin makers why they oversample inside their plugins? Don't these naive fools know that "there are no frequencies"?



No. Until you prove (to me and also to Bob Katz and to Aleskey Vaneyev) that re-sampling up and down, up and down, many times, when the audio data are transmitted from one plugin to another, is better than upsampling it once before entering a chain of vst-plugins, you should refrain from discouraging users to use the dBpoweramp/SSRC upsampler in Foobar.



Ok! Let's suppose plugins oversample x2. I mean, if the signal 88 or 96 or higher (176 or 192), they just operate at these rates. But if the incoming signal is 44 or 48, then they oversample by 2.

This is what happens if you follow my advice and upsample in Foobar prior to feeding the signal to a vst-host (Foobar is 32bit and vst-host is also 32bit):

And this is how it looks if I follow your advice:

to be clear for others, the 2 examples are manufactured! and the red annotations about how something will stay as is or be upsampled X2 are either written without actual evidence that it happens(and it most likely doesn't), or does happen that way because again the settings of the VSTs when available were set to upsample X2. kind of like proving something happens by forcing it to happen with settings nobody would use otherwise.
if I was to know for a fact that most of the VSTs I use work at a known and identical sample rate, I would just set the VST host at that sample rate and be done with it(if the DAC happens to handle that sample rate). and if some VSTs allow me to pick the internal sample rate myself, and no other consideration came along at all (CPU usage or whatever convolution stuff that could require to follow the rate of the impulse), then obviously I would also try to set them to have the same sample rate, or maybe a higher one if I knew it somehow mattered for one of those VSTs in particular.
so we simplify things when possible and when there is no other reason to do something else. which is a little different from assuming that starting the VST chain with oversampling is always better. the proper answer to pre oversampling or not is likely to be: "it depends".

as for bit depth, indeed almost everything works at least at 32bit. until whatever we have set at the output for the DAC. I believe everybody now agrees on at least that much.

 

[ironmine]

Gregorio,

I want to come back to your previous post:

You appear to be confusing two different things here: Anti-alias and anti-imaging filters. To comply with Nyquist, we have to remove all freqs above the Nyquist Point to avoid aliasing. ... However, none of this is applicable in our case because what we're dealing with has already been anti-alias filtered and there is nothing above the 22.05kHz Nyquist Point of our 44.1/16 input file/signal!

Yes, the original 44/16 has been anti-alias filtered, but as we process audio with plugins, aliasing can be re-introduced into the signal again. For example, even an algorithm as simple as a limiter can result in aliasing. Just read this explanation from FabFilter:
https://www.fabfilter.com/help/pro-l/using/oversampling.html

"The limiting algorithm often needs to make very quick changes to the audio in order to remove peaks while preserving transparency and apparent volume. These sudden changes can introduce aliasing, which causes distortion and generally reduces the quality of the audio signal. Oversampling is a way to reduce that aliasing by running the internal limiting process at a higher sample rate that is a multiple of the host's sample rate."

FabFilter also recommends oversampling for its compressor and expander:
https://www.fabfilter.com/help/pro-c/using/oversampling
https://www.fabfilter.com/help/pro-mb/using/oversampling

And for its gating algorithm, too:
https://www.fabfilter.com/help/pro-g/using/oversampling

1. No, it [oversampling] is not harmless but it is/should be inaudible!

Well, it you do it once, may be in inaudible, but if you do it several times? As an audiophile, I passionately care about the quality of playback and I try not to do something that degrades the sound quality.

FabFilter also says that oversampling degrades the quality:

https://www.fabfilter.com/help/pro-l/using/oversampling.html:
"There are only two small drawbacks to oversampling: it increases CPU usage, and it can introduce a very slight pre-ring due to the phase-linear filtering that is needed. Generally this effect is so small that it's inaudible, but it's good to be aware of this and not blindly assume that oversampling is always better."

I don't care about CPU usage (my computer is powerful), but I do care about the effect of "slight pre-ringing due to the phase-linear filtering that is needed" as a result of oversampling. I don't want this effect of pre-ringing to be multiplied by many instances of oversampling occurring in different plugins. If oversampling has such a negative impact upon sound quality, I would like to do it only once, in the highest quality upsampler that I trust, not many times in VST plugins, whose oversampling algorithm, I am sure, is not as advanced as a dedicated upsampler. VST try to boast as low latency as possible, but high-quality oversampling works against it. But I don't care about latency while simply listening to music.

You can see here http://src.infinitewave.ca/ that even costly software products often struggle to re-sample with high-quality. So, what to expect from VST plugins? Mediocre results due to crude interpolation methods, I would not be surprised.

Oversampling results can differ very much depending on how much effort you input into interpolating the missing samples:

http://lavryengineering.com/pdfs/lavry-sampling-oversampling-imaging-aliasing.pdf

 

[ironmine]

. For everyone else: You do not need an upsampler as part of your plugin chain.

Yeah, very "valuable" advice from the guy who still runs his sessions, as you confessed, at 44 or 48 kHz!
Much good it will do us...

.
Very few plugins benefit from upsampling and those that do, will do it themselves, if necessary.

You conveniently do not mention the fact that not only these plugins will upsample if necessary, but they will inevitable downsample the data before they can pass it to the next plugin in the vst-chain. If the VST-host operates at 44, a plugin cannot pass the data to the next plugin at 88 or 176.

 

[gregorio]

to be clear for others, the 2 examples are manufactured! and the red annotations about how something will stay as is or be upsampled X2 are either written without actual evidence that it happens(and it most likely doesn't), or does happen that way because again the settings of the VSTs when available were set to upsample X2.

In actual fact, his example plugin chain is not just a manufactured example, it's completely made-up nonsense! The RX De-Clip has a built-in True Peak limiter and is therefore running internally at a sample rate of at least 192kHz. So, he's upsampled (with a plugin omitted from his diagram!) to 88.2kHz and then the De-Clip upsamples it again. If he'd just fed the RX De-Clip 44.1kHz to start with, there would have been fewer upsampling steps/filters applied! The signal exits this De-clip module and is sent to FabFilter Pro Q2 (an EQ plugin). EQ does not benefit from oversampling, the Q2 therefore does not oversample and has no setting to force it to oversample! After the Q2, the signal goes to a mic-preamp emulator. I'm not sure why anyone would want to put a mic-preamp plugin on a final mix but that's a matter of choice I suppose; as this is a non-linear analogue modelling type plugin it could theoretically benefit from upsampling, depending on exactly what non-linear processing it's doing and how it's doing it. Whether it does actually upsample or not I don't know and if it does upsample then it might well do so at a fixed rate, say 96kHz. There's a fair/good chance it does not upsample though, because as a mic-preamp plugin it's designed to be used on every input channel and upsampling could result in unacceptable CPU usage in such circumstances. Then on to an algorithmic reverb, which definitely does not benefit from oversampling, in fact even 44.1kHz is higher than necessary and to reduce processing overhead some algorithmic reverbs downsample and then operate internally at a 32kHz sample rate! I'm not sure if any current plugin algorithmic reverbs actually do this any more but for certain, if this plugin even has an oversampling option it's purely a gimmick/marketing exercise and should be avoided. The Redline Monitor is a basic headphone crossfeeder which again would not benefit from a higher sample rate.

Clearly, ironmine's examples/annotations could not be manufactured even if you wanted to, he's just made it up! The RX De-Clip is not upsampling x2, more like about x4.3 or higher. The Q2 does not and cannot be forced to upsample. We don't know if the pre-amp plug upsamples and if it does, to what sample rate, etc. Even in his own cherry-picked processing chain example, initially upsampling to 88.2kHz is likely to be more detrimental than just feeding the original 44.1kHz! However, it's very unlikely in practise this inferior result would be audibly inferior.

Again, for everyone else: Do not insert an upsampling plugin, just feed your chain what you've got (say 44.1kHz) and let your plugins up/down sample when/IF they need to. I suppose an exception could be: If you are certain that ALL the plugins in your chain are operating at exactly x2 oversampling AND that they are doing so for legitimate reasons. Then sure, insert an upsampling plugin BUT rarely, if ever, can you be certain of both of these conditions, as so ably (and inadvertently!) demonstrated by ironmine! Therefore, the most likely outcome is that you will be significantly increasing your processing overhead in exchange for (theoretically) reducing audio quality!

For example, even an algorithm as simple as a limiter can result in aliasing. Just read this explanation from FabFilter: ...

AGAIN, you appear to be quoting something you either have not understood or are deliberately misrepresenting, which is it???

1. I specifically already mentioned the need for oversampling with a true-peak limiter AND
2. This is what FabFilter actually state in the article to which you linked: "We recommend 4x or possibly 8x oversampling for normal use as this will already drastically reduce aliasing and not cause extreme CPU usage. The 16x and 32x options may result in even higher audio quality, but for most systems this is simply too taxing to run in real-time especially if there are also other plug-ins in the session.". So, what benefit is there to upsampling x2 to 88.2kHz (and introducing a filter), just for the plugin to upsample again at an even higher rate, add another filter and then downsample back to 88.2??? You'd be better off just feeding the plugin the original 44.1kHz to start with!

[1] Yeah, very "valuable" advice from the guy who still runs his sessions, as you confessed, at 44 or 48 kHz!
[2] You conveniently do not mention the fact that not only these plugins will upsample if necessary, but they will inevitable downsample the data before they can pass it to the next plugin in the vst-chain.

1. You are AGAIN either NOT reading or DELIBERATELY misrepresenting what's been stated! I am not "STILL" running my sessions at 44 or 48kHz. I already mentioned (and you have quoted!) that at one stage, for a number of years (starting around 1998), that I regularly ran sessions in 96kHz for audio quality reasons but that I have since stopped that practise and RETURNED to 44 or 48, as there are no longer any audible benefits.
2. Another lie/misrepresentation, I have consistently stated that in the given circumstances plugins up/down sample, NOT ONLY upsample!

You obviously have a strong (though erroneous) belief in upsampling, which you've arrived at through the marketing hype that higher sample rates must be better and then supported that belief with outdated information, a typical audiophile trap. I don't object to this, in fact, this is one of the main reasons this forum exists, to present/discuss relevant information and facts, to separate out what is just marketing hype and help to avoid the audiophile traps. However, you've now progressed beyond just presenting/discussing the facts and are trying to defend your belief by simply making-up nonsense facts and deliberately misrepresenting others, that is NOT acceptable in this sub-forum!!

G

 

[ironmine]

I did not actually say that I know for sure that those specific plugins which I showed in the above screenshots oversample or don't. I cannot know that. I showed that chain to illustrate my thought (scenario) only. I don't claim any knowledge about how much they oversample, either (if they do). But you seem to be so confident, you pretend that you know exactly what happens, for example, inside the RX De-Clip. Ok, let's check whether you lied or not when you said that you know that RX De-Clip operates at 192 kHz:

In actual fact, his example plugin chain is not just a manufactured example, it's completely made-up nonsense! The RX De-Clip has a built-in True Peak limiter and is therefore running internally at a sample rate of at least 192kHz.

I converted a flac file in Foobar losslessly to another flac file. In the process of conversion, I applied the processing in the form of the RX De-Clip plug with its post-limiter activated . This VST plugin found 0 (zero) clips (because the file's peak was at -1.5 dB and the the RX De-Clip threshold was set to - 1 dB). The quality level was set to High. Then I bit-compared these two flac files in Foobar. Foobar checked them and reported that they are bit-identical except a small offset. It means that the RX De-Clip does not upsample/downsample. If it did, the files would not be identical.

So, why did you say that you know the RX De-Clip upsamples? It does not.

So, he's upsampled (with a plugin omitted from his diagram!) to 88.2kHz

What? I did not omit the plugin. I showed it in the list of Active DSPs in Foobar. Don't you see dBpoweramp/SSRC in my screenshot? it's the first in the list.

For your information, unlike Foobar components, VST-plugins inside a VST-host cannot be upsamplers. I mean, they can upsample/downsample internally only, but they cannot upsample and pass these upsampled data to the next plugin. So your remark is funny. You just revealed inadvertently your ignorance about how VST-hosts work.

 

[gregorio]

But you seem to be so confident, you pretend that you know exactly what happens, for example, inside the RX De-Clip. Ok, let's check whether you lied or not when you said that you know that RX De-Clip operates at 192 kHz ...So, why did you say that you know the RX De-Clip upsamples? It does not.

Yes it does and it MUST! You obviously don't know what True Peak means or how it's measured and defined. The ITU defines a TP measurement as at least a x4 oversampling process based on a 48kHz sample rate, although Izotope's own dedicated TP meter/loudness plugin oversamples x9, it's entirely likely that it's De-Clip plugin does too. So, I don't know DeClip is operating at 192kHz, it could be operating far higher but it's certainly not working at 44.1 or 88.2!!

G

 

[castleofargh]

I was wondering about a few of those points. obviously anything about clipping check that wouldn't oversample is silly. but maybe the scan could be done on oversampled signal and then only apply some gain or compression or whatever the VST does in a separate signal stream using the original signal instead of the oversampled one used for the scan?

as for VST host, I checked on another one just now in case my assumptions were limited to the one I know best. and as I thought, the oversampling/downsampling when done, seems internal to each plugin. they all output whatever I set the VST host to use and can't seem able to communicate another sample rate to the next VST in the chain. I was on 48khz in the VST host settings and that's what I was reading out of each plugin.
on the other hand, I can reduce bit depth and read the new bit depth at the output of the plugin reducing it. but then the next plugin will typically turn it back to 32bit. not super interesting.
maybe more professional VST hosts, or at least DAWs offer a little more versatility/coherence by letting a sample rate out of a vst and into the next even if it's not the default setting for the workspace? IDK.

 

[Zapp_Fan]

I was wondering about a few of those points. obviously anything about clipping check that wouldn't oversample is silly. but maybe the scan could be done on oversampled signal and then only apply some gain or compression or whatever the VST does in a separate signal stream using the original signal instead of the oversampled one used for the scan?

as for VST host, I checked on another one just now in case my assumptions were limited to the one I know best. and as I thought, the oversampling/downsampling when done, seems internal to each plugin. they all output whatever I set the VST host to use and can't seem able to communicate another sample rate to the next VST in the chain. I was on 48khz in the VST host settings and that's what I was reading out of each plugin.
on the other hand, I can reduce bit depth and read the new bit depth at the output of the plugin reducing it. but then the next plugin will typically turn it back to 32bit. not super interesting.
maybe more professional VST hosts, or at least DAWs offer a little more versatility/coherence by letting a sample rate out of a vst and into the next even if it's not the default setting for the workspace? IDK.

My GUESS is they force to project/systemwide sample rate because some (most?) DAWs have wet/dry controls for each insert effect. If each VST didn't output the same sample rate, you'd have to mix two or more sample rates together, without resampling, I don't see how you can pass a mix of 44 and 192 to single input further down the chain. However, I am not super-clever with software tricks, so it might be possible? Would be a question for the devs.

 

[ironmine]

Yes it does and it MUST! You obviously don't know what True Peak means or how it's measured and defined. The ITU defines a TP measurement as at least a x4 oversampling process based on a 48kHz sample rate, although Izotope's own dedicated TP meter/loudness plugin oversamples x9, it's entirely likely that it's De-Clip plugin does too. So, I don't know DeClip is operating at 192kHz, it could be operating far higher but it's certainly not working at 44.1 or 88.2!!

G

Well, then you have to explain how the original flac file and the same flac file that has been put through the De-Clip plugin ended up being bit-identical. Is Castle of Fargh's assumption correct?

as for VST host, I checked on another one just now in case my assumptions were limited to the one I know best. and as I thought, the oversampling/downsampling when done, seems internal to each plugin. they all output whatever I set the VST host to use and can't seem able to communicate another sample rate to the next VST in the chain. I was on 48khz in the VST host settings and that's what I was reading out of each plugin.

My GUESS is they force to project/systemwide sample rate because some (most?) DAWs have wet/dry controls for each insert effect. If each VST didn't output the same sample rate, you'd have to mix two or more sample rates together, without resampling, I don't see how you can pass a mix of 44 and 192 to single input further down the chain. However, I am not super-clever with software tricks, so it might be possible? Would be a question for the devs.

Yes, this is what I mean. Otherwise, the VST-chains such as I built below would not be technically possible.
(Please don't jump at me if the logic of this specific VST chain does not make sense, I just show it as an illustration to my thoughts):

I inserted two instances of the same plugin. One of them emulates 12AX7 and oversamples x2. The other one emulates 12AU7 and does not oversample. The outputs of these two plugins are summed at the input to the next plugin (Redline Monitor).

So, I am sure that each plugin in the VST chain, regardless how it resampled internally, at its output must release the data at the sample rate that the VST host is running at.

Here's a similar discussion: "Oversampling vs. Increased Sample Rate". I started reading it.
And this one too.

 

[WoodyLuvr]

Could we discuss the how/why of the slider on Case's Meier Crossfeed DSP? E.g. explain the scale 0-100; what settings best for certain genre; etc.

 

[gregorio]

[1] I was wondering about a few of those points. obviously anything about clipping check that wouldn't oversample is silly. but maybe the scan could be done on oversampled signal and then only apply some gain or compression or whatever the VST does in a separate signal stream using the original signal instead of the oversampled one used for the scan?
[2] as for VST host, I checked on another one just now in case my assumptions were limited to the one I know best. and as I thought, the oversampling/downsampling when done, seems internal to each plugin. they all output whatever I set the VST host to use and can't seem able to communicate another sample rate to the next VST in the chain.

1. What RX DeCip is doing is taking a signal which has been clipped, the waveform peaks literally cut off by being slammed into the 0dBFS limit (for example) and then reconstructing those waveform peaks to what would have been if there were no 0dBFS limit. It uses floating point math to do this because while in the digital domain there is no 0dBFS limit (in effect the limit with 32bit float is about +1,520 dBFS). I am presuming that you would need some degree of oversampling to achieve this reconstruction task, to make the thing work well you'd almost certainly need to calculate the inter-sample peaks (ISPs). Once this De-Clipping process is complete, you'd typically have an illegal but recoverable result (sample peaks above 0dBFS), so included in the plugin is a True Peak Limiter, also of course operating at 32bit float, to take those peaks back into the legal range and provide a dynamic range roughly equivalent to the input signal but without any clipping distortion (even from ISPs), hence why the TP limiter rather than just a standard sample peak limiter. This TP Limiter absolutely must operate at very high sample rates (at least x4 oversampling) because it is specifically processing the ISPs to give a True Peak result. If it were not oversampling there would be no detectable or processable ISPs and it could only operate as a sample peak limiter NOT a TP limiter. In other words, it's operating on ISPs at an oversampling rate which defines it as a True Peak limiter in the first place. And, as mentioned previously, True Peak is defined by the ITU as; at least x4 oversampling and Izotope's TP detection/reporting in it's dedicated metering plugin is done at x9 oversampling, so it's not unreasonable to assume it's DeClip plug is too, otherwise the TP level achieved in it's DeClip plugin would not agree with the TP level reported by "Insight" (Izotope's dedicated metering plugin). Izotope is, AFAIK, the only plugin manufacturer which uses this x9 oversampling for it's TP reporting, most do x8, some only do the required minimum and some provide the option to choose from x4 all the way up to x32.

I just happen to know a fair bit about Izotope RX suite of plugins because I use it frequently and have done since RX 2 Advanced was released about 7 years ago and I'm now on RX 6 Advanced. I've also had correspondence with Alexey Lukin, the head of DSP coding for Izotope. Unlike most programmers for the big manufacturers, Alexey is quite open, most either don't want to talk about it or are legally constrained from doing so. However, "quite open" is a relative term, Alexey is willing to discuss general DSP principles in depth and go into *some* detail about what the Izotope plugins are doing under the hood but there's ALWAYS a limit. On the one hand he wants to satisfy pro-user's desire to know what's actually going on and on the other hand, he doesn't want to give any clues which might help competitors or potential competitors achieve similar performance more cheaply. It's conceivable that the DeClip plugin actually operates at two different sample rates. For example, x2 oversampling for the DeClipping and then x4 (or higher) for the TP limiting section. In this case though, I would expect it to always oversample x2 in the DeClip section, IE. Feed it 44.1 and the Declip section would oversample to 88.2, Feed it 88.2 and it would oversample to 176.4. I think it's moderately unlikely it's using two different sample rates though and I think it's at least moderately unlikely Alexey would say if asked.

2. I'm not an expert or even particularly well informed about VST hosts but the basic principles of digital audio processing environments are much the same across the board. I don't know of any hosts or DAW environments which allow output from a plugin at a sample rate or bit depth different to the environment. A plugin is an independent DSP program which can do pretty much anything it wants but is constrained to interfacing it's input and output with the host environment. The host environment doesn't know or care what the plugin is doing, as long as it gets what it expects in terms of format and whatever other stipulations the original host environment owners/controllers demand. So internal bit depths and sample rates can be anything the plugin developer wants as long as it can handle the data the host environment gives it and return it's processed data in the format the environment expects. In practise, what actually going on is all over the place and always has been. Software environments which allowed 3rd party plugins started really taking off about 20 years ago with Pro Tools TDM. Within a couple of years TDM's release we started seeing "double precision" plugins, plugins operating internally at 48bit fixed but outputting to the environment's 24bit requirement and by about 2002 plugins which benefited from this double bit depth accounted for a significant number of the most used plugins, often without the operator (engineer) knowing anything about it. So already, by 15 years ago we had the situation where the bit depth was all over the place, 24bit for recording, 8, 24 or 48bit for processing, back to 24bit again, then to the internal TDM summing mixer operating at 56bit, and finally recorded ("bounced down") at 24bit or 16bit. Today the situation is basically the same, although with different bit depths, still 24bit for recording, 32bit float data paths, 64bit internal plugin processing, back to 32bit float, then summed at 64bit and finally bounced down in 24bit or 16bit. The situation of plugin internal sample rates was more static for longer, as there's very significantly more processing overhead with higher sample rates relative to the processing overhead of doubling the bit depth (to say 64bit, as modern CPUs have an architecture designed and optimised for 64bit word lengths). So it wasn't until about 2005 that I recall starting to see plugins internally up/down sample, they simply operated at the session sample rate, and it took several years more before it was common. By about 2009 or so, the only time I needed to run a session at 88.2 or 96kHz to force a plugin to operate at an audibly superior sample rate was for a small number of soft-synths, nearly all the other plugins up/down sampled internally when required with no audible benefit to feeding them a native 88.2 or 96kHz.

Well, then you have to explain how the original flac file and the same flac file that has been put through the De-Clip plugin ended up being bit-identical. Is Castle of Fargh's assumption correct?

Castleofargh's assumption about the fixed environment sample rate is correct, AFAIK. I can think of 3 or 4 potential explanations off the top my head for your observation. However, none of them are that RX DeClip is not oversampling, because that is an impossibility by definition of a True Peak limiter!

G

 

[ironmine]

Could we discuss the how/why of the slider on Case's Meier Crossfeed DSP? E.g. explain the scale 0-100; what settings best for certain genre; etc.

I don't think one can find a setting in Meier that would sound best with all albums. As you move the slider more and more to the right, it will take out more and more "buzzing bees" out of your ears and your perception of the music coming from the sides will improve, but at the cost of losing details in the center. It's a trade-off.

 

[WoodyLuvr]

I don't think one can find a setting in Meier that would sound best with all albums. As you move the slider more and more to the right, it will take out more and more "buzzing bees" out of your ears and your perception of the music coming from the sides will improve, but at the cost of losing details in the center. It's a trade-off.

Thank you for the explanation. Between you and @Strangelove424 I have a better idea what to listen for when I am adjusting the slider. Any other helpful listening cues would be most appreciated