Speedskater
Major Contributor
Would not this discussion have been more meaningful in 1983 than in 2023? Back than commercial digital technology (including ADC & DAC) was struggling to do 16x44.1.
True. But I see so much discussion of technical fine points here that I am surprised to see the dismal state of test tones people are using. They are frightening! What's funny is the ones claiming high quality are usually the worst. What good are 24-bit samples if they contain errors that are clearly visible in the spectrum?Yes, and that is great for number-crunching and theoretical analyses, but in the real world is far too limiting for frequency choice and means distortion and noise will be set by the ADC/DAC and analog signal chain, as always. That sets the practical spur floor irrespective of whether every point in the sine wave is rational or not.
Note an ideal N-bit converter has an actual spur floor (SFDR) of about 9N dB; the SNR set by quantization noise (and nothing else) is about 6.02N+1.76 dB.
Again, this is great for a theoretical analysis, getting mathematically "perfect", but in practice REW must operate on the input from a real-world ADC chain, and output through a real-world DAC, which will add noise and distortion of its own far surpassing the 53-bit level (for your IEEE FP example; some (many?) signal-processing programs use 64-bit integers internally so have more resolution).
Typo: the 53-bit (52 plus sign) IEEE 64-bit FP standard yields about 53*6.02+1.76 ~ 320 dB -- dB, not bits.
Your last point is key to me: this allows you to see the limitations of your digital processing chain. That can be very useful, but to use that DSP chain you're probably going to want to sweep more than just a few signals to look for things like filter overloads and limit cycles etc.
The point was that other means are used to generate a (broader) range of test signals that avoid spectral leakage. Again, the focus of most of the counter arguments (mine included) is on component and system testing, not just the bits inside the machine.
It is really cool to see the noise floor go to (essentially) 0 in the model or simulation! But of limited practical use, alas. Prime or relatively-prime signals are more useful for broader testing IME.
FWIWFM - Don
The other day I was reading a discussion of PCM for voice audio time division multiplexing. Bit depths of 7 or 8 were being considered. Not a bad choice, especially given it was written in 1948! So surely 16 bit samples are enough for any kind of audio. The point I am trying to make is that some of the discussion here assumes any well-known sine generator is good enough. That may be true for the real world hardware stuff being tested here. But as a software developer, it seems wrong that test tone files aren't bit perfect. So I am exaggerating to say the test tones in use here are horrible. But some, especially at bit depths of 32 and higher, have flaws that are visible in a spectrum view when analyzed directly and not passed through hardware. That doesn't make them unusable for the testing done here. But when validating a spectrum view, it's so annoying when the display is randomly bouncing around, or has more noise than expected.Would not this discussion have been more meaningful in 1983 than in 2023? Back than commercial digital technology (including ADC & DAC) was struggling to do 16x44.1.
Thanks for the screen shots. I already found a related wav file of yours, APx555 Multitone 32 192 khz 24 bit.wav. Do you have any sample wave files for single tones I could look at? Thanks.In case there is any doubt about sine generator in Audio Precision, here is a real life measurement of a device which outputs bit perfect:
IME this biggest offenders are the ones not following the relatively-prime conditions to make it better for testing. I do not know exactly what errors you are finding, but frequency choices causing spectral leakage is what I usually find, and that is often a numerical (FFT) problem rather than a real-world problem. Unfortunately the real world has all frequencies and does not insist on "nice" FFTs without windowing...True. But I see so much discussion of technical fine points here that I am surprised to see the dismal state of test tones people are using. They are frightening! What's funny is the ones claiming high quality are usually the worst. What good are 24-bit samples if they contain errors that are clearly visible in the spectrum?
Seems like a typo there... At 44.1 kS/s, 1000 Hz can have 22 tones (fundamental plus harmonics) and still meet Nyquist; 997 Hz still only gets you 22 tones (fundamental included) meeting Nyquist at 44.1 kS/s. There will be more terms (exceeding Nyquist) due to numerical roundoff and such but by that point they should be small and filtered before applying to an ADC or DAC.So now let's forget about this 3:1, 4:1, 6:1 special case business. Start with something simply, such as a 1000 Hz sine wave. 997 Hz is fine too. They are not really much different (at 44100, 1000 Hz has 220 harmonics and 997 Hz has 11025 harmonics). I chose 1000 Hz because I wanted to download and compare the type of test tones people here are using. I don't
Being an analog guy, I am sort of used to noise being noise and not always known and stable. Given there are no 32-bit audio DACs (at least none with anywhere near ideal 32-bit performance) I am not surprised you see spurs at that level (let alone 64-bit). And yeah probably plenty of test files not meeting standards or pushing the precision of the processors. It would be good to list the good ones; there are likely a lot of 16-bit'ish files around not suitable for higher-resolution DACs. But for audio, at the end of the day performance is probably going to be set by the HW and not the DSP's word size. I have had to argue more than once with a system guy who did not understand why ADCs and DACs did not scale with processors. For a software-defined radio one PM spec'd a 32-bit, 10 GS/s ADC, and I had to try to explain why there was no such thing. Not sure he was ever convinced, and continued to issue RFPs for one... I suspect I'll be long retired before he gets one. Not sure you can even get a clock source clean enough let alone all the other issues.The other day I was reading a discussion of PCM for voice audio time division multiplexing. Bit depths of 7 or 8 were being considered. Not a bad choice, especially given it was written in 1948! So surely 16 bit samples are enough for any kind of audio. The point I am trying to make is that some of the discussion here assumes any well-known sine generator is good enough. That may be true for the real world hardware stuff being tested here. But as a software developer, it seems wrong that test tone files aren't bit perfect. So I am exaggerating to say the test tones in use here are horrible. But some, especially at bit depths of 32 and higher, have flaws that are visible in a spectrum view when analyzed directly and not passed through hardware. That doesn't make them unusable for the testing done here. But when validating a spectrum view, it's so annoying when the display is randomly bouncing around, or has more noise than expected.
Harmonic Frequency Power angle
(0-524288) (Hz) (dB) (deg)
80 14.6484 -24.71874421 0.06159566
112 20.5078 -24.71874421 0.60781184
144 26.3672 -24.71874417 0.75861226
176 32.2266 -24.71874422 0.87396498
224 41.0156 -24.71874419 0.70443636
272 49.8047 -24.71874419 0.95871987
352 64.4531 -24.71874419 0.61743527
432 79.1016 -24.71874416 0.27648399
544 99.6094 -24.71874416 0.21705898
688 125.977 -24.71874417 0.12747603
880 161.133 -24.71874420 0.14058409
1088 199.219 -24.71874420 0.37903255
1360 249.023 -24.71874425 0.42272619
1728 316.406 -24.71874420 0.92870460
2192 401.367 -24.71874421 0.14235732
2736 500.977 -24.71874422 0.88125051
3440 629.883 -24.71874417 0.91201400
4368 799.805 -24.71874422 0.33120633
5456 999.023 -24.71874422 0.81250651
6832 1250.98 -24.71874420 0.27409667
8736 1599.61 -24.71874419 0.23856877
10928 2000.98 -24.71874418 0.32774481
13648 2499.02 -24.71874416 0.47019342
17200 3149.41 -24.71874421 0.21303107
21840 3999.02 -24.71874419 0.75482235
27312 5000.98 -24.71874422 0.72061276
34400 6298.83 -24.71874421 0.91744560
43696 8000.98 -24.71874419 0.04343103
54608 9999.02 -24.71874421 0.90461145
68272 12501 -24.71874420 0.27080336
87376 15999 -24.71874418 0.54698210
109232 20001 -24.71874420 0.29017821
32 harmonics found
Sure. But it's still a good review, especially for those of us not familiar with the details of what's available now.Would not this discussion have been more meaningful in 1983 than in 2023? Back than commercial digital technology (including ADC & DAC) was struggling to do 16x44.1.
I probably have more comments on the post, but we still haven't determined what you mean by "harmonics". You didn't answer my question about it on the first page, and DonH56 asked about it again. It seems you're using a different definition of "harmonics" than the standard meaning, making it difficult to understand some of your points. You've mentioned things like 11025 harmonics for 1 kHz signal, which would require megahertz sampling, but you referenced 44.1 kHz. Hard to figure what that means.I used command line FFT to dump the frequencies and phases using 8 significant digits and ignoring harmonics with power less than -100 dB.
What did you expect 24-bit data to look like? What do you think your 64-bit data will look like after it passes through a 24-bit data path?The FFT results speak for themselves:
I think what you are saying is equivalent to using a whole number of sine cycles in the test pattern. At first, I was accidentally truncating the tones at an arbitrary point, such as 10 seconds. This doesn't affect high frequencies much. If a high frequency tone of 200,000 cycles comes up short by half a cycle, it's not so noticeable. But the low frequencies are greatly affected. If a low frequency tone of 200 cycles is truncated by half a cycle, thew difference is bigger.Since the noise floor of a real system is limited by resolution (number of bits) and the analog signal chain, I can live with truncating the sine wave to 1/2^N. More important in the test and measurement world is the ability to choose frequencies that bin perfectly in the FFT, a function of sampling rate and FFT length. The means to choose such frequencies, and thus avoid windowing in the FFT, are described in various IEEE Standards e.g. 1057 (waveform recorders, the grandfather), 1241 (ADCs), 1658 (DACs) etc. as well as numerous other references various manufacturers use. I have lost track of the IEEE numbers and revs since it's been a decade or so since I was involved with them.
I think I have proved my point
I agree. I made the error-free files as a personal challenge. The easiest way to get to the top of Mt Everest is helicopter. But some people climb it for the challenge.With 24-bit samples, you have 144 dB of dynamic range. Lose 3 dB due to dither noise is not important as even state of the art equipment has far more noise. And for FFTs, we can use FFT gain to go to any level of noise floor we want.
My point is that the sample Audio Precision test file provided by Amir isn't perfect and can be improved. I improved it.With respect, I am at a loss as to exactly what 'point' you have proved.
The easiest way to get to the top of Mt Everest is helicopter.
I agree. Isn't this the same as saying the test pattern should contain whole sine wave cycles, and not truncate a sine wave mid cycle? Of the Multitone Analyzer pre-built test files, I looked at 'Multitone 20 44100 64bits'. Viewing a the spectrum in real time shows a jump every 5 seconds. The file itself has one unique section of 131,072 samples. It's followed by the same pattern, but truncated to 89,424 samples. That doesn't seem right.FFT window is normally applied to any signal that has discontinuities, i.e., one that isn't infinitely periodic (which includes all real signals). FFT windows cause leakage, or spreading of energy, to the neighboring bins. If one wants to eliminate such leakage, test tone frequency must be exactly periodic with the length of the FFT which is easily accomplished by centering the test tone frequency precisely in the middle of an FFT bin.
I probably have more comments on the post, but we still haven't determined what you mean by "harmonics". You didn't answer my question about it on the first page, and DonH56 asked about it again. It seems you're using a different definition of "harmonics" than the standard meaning, making it difficult to understand some of your points. You've mentioned things like 11025 harmonics for 1 kHz signal, which would require megahertz sampling, but you referenced 44.1 kHz. Hard to figure what that means.
(BTW, just a minor point, but there is no "power" involved here, I think you mean magnitude referenced to the fundamental.)
I mis-spoke. What I am talking about is better described here. A 1000 Hz tone encoded at 44100 samples per second, with no partial cycles has 220 harmonics. That's because 441 samples encodes 10 complete cycles before the pattern repeats. 441 / 2 gives the potential number of harmonics (or whatever you want to call the component sine waves). So there are 220 component sine waves. Because of the odd / even relation of the two numbers, 220 is the final number. A big list of the number of component sine waves in a PCM encoded sine wave is here. It is interesting to note that I cannot find anywhere in my DSP text books where this simple calculation is described.I probably have more comments on the post, but we still haven't determined what you mean by "harmonics". You didn't answer my question about it on the first page, and DonH56 asked about it again. It seems you're using a different definition of "harmonics" than the standard meaning, making it difficult to understand some of your points. You've mentioned things like 11025 harmonics for 1 kHz signal, which would require megahertz sampling, but you referenced 44.1 kHz. Hard to figure what that means.
(BTW, just a minor point, but there is no "power" involved here, I think you mean magnitude referenced to the fundamental.)
54 bits of integer-equivalent precision, you need to include the implicit leading 1 which is not encoded, since it is always 1. Floats have 25-bit integer-equivalent precision.Bug fix: Double precision floating point as used in 64-bit wav files are good for 53 bits of precision.