Goddard
RMS measurement won't reveal peaks. And as already said, Sound Forge's RMS measurement (at least in SF 8.0 as was used for the differencing results reported in that old thread) was known to be rather buggy and unreliable:
Notable fixes/changes in version 9.0a
...
A bug has been fixed that caused the Statistics tool to report inaccurate RMS levels has been fixed.
http://dspcdn.sonycreativesoftware.com/releasenotes/soundforge90e_readme_enu.htm
Perhaps you missed that I posted the peak errors as well (SF lists them as Minimum and Maximum - there are two, because both the positive and negative peaks are posted):
32bit vs. 64bit (no FX):
Left Channel Right Channel
Minimum sample value (dB) -138.739 -136.175
Maximum sample value (dB) -138.943 -138.192
RMS level (dB) -164.395 -164.148
I used SF 9.0c, so the RMS values had been fixed.
Btw, in that same thread, the OP had reported a further test here:
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611251
Yes, and his result was a 1dB
lower error level.
and also, Ron K had previewed the AES presentation he was then about to give:
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#611393
The verdict is that using 32-bit floats to mix 24-bit data introduces at most 6dB of error more than 25% of the time.
Are you asserting that "at most 6dB" is a problem?
Ok, but while Sonar may not have any control over what/how (i.e., with what precision) a plug-in may process things internally, it does control what the plug-in processes, namely, whether the plug-in receives/returns a single precision fp stream or a double precision fp stream from/to the audio engine. That is, whether or not Sonar's DPE is enabled can influence the precision of the sample stream supplied by Sonar's audio engine as the input (i.e., "operand") to the plug-in for processing and also the precision at which the processed output stream is returned to Sonar's audio engine by the plug-in.
This is a bad argument, as it only applies in borderline cases that don't exist in the real world. If the errors from using Sonar's single precision mix engine are
far from audible (as they are), you need to do huge amounts of additional processing using 32bit single precision to get audible errors. But the audible errors are then not really from the mix engine, but from the additional processing. It's an argument that the additional processing should be done with more precision.
Do you understand how to calculate the effect of adding, say, a -140dB RMS error to a -120dB RMS error? If not, we can go through it, but the increase in error level of adding something 20dB lower is much less than many people might think. Basically, if you have two similar sources of error, you can completely ignore the lower level one if it's far enough below the higher level one.
But whether or not the DPE is enabled in Sonar can determine what the recursive DSP FX processes.
What makes you think that that matters? The DSP adds additional errors to what it gets or it doesn't.
As already noted, those reported RMS readings were rather liable to be unreliable. And in any case, both Ron K and Justin Frankel confirmed that single precision fp summing rounding errors do make it into the 24-bit PCM output.
I've repeatedly said that some errors will indeed make it into the 24bit output. The point is that they aren't remotely audible.
drewfx1
Goddard
drewfx1
It depends. The lower the exponent is set, the higher the comparable resolution of floating point. It's only "equivalent" for samples that are near full scale. And if we consider that adding one bit doubles the resolution...
No it doesn't depend. 32-bit floating point and 24-bit fixed/integer are equivalent in resolution/precision:
http://www.bores.com/cour...tro/chips/6_precis.htm
From your link (sic):
Because the hardware automatically scales and normalises every number, the errors due to truncation and rounding depend on the size of the number. If we regard these errors as a source of quantisation noise, then the noise floor is modulated by the size of the signal.
Which once again confirms exactly what I said in the quote of mine that you are replying to here. When the MSB's in 24bit are zero (i.e. a lower signal level for a given sample), 32bit indeed has higher precision.
That's "scaling" (in the exponent), not precision (in the significand/mantissa). And in any case, sampled values constantly vary (unlike e.g. filter coefficient values). Consider what occurs precision-wise in the significand when the sample value becomes so small/large that the exponent has to change.
No it's the same. An intrinsic property of floating point numbers is that the numbers have less/more precision compared to fixed point depending on the exponent.
For instance, in 24 bit fixed point if the 3 MSB's at the top are all zero (i.e. a lower signal level), you only have 21 bits of precision left for your actual data; in floating point the MSB is an implied value of 1 (except for subnormals), so you are always using every bit of precision (for all non-subnormal values) and the exponent scales it up or down. To put it another way, with fixed point the level of quantization error relative to the signal increases for lower level signals whereas with floating point it stays the same.
Anyway, such a discussion is only academic. The point of real practical interest here is that processing 24-bit PCM audio with single precision floats can lead to errors in the processed (summed) 24-bit PCM audio output of the audio engine which do not manifest when double precision is employed.
I would say that the "practical" point is not whether the errors exist, but whether they are audible. If the errors are present, but never audible I would call that academic.
drewfx1
How many times have I made the point that mixing doesn't cause this type of accumulation? You are of course welcome to prove otherwise. I've already shown the proof (which you keep questioning), but was confirmed by the null test you yourself linked to above.
Perhaps you missed this by Ron K in that same thread?:
That's 1 bit per multiply/summing stage. In other words, the more tracks and buses you have, the more these bit errors can accumulate and start to be come 2 bit errors, 4 bit errors, etc.
http://forum.cakewalk.com/White-Noise-32bit64bit-Engine-Test-m610884.aspx#614682
This is indeed true. But don't confuse peak errors with RMS, which much more closely represents what we hear. If you test, you will find that the RMS error increases far more slowly than the peak error levels.
And you also need to consider that the true peak is dependent on the sample level not dBFS - so you only get the maximum peak if you happen to be unlucky enough to have a maximum calculation error occur on a sample near that is near full scale. This is unbelievably rare in the real world, and becomes increasingly rare as you do more calculations.
And as noted earlier, I got a peak error of -136.175 dBFS in my tests (which became -138.474 dBFS when truncated to 24bits). But the dBFS peak value will vary much more from test to test than the RMS value for the reason I stated above - the errors are relative to the sample itself, not dBFS, so the peak dBFS error in any given test will depend on levels of the samples where you happened to get a peak calculation error.
drewfx1
I think you didn't understand. The RMS indeed nulls to infinity, but only when truncated to 24bit - because the result was less than the LSB of 24bit fixed point. It's exactly the same as an undithered recorded signal being cut off below the LSB. As I posted, it did not null to infinity before it was reduced to 24bit.
You are focusing on an unreliable RMS measurement.
As stated above, my RMS measurements were from a version of SF that had corrected that error.
And I find it very telling that you just
assume that my numbers must be wrong.
The poster there also reported that the normalized differences were audible.
Rounding error (bit loss) which occurs in (the significand of) the 32-bit fp number will still be present when that 32-bit fp number is converted to 24-bit integer/fixed. This was clearly shown in the reported 24-bit PCM output results of CW's testing for a simple gain alteration and summing operation, and also confirmed by Justin F's comparision test post. Converting to 24-bit won't make any difference, null-depth-wise, in the difference.
SF reports the numbers in the bit depth of the project. You can't represent a number below -144.494 dBFS in 24bit, so SF reports -infinity. The point is that the RMS error level is below the level of 24bit's LSB.
Note that I got an RMS error of -164.148 dBFS RMS before truncation. Since this indicates that an overwhelming number of errors are below -144.494 dBFS and will thus get truncated, you will get an
even lower RMS error level after truncation if we bother to calculate it and express it at a higher bit depth.
As noted above, it's already been done, back when. Didn't null completely. Was the difference audible? Hardly. But that's not really the point.
drewfx1
Um, that's been exactly my point all along - as I've repeatedly said, there are indeed errors some of which will make it into 24bit output. But they aren't audible.
And my point is that noise/distortion due to rounding error which manifests when mixing 24-bit audio using single precision even if not initially audible may become audible (or cause undesirable effects) when further downstream mixing or DSP is performed on the rounding error-bearing data.
As noted above, it will be downstream errors that are audible, not the ones from the mix engine.
How many low bits of a 24-bit PCM sample need to be lost (incorrect) before it's audible? How much gain is required before a low bit rounding error becomes audible?
Ignoring masking, if your playback level puts the errors at a level that is below your absolute threshold of hearing, they are obviously inaudible.
When we consider masking from background noise in the listening environment, analog circuit noise, dither, quantization noise, noise in the signal and the signal itself, they are much further from being audible.
If you do a null test and listen to the difference signal, you will find that you have to add many tens of dB's of gain to hear anything, even without your signal there to mask it.
I strongly suggest you do such a test to see for yourself.
Wrt certain types of digital filters (as might be employed in various DSP FX plug-ins such as EQ and multiband compressors), see e.g. "noise gain" here:
http://electronotes.netfirms.com/EN209.pdf
Some DSP FX such as dynamic processors or FX with sidechain inputs may normalize or otherwise raise the level of an input in order to derive an internal reference level. See e.g. (towards the bottom, at "Anyway what is the bottom line (finally)?"):
http://www.gearslutz.com/board/6016102-post259.html
I afraid I don't have time to read every link you post. I suggest that in the future you quote the relevant parts in addition to providing the links for people not inclined to follow every link.
Regardless, I fully understand and have repeatedly stated that higher precision is desirable/necessary for certain forms of processing involving thousands of calculations (or more), but this doesn't apply to the mix engine.
Changing the reference level in floating point doesn't make the errors any more of a problem (perhaps it adds a few additional calculations, but they have essentially no effect on the error level).
Perhaps we inhabit different "real worlds" then, dunno. You seemed to temper your position in the course of an earlier thread on this topic:
http://forum.cakewalk.com/More-questions-about-64bit-recording-m2444701.aspx
I'm not sure what you mean here. My positions have not changed since those posts.