• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

How good is your PCM sine wave test tone? Niven's theorem is your friend.

scottd

Member
Joined
Jul 10, 2022
Messages
36
Likes
16
Location
Texas
A steady sine wave tone is useful for various testing applications. A PCM encoded wave file can hold a representation of a sine wave, but often it's not perfect due to quantization loss when sine values are converted to integer sample values. The sine function generally produces irrational values, and an irrational value can't be digitized without loss. But Niven's theorem points out 3 special cases where sine is rational. If the PCM sine wave file is constructed using the rational values from Niven's theorem, quantization rounding loss can be avoided, allowing the PCM wav file to describe a sine wave perfectly. When such a constructed PCM sine wave file is played back, the only imperfections are due to equipment limitations, and not the wav file itself. Here is more information.
The effect of quantization loss on the spectrum of PCM sine waves has been thoroughly studied starting in the 1940s. But the focus is on real-world use, such as voice signals. I have yet to see anyone point out the 3 very special cases of sampling rate to sine frequency of 3, 4, and 6 that are useful for generating pure tones.
The PCM wave files for these 3 cases contain the following patterns, repeated indefinitely:

0 1 -1
0 1 0 -1
0 1 1 0 -1 -1
 
So, half sample rate, quarter sample rate and a square wave.

Okay, but the answer is dither.
I'm not so good at explaining my thoughts. Dithering adds noise. These test tones are noise-free. Now I admit that my hardware (Asus motherboard audio) isn't quite good enough to demonstrate the difference using a hardware loop-back cable. My motherboard audio doesn't preserve more that 16 bits in loop-back mode, even with 24-bit input/output.
These noise-free tones have another use: benchmarking measurement software.
 
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'm not so good at explaining my thoughts. Dithering adds noise. These test tones are noise-free. Now I admit that my hardware (Asus motherboard audio) isn't quite good enough to demonstrate the difference using a hardware loop-back cable. My motherboard audio doesn't preserve more that 16 bits in loop-back mode, even with 24-bit input/output.
These noise-free tones have another use: benchmarking measurement software.
Yes, but it is preferable to quantization noise, and most gear is surely going to use dither. As the noise is spread out across the frequency bandwidth, if you are using FFT analysis the noise in each bin is very far below any signal, distortion or whatever. As DonH 56 says, much more important is to choose frequencies that fit in the middle of FFT bins to get at really, really low level things going on. Using real gear and REW or Multitone software or others you can get down to -150 db or so even with dither and other noise. Noise shaped dither can do even better. You can literally record and recover tones below -120 db even if using 16 bit files sent thru with dither. Without dither everything below like -98 db disappears.
 
Mic feed from my speaker very cycle are not the same from DAW such as Audacity.
 
I am truly not good at explaining my thoughts. Dither is a way to hide patterns in quantization noise. A PCM encoded sine wave has NO quantization noise if the sample rate to sine frequency ratio is 3:1, 4:1, or 6:1. There is no quantization noise to hide. That's the value of these special test tones. These test tones work properly with a sample bit depth as little as 2 bits. Dithering 2-bit samples would not even be possible.

I made a new thread showing a use for these special test tone files. When an input file has zero noise, noise in a spectrum display such as that of REW is all due to software. Software can limit its introduced noise to any level, but at the expense of performance. Limiting software introduced noise to that of IEEE double precision (53 * 6.02 = 319 bits) is a good balance between performance and precision for many applications. The point I am trying to make is that software should strive to limit its introduced noise to the extent possible without going beyond double precision floating point math. That means noise introduced by measurement should be < -319 dB. These test tone files provide an easy way to see how much noise your software is contributing.

As far as FFT bins, I don't understand the point. I made a test file encoded at 48,000 samples per second carrying a sine wave of 16,000 Hz. Surely any software displaying its spectrum should be able to do what's necessary to get the job done. FFT/DFT isn't even needed for making an accurate, low noise spectrum display as SpectrumViewer shows (it uses a digital filter bank). But certainly FFT/DFT can get the job done equally well if implemented properly.
 
I'm not so good at explaining my thoughts. Dithering adds noise. These test tones are noise-free.
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.
 
All the highest precision industry standard test CDs (16bit) I have and use, deliberately ensure the spot frequency is prime to the sample rate. ie, not 1000Hz, it is 997Hz. Not 16kHz but 16001Hz. The square wave is not 1kHz, it is 1002.27Hz.
 
A steady sine wave tone is useful for various testing applications. A PCM encoded wave file can hold a representation of a sine wave, but often it's not perfect due to quantization loss when sine values are converted to integer sample values. The sine function generally produces irrational values, and an irrational value can't be digitized without loss. But Niven's theorem points out 3 special cases where sine is rational. If the PCM sine wave file is constructed using the rational values from Niven's theorem, quantization rounding loss can be avoided, allowing the PCM wav file to describe a sine wave perfectly. When such a constructed PCM sine wave file is played back, the only imperfections are due to equipment limitations, and not the wav file itself. Here is more information.
The effect of quantization loss on the spectrum of PCM sine waves has been thoroughly studied starting in the 1940s. But the focus is on real-world use, such as voice signals. I have yet to see anyone point out the 3 very special cases of sampling rate to sine frequency of 3, 4, and 6 that are useful for generating pure tones.
The PCM wave files for these 3 cases contain the following patterns, repeated indefinitely:

0 1 -1
0 1 0 -1
0 1 1 0 -1 -1
Good point, very cool. It's worth adding that these three patterns produce sine waves of different amplitudes. And related: While scaleable, the first and third have peaks greater that the respective digital peaks, so watch out for "inter-sample peaks". But nice that, within those limitations the perfection remains perfect for any gain change of an integer multiple (of the integer "1"), unlike arbitrary sine waves, for which the S/N gets worse as the signal drops (and dither won't fix that, only make the error sound better).

However, if it's a 24-bit sine wave played on 24-bit hardware, the error is well beneath unavoidable errors such a Johnson-Nyquist noise, and the threshold of hearing at any practical monitoring level. So the above is academic—we usually want a test signal at the frequency we want it, and the amplitude we want it. And of course some times we want sine sweeps, which can't be done under Niven's terms.

It seems it would be helpful for tests of shorter word length hardware (though some—all?—could be also done with square waves at integer multiples of the sample period, with many more possible frequencies).

But it's still a neat mental exercise, thanks for bring it up. :)
 
As far as FFT bins, I don't understand the point. I made a test file encoded at 48,000 samples per second carrying a sine wave of 16,000 Hz. Surely any software displaying its spectrum should be able to do what's necessary to get the job done. FFT/DFT isn't even needed for making an accurate, low noise spectrum display as SpectrumViewer shows (it uses a digital filter bank). But certainly FFT/DFT can get the job done equally well if implemented properly.

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 am truly not good at explaining my thoughts. Dither is a way to hide patterns in quantization noise. A PCM encoded sine wave has NO quantization noise if the sample rate to sine frequency ratio is 3:1, 4:1, or 6:1. There is no quantization noise to hide. That's the value of these special test tones. These test tones work properly with a sample bit depth as little as 2 bits. Dithering 2-bit samples would not even be possible.
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.

I made a new thread showing a use for these special test tone files. When an input file has zero noise, noise in a spectrum display such as that of REW is all due to software. Software can limit its introduced noise to any level, but at the expense of performance. Limiting software introduced noise to that of IEEE double precision (53 * 6.02 = 319 bits) is a good balance between performance and precision for many applications. The point I am trying to make is that software should strive to limit its introduced noise to the extent possible without going beyond double precision floating point math. That means noise introduced by measurement should be < -319 dB. These test tone files provide an easy way to see how much noise your software is contributing.
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.

As far as FFT bins, I don't understand the point. I made a test file encoded at 48,000 samples per second carrying a sine wave of 16,000 Hz. Surely any software displaying its spectrum should be able to do what's necessary to get the job done. FFT/DFT isn't even needed for making an accurate, low noise spectrum display as SpectrumViewer shows (it uses a digital filter bank). But certainly FFT/DFT can get the job done equally well if implemented properly.
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
 
All the highest precision industry standard test CDs (16bit) I have and use, deliberately ensure the spot frequency is prime to the sample rate. ie, not 1000Hz, it is 997Hz. Not 16kHz but 16001Hz. The square wave is not 1kHz, it is 1002.27Hz.
When the sine frequency doesn't divide the sample rate, there will sampleRate/4 harmonics, assuming the sample rate is even and the sine frequency is integer. So a 1KHz sine at 44100 has 11025 harmonics. One fundamental plus 11024 due to quantization noise. That gives a self-dithering effect. That is why the coprime sample rate/frequency pairs are used. With that much self dithering, added dithering hardly changes the spectrum. So it makes the dithered/undithered forms essentially the same.
So why not take it to an extreme and choose a frequency such as 997.001 Hz? That gives 11025000 harmonics for super smooth self dithering. Of course the problem with that is the resulting wav file is 1000 seconds long (or integer multiples of that).
 
Good point, very cool. It's worth adding that these three patterns produce sine waves of different amplitudes. And related: While scaleable, the first and third have peaks greater that the respective digital peaks, so watch out for "inter-sample peaks". But nice that, within those limitations the perfection remains perfect for any gain change of an integer multiple (of the integer "1"), unlike arbitrary sine waves, for which the S/N gets worse as the signal drops (and dither won't fix that, only make the error sound better).

However, if it's a 24-bit sine wave played on 24-bit hardware, the error is well beneath unavoidable errors such a Johnson-Nyquist noise, and the threshold of hearing at any practical monitoring level. So the above is academic—we usually want a test signal at the frequency we want it, and the amplitude we want it. And of course some times we want sine sweeps, which can't be done under Niven's terms.

It seems it would be helpful for tests of shorter word length hardware (though some—all?—could be also done with square waves at integer multiples of the sample period, with many more possible frequencies).

But it's still a neat mental exercise, thanks for bring it up. :)
Great summary. The 3:1, 4:1, and 6:1 ratios of sample rate to sine frequency aren't all that useful outside of software testing. So what's the best way to get a high quality sine wave without all the restrictions of this method? For a PCM wav file, the answer is easy:
1) Generate sine function values using bit-perfect 64-bit or better double precision math. This is easily done using The GNU MPFR Library.
2) Choose the number of samples so that every sine wave completes of an exact integer number of cycles.
3) Compensate for the fact that pi is irrational. That means the angle calculations must be done with a precision higher than that of the sine calculation itself. So the angle calculations should use 128-bit floating point, or better. It's super easy using The GNU MPFR Library, assuming a project can call its C functions.
I will show some examples and sample code.
 
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:

index.php
 
When the sine frequency doesn't divide the sample rate, there will sampleRate/4 harmonics, assuming the sample rate is even and the sine frequency is integer. So a 1KHz sine at 44100 has 11025 harmonics. One fundamental plus 11024 due to quantization noise.
I don't know what you're saying here. 11025 harmonics of 1 kHz dictates a top frequency of 11.025 MHz. At a sample rate of 44.1 kHz. I understand that there will be quantization noise. There rest I can't make sense of.

That gives a self-dithering effect. That is why the coprime sample rate/frequency pairs are used. With that much self dithering, added dithering hardly changes the spectrum. So it makes the dithered/undithered forms essentially the same.
It doesn't self-dither—you're discussing generated signals, therefore the error (noise) would simply be truncation error, therefore it's not decoupled, hence not dithered.

But even if it were self-dithered, you say, "added dithering hardly changes the spectrum." But the only reason we would dither at that point is to reduce the sample word length, and of course that dithering step would necessarily be done with much higher magnitude of added noise. (Edit: Alright, I guess you mean calculating at high precision then truncating to the target word length for the DAC is basically no worse than calculating at a higher precision, adding appropriate dither noise, then truncating. Well, pretty much true, since this is a test signal of presumable decent amplitude, and constant level. But strictly speaking...)

If you think you are right, and perhaps I'm misunderstanding your points, I'm open to reading your explanation.
 
Last edited:
2) Choose the number of samples so that every sine wave completes of an exact integer number of cycles.
Just singling this one point out for clarity. The advantage of this is basically that error from quantization is purely harmonic distortion. greed? Or do you have another thought?

That is, essentially, any quantization error results in harmonically related tones added to the target sine wave.

(Historical note: This was the advantage of non-multiplexed, variable sample rate hardware digital oscillators. Ones that would repeatedly cycle through a single wave table. you could get by with 8-bit DACs, for instance, because the error wasn't "noise", it was harmonic distortion.)
 
3) Compensate for the fact that pi is irrational. That means the angle calculations must be done with a precision higher than that of the sine calculation itself. So the angle calculations should use 128-bit floating point, or better.
Rather than incrementing the floating point angle itself for each sample, it's better to use an integer phase rotator that is incremented by the bin number, modulo the (integer) sequence length, obtaining the current angle by one single direct multiplication with M_2_PI / double(seq_len), double precision math. This avoids any accumulation of errors, no need for any 128bit floating point libraries.
 
Back
Top Bottom