[1] Processing in a higher sample/bit rate format helps to (a) minimize aliasing, (b) quantization noise, rounding-off errors, (c) phase misalignment issues, etc.
[2] The more data points an algorithm has to work with, the more precise and accurate the result of calculation will be.
[2a] That's why high-quality plugins offer oversampling options to increase the accuracy of processing. [2b] And that's why DAW process signals at higher sample and bit rates. They need more resolution to achieve their best.
[3] Processing audio means running thousands of mathematical calculations. Where the results of one calculation depend on the results of a previous calculation.
A higher sample/bit rate is like having a calculator with more figures after the decimal point. The more figures there are after the decimal point, the less the rounding off error is. And if there are thousands of math calculations to do, these rounding off errors add to each other, resulting in a less precise result.
Consider this:
If a calculator (A) has only two figures after the decimal point, it cannot multiply 1.25343 x 1.54789 as precisely as a calculator (B) with four figures after the decimal point:
Reality: 1.25343 x 1.54789 = 1.9401717627
Calculator A: 1.25 x 1.55 = 1.94 (the rounding-off error is 1.9401717627 - 1.94 = 0.0001717627)
Calculator B: 1.2534 x 1.5479 = 1,9401 ((the rounding-off error is 1.9401717627 - 1.9401 = 0,0000717627.
The rounding-off error of calculator A is 2.5 times more than the rounding-off error of calculator B.
The more math operations we do, the more we deviate from the precise result, because rounding-off errors multiply.
Now imagine doing thousands of such operations in one plugin, then passing the result to another plugin which runs thousands of other math calculations.
How about a chain of 5-6 plugins?
[4] That's why I prefer to upsample the signal to as high format as my DAC would accept. (44/16 > 176/24).
[5] Please refer to Chapter 4 "Worldlengths and differ" (page 49).
Also, Chapter 18 "High Sample Rates" (page 221).
1a. Aliasing of what? There is nothing above 22.05kHz if you're feeding 16/44.1, upsampling does NOT magically recreate those frequencies ALREADY removed above the Nyquist point. Same with bit depth: If we've got a 16bit file and convert it to 24bits it does NOT magically generate data for those extra 8 bits, all it does is fill/pad those 8 bits with zeros!
1b. The quantisation/round-off error is ALWAYS in the LSB of the plugin format, which is 64bit float in many cases, 32bit float in others.
1c. Sample rate has nothing to do with phase.
2. That's of course nonsense! How does 1.25343 x 1.54789 give a less accurate result than 1.2534300000000 x 1.54789?
2a. Due to the above, your assertion obviously has nothing to do with why plugins upsample! There are 3 potential reasons plugins upsample: 1. The plugin is using some non-linear process which generates content above 22.05kHz, typically something like an analogue modelled compressor will do this to generate IMD in the audible band. 2. It might be more practical for a plugin to operate at a single sample rate and up/down sample it's input to match, some convolution reverbs do this for example. 3. It could be purely marketing, to fool newbs who are gullible enough to believe that a higher sample rate must be better because it's a bigger number!
2b. DAWs do not operate at a higher sample rate! If you record in 44.1kHz, they operate at 44.1kHz. Their internal mix environment is commonly 64bit float, some are 32bit float or in some older DAWs it's 48bit fixed.
3. All of this is irrelevant nonsense!! Let's take your 1.24343 as our 16bit value, let's convert it to 24bit, so now we have something like 1.2434300000000. What happens if we were to feed those two values into a 64bit plugin? Our 16bit value gets padded with a whole bunch of zeros to create a 64bit word so that our 64bit plugin can actually process it, so now we have:
1.253430000000000... On the other hand, our 24bit word gets padded with a whole bunch of zeros to create a 64bit word so that our 64bit plugin can actually process it, so now we have:
1.253430000000000... In both cases we've got 1.25343 followed by exactly the same number of zeros, so WHAT'S THE DIFFERENCE??
The result of all the internal calculations of the plugin is also a 64bit float (because it's a 64bit plugin!). The quantisation error is in the LSB of that 64bit result (because it's a 64bit plugin!). The output of the plugin when it's finished all it calculations is also a 64bit float (because it's a 64bit plugin!), which either stays as a 64bit float if the data paths between plugins is 64bit or gets truncated to 32bit if that's the width of data path.
The difference between a 16bit word or a 16bit word padded to 24bits is LITERALLY zero (or 8 zeros if you want to be really precise about it) and once input into a 64bit plugin even the number of trailing zeros is the same!!! The only way your examples and statements would make any sense would be if feeding a 16bit word to a 64bit plugin somehow magically changed all the plugin's internal coding/processing and turned it into a 16bit plugin, while feeding it a 24bit word magically turned it into a 24bit plugin. That's of course nonsense, all that happens is that those 16 or 24 bit words are padded with zeros to 64bit floats and that 64bit plugin is always a 64bit plugin!
4. What's your DAC go to do with it? You are talking about the precision of plugin processing not whether or not your DAC is incompetently designed, which is a completely different issue!
5. Ah, it seems like the suggestion in my previous post was incorrect. Instead, try a book which explains the very basics of digital first, and then you might correctly understand what's in Bob's book!
G
Last edited: