None of the WAV files load in any of my audio software, either.
-
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.
- Thread starter scottd
- Start date
None of the WAV files load in any of my audio software, either.
Mac? The Finder happily seems to unpack the file, but it's 7s, not zip. Try another utility (The Unarchiver, free in the App Store, worked for me).
Mac and Windows
EDIT: I take it back, extracted it with another archive utility on the Mac and now they load OK.
Last edited:
KSTR
Major Contributor
In my direct implementation of generating periodic multitones with a bank of cosine oscillators I can set the phases of the populated frequencies as well.
As for minimized crest factors, I think there is an additional constraint. I can get really low crest factors using Newman start phases but this transforms a multitone into a periodic sweep with mostly only one (momentary) frequency playing at a time which sort of defeats the idea of having all frequencies playing at all times. So what we want is a still quite random start phase distribution but one that avoids "unlucky" piling up of momentary amplitudes. Then even with a shorter and windowed FFT we have enough frequencies playing at a time.. and this also properly excites the DUT.
I've seen quite some difference in DUT responses depending on actual start phase distribution (and thus resulting crest factor) for multitones with identical magnitude spectra. I would think for reproducible results periodic multitones should be exactly spec'd with not only the frequencies and amplitudes but also, for example, the start phases for cosine oscillators, using the "prototype" model of a bank of oscillators for convenience.
- Thread Starter
- #65
The reason I thought nobody was using inverse FFT for tone generation is the generally dismal state of free test tones I find. For the one I tested (FFTW), the output has better accuracy than what I find here. However, as of today I can no longer say I have found no test tone files that are correct to the limit of their sample format. See below.
The other day I saved single tone sine files from your Multitone Analyzer and viewed a couple of them with Spectrumviewer for Windows. Even though the files come out to 49 seconds for me, it's immediately obvious there is a a problem. When I say there is a problem, I mean relative to the goal of correctly setting all sample bits. Your files are double precision, so that sets the bar far higher that AP, REW, etc. Though the fundamental is good, the noise harmonics are sitting at around -217 dB. For double precision, I would expect something closer to 54 * 6.02 = 325 dB. So the single tone files I looked at seem to properly encode only 37 or so of the 54 bits. Note that 37 correct bits is still far in excess of AP, REW, etc. Another point is that SpectrumViewer shows something not so easy to see with FFT. The noise harmonics are not steady. they jump somewhat randomly. That suggest a sine or sine argument problem.
After seeing that, I didn't study Multitone Analyzer test tones any more. I figured multitone from the same software would be similar to its single tones. But this morning I did take a look at your multitones. They are amazing, and reach the level of double precision bit-perfectness to within my ability to measure. Well done! I checked every one of them. They all repeat after 2^21 samples.
So at his point, I can say Multitone Analyzer has the highest resolution multitone files of any in widespread use here. However, Multitone Analyzer single tones, while probably better than AP, REW, etc from an ENOB point of view, are far below the quality (ENOB level) of the Multitone Analyzer multitone files.
Thanks for the free software. By the way, our SCADA shop had a Compaq like yours in 1984. We had it maxed out with 640KB RAM, and it made the BIOS powerup memory scan took forever. I see you have dual half-height floppies in the left bay and a HDD in the right. After 12 years of SCADA, I worked for Compaq 1994-2004.
- Thread Starter
- #66
Here is a video of 15KHz sine from Multitone Analyzer that shows shows the sine angle error accumulation problem:
Here is what I would expect:
I did a quick test of a Rew generated 15K sine wave. It's steady with a repeating pattern of length 147 samples at 44100. But when saving as 32-bit integer, it doesn't produce the expected result. I did an experiment and found Rew sine saved as 32-bit integer has exactly the same noise harmonics as when saved as 32-bit float. It looks like Rew is limited to single precision float for exported wave file tones.
Here is what I would expect:
I did a quick test of a Rew generated 15K sine wave. It's steady with a repeating pattern of length 147 samples at 44100. But when saving as 32-bit integer, it doesn't produce the expected result. I did an experiment and found Rew sine saved as 32-bit integer has exactly the same noise harmonics as when saved as 32-bit float. It looks like Rew is limited to single precision float for exported wave file tones.
- Thread Starter
- #67
I checked some Rew test tones, and one has a unique problem. It's the Klingelnberg 10.5K, 19K, 20K:
https://notabs.org/audiosciencerevi...mV_44k_PCM32_rew.wav_ 2023-01-14 00-09-41.mp4
https://notabs.org/audiosciencerevi...mV_44k_PCM32_rew.wav_ 2023-01-14 00-09-41.mp4
I suspect the "problem" may be a lack of windowing in your analyser, the dual and triple tone signals have the frequencies they state, they are not periodic in an FFT length.
REW uses single precision floats for all its audio data paths, including the signal generator output, since they have higher integer-equivalent precision than any device is currently capable of reproducing. Using doubles would be inefficient, doubling the storage requirement and amount of data being moved around. For analysis and generation of live audio streams efficiency is important.
There's no sine error accumulation problem in Multitone, since the tone is not generated using sines. What you're seeing seems to be an artifact of your processing for display and that's where you should look for the error.
I posted an example before, and here it is again. This is with no averaging, a single 64k-sample test signal, @15Khz. No windowing, 64k FFT, and the plotting library always shows the peak value if multiple bins fit into the same display pixel, so these are not averaged in any way:
Why aren't your "perfect" test tones dithered to the chosen sample format? They have horrendous quantisation artefacts.
Actually, no quantization error at all. BUT...here is the problem, which I alluded to early in this thread:
The files are perfect, to the bit. So, there is no dither necessary—strictly speaking to the values in the files—because there is no quantization error. That's what makes them "perfect"—exact repeating patterns that make perfect sine waves with no quantization error.
Where all this goes off the rails is that, 1) you only have a choice of three frequencies relative to the sample rate—divisors of 3, 4, and 6. So, for the frequencies in the directory of "perfects", the sample rates are selected to obtain the frequencies implied in the naming. That is, non-standard frequencies, so sample rate conversion needs to be performed in order to really get "20 Hz", etc., as indicated—by specifying sample rates of 60, 80, or 100Hz. I don't find those samples rate supported on any converters I own (do you?), so SRC will be used...and there goes "perfect".
And, 2) The samples are normalized in a way that will produces inter-sample overs. So they need to be multiplied by a number less than 1, and since they use all the bits, you'll have to ensure that the result remains symmetrical (rounding towards zero, for instance), or you'll need to dither. This one is not as big of a problem as #1, in practice, because the error is relative. (That is, as long as the error induced by the gain is symmetrical, the peak amplitude might be a little off but the spectrum will still be perfect.)
So, yes, the data in the files are perfect. But you can't play them as expected without sacrificing that perfection.
If anyone needs a little clarity, examples:
4_1_20Hz.wav has the repeating pattern 0x0000, 0x7FFF, 0x0000, 0x8001...in other words, 0, 1, 0, -1, 0, 1, 0, -1 (with each 1 being slightly less than "1.0", but symmetrical. That's the easiest to understand, since it's the zero crossings and positive and negative peaks for a sine. But obviously it will always be one-quarter of the sample rate, because it takes four samples to complete a cycle. So, the sample rate needs to be 80 Hz in order to achieve a 20 Hz tone, as indicated in the file name.
3_1_20Hz.wav is the repeating triplet of 0x0000, 0x7FFF, 0x8001...It looks like the same amplitude, but since one cycles is divided into three samples, 0x7FFF and 0x8001 (±1) aren't at the peaks of the sine, they are down the side a bit. So this will play back well over full output of the DAC (~16% over), and need to be scaled back. The same with 6_1_20Hz.wav. All need SRC if you want to specify and arbitrary frequency.
So, the perfect waves are interesting mathematically, but have limited practical value, except for producing a third, fourth, or sixth of the sample rate in use. Their best use is, for instance, is to give a 24-bit DAC a perfect 24-bit sequence that can generate a perfect, noise-free sine on a perfect DAC. But you only have three choices of frequencies.
Last edited:
- Thread Starter
- #73
Thanks for looking at it. The analyzer I am using is the old-school filter bank kind, so there is no FFT and therefore no windowing.
I figured out the problem: The Rew generator is clipping without any indication of clipping. For the settings I used (Klingelnberg, 44100), Rew allows me to put in an RMS value as high as 589 mV without turning red and showing the clipping warning. But what I find is that clipping actually starts at 578 mV. So at least in my case, the clipping warning is off quite a bit.
- Thread Starter
- #74
Yes exactly. Well stated. At first I did my debugging of SpectrumViewer, an old-school filter bank spectrum analyzer emulation, with Windows audio. I quickly learned I would pull my hair out that way and switched to wave files. I noticed that the number of noise harmonics varies with the sampling rate and sine frequencies. I saw that dividing sample rate and sine frequency by the greatest common denominator of both results in a pair of numbers related to the number of harmonics. After that, I figured out how to exactly calculate the number of quantization harmonics in all cases. It's either the total number of harmonics possible, of half that, depending on odd-even symmetry. Some of the noise harmonics can seem to be missing in certain cases, because the round-off error is sometimes small. But those missing harmonics are there, and become visible with increased sample depth.Actually, no quantization error at all. BUT...here is the problem, which I alluded to early in this thread:
The files are perfect, to the bit. So, there is no dither necessary—strictly speaking to the values in the files—because there is no quantization error. That's what makes them "perfect"—exact repeating patterns that make perfect sine waves with no quantization error.
Where all this goes off the rails is that, 1) you only have a choice of three frequencies relative to the sample rate—divisors of 3, 4, and 6. So, for the frequencies in the directory of "perfects", the sample rates are selected to obtain the frequencies implied in the naming. That is, non-standard frequencies, so sample rate conversion needs to be performed in order to really get "20 Hz", etc., as indicated—by specifying sample rates of 60, 80, or 100Hz. I don't find those samples rate supported on any converters I own (do you?), so SRC will be used...and there goes "perfect".
And, 2) The samples are normalized in a way that will produces inter-sample overs. So they need to be multiplied by a number less than 1, and since they use all the bits, you'll have to ensure that the result remains symmetrical (rounding towards zero, for instance), or you'll need to dither. This one is not as big of a problem as #1, in practice, because the error is relative. (That is, as long as the error induced by the gain is symmetrical, the peak amplitude might be a little off but the spectrum will still be perfect.)
So, yes, the data in the files are perfect. But you can't play them as expected without sacrificing that perfection.
If anyone needs a little clarity, examples:
4_1_20Hz.wav has the repeating pattern 0x0000, 0x7FFF, 0x0000, 0x8001...in other words, 0, 1, 0, -1, 0, 1, 0, -1 (with each 1 being slightly less than "1.0", but symmetrical. That's the easiest to understand, since it's the zero crossings and positive and negative peaks for a sine. But obviously it will always be one-quarter of the sample rate, because it takes four samples to complete a cycle. So, the sample rate needs to be 80 Hz in order to achieve a 20 Hz tone, as indicated in the file name.
3_1_20Hz.wav is the repeating triplet of 0x0000, 0x7FFF, 0x8001...It looks like the same amplitude, but since one cycles is divided into three samples, 0x7FFF and 0x8001 (±1) aren't at the peaks of the sine, they are down the side a bit. So this will play back well over full output of the DAC (~16% over), and need to be scaled back. The same with 6_1_20Hz.wav. All need SRC if you want to specify and arbitrary frequency.
So, the perfect waves are interesting mathematically, but have limited practical value, except for producing a third, fourth, or sixth of the sample rate in use. Their best use is, for instance, is to give a 24-bit DAC a perfect 24-bit sequence that can generate a perfect, noise-free sine on a perfect DAC. But you only have three choices of frequencies.
The points you make about the choice of actual sample values is interesting. I think you are making two points if I am understanding. One point is about what sample encodings are used for full scale min and max. You say: 0x0000, 0x7FFF, 0x0000, 0x8001...in other words, 0, 1, 0, -1, 0, 1, 0, -1 (with each 1 being slightly less than "1.0", but symmetrical. My intention was to make the values zero, plus full scale and minus full scale. But apparently there are two schools of thought about how to handle the problem of more negative encodings than positive encodings. I am taking this approach, which has some support from a couple of audio standard publications. But according the the link, not everybody agrees.
The other point if I understand you is that the wave files are describing a sine wave that exceeds the [-1, +1] range. Don't many wave files do that? If a wave file is scaled to [-1, +1], there are many cases where the sine wave peak won't fall exactly on a sampling point. So the real peak never gets sampled the file is scaled [-1, +1] then the reconstructed sine wave will exceed [-1, +1]. Some of the examples I made are worse case for this effect I think. Well like you say, any gain scaling can be used and still demonstrate how the noise harmonics are avoided. I just thought max scaling was good choice for demo, and FFT is OK with it.
So yes, this 3:1, 4:1, 6:1 is a mathematical curiosity. I find them a useful test case for both for my filter bank spectrum viewer, as well as for command line FFT/DFT testing. Both tests show results consistent with the claim of no quantization harmonics. I don't think there is any other way to make a PCM wave file that describes a single frequency tone with no quantization harmonics.
For what you are doing to work, you need samples to be either 0, A or -A. And 1/3, 1/4, 1/6 ratios allow that. So, I wasn't talking about the distinction of 0x7FFF being not quite 1.0, versus 0x8000 being exactly -1.0. If you're going to use the maximum positive value, it needs to be balanced with one lsb less than the maximum negative value, as you are doing. I have no issue with that.
What I was pointing out is that you have multiple frequencies. When choosing between test frequencies, people anticipate that they will have different frequencies, but the same (or very close) amplitudes. But your 1/3 and 1/6 waves have a much high amplitude than the 1/4 wave. In the case of 1/3 and 1/6, the maximum samples values represent points on the rishing and flling curves, whereas for the 1/4 they represent the positive and negative peaks. So, at minimum better values of "A" should be chosen (around 0.866 or lower, versus ~1.0).
Yes, but your "perfect" files exacerbate the problem. The 1/3 wave would correspond to 16 kHz for 48 kHz SR. We don't test often with 16 kHz, we test with things like 1 kHz, which are more headily oversampled, and therefore the creating over the highest sample value is far smaller. And since the people making "non-perfect" test signals don't have to worry about being perfect, they simply calculate the sine values references to something just under 1.0, and there is no "crest factor" concern at all.
Inter-sample overs is really another topic, for the general case. You can artificially create overs of any theoretical amplitude you want. It's not actually much of a problem is music that people would want to listen to, and the worst case is easily handled by either always backing off a bit, or monitoring with oversampling meters.
Again, I cringe at "quantization harmonics". The artifacts you refer to with this term are not harmonics of the signal you are generating (in the general case where a cycle is not an integer number of samples), which would be the first thing people think of when you generate a signal and speak of harmonics. And if you dither—which everyone would expect of such a test signal—they aren't even periodic (in any practical sense). Also, the same effect in actual music would have ever-changing correlation with the music, resulting in absolutely no sense of being harmonics at all, even without dither. Sorry, you may have read of other people referring to them as "quantization harmonics", but I don't find that viewpoint helpful at all. <shrug, just my opnion>
- Thread Starter
- #76
Thanks for looking at it. Something really strange is going on. You're app is a little short on symbols for easy debugging. The farthest I can see the code get for the 15 kHz sine generation is here: MathNet.Numerics.IntegralTransforms.Fourier.FrequencyScale(Int32 length, Double sampleRate)
So it is calling a Fourier related function.
However, if I change the FFT size box to something big, then export multitone 3 and compare the result to 15kHz sine, the execution is vastly different. Saving multitone 3 as a wave file runs all 24 threads on my desktop near maxed out for several minutes. On the other hand, saving 15kHz sine as a wave file take less than one second:
That's one reason I thought sine generation was using the sine in a loop method. Multitone generation uses several minutes of 24 thread execution while 15 kHz sine uses less than a second of single thread execution.
Another big difference between the multitones (multitone 3 tested) and the sines (15 kHz sine tested) is that the multitones are periodic with a pattern sample length matching the FFT size. The sine never (exactly) repeats. At 44100, sine 15kHz should repeat every 147 samples by my calculation. For IFFT generation, I would expect the software to adjust the sine 15 kHz frequency the the nearest match available with the given FFT size. MTA will not accept a non-power of two for FFT size. So I can't enter 147. But with multitones, I always get a sequence of identical sample patterns each of length following the FFT size.
Another difference between multitone and single frequency sine is that the single frequency sines have a pre-defined frequency and the multitones do not. So there has to be a difference in the code flow relating to that.
I will finish debugging it tomorrow if this doesn't ring any bells. I did back the gain down a bit from full scale, and that wasn't the problem.
Sorry about that. The bottom left corner of the level display shows the peak level, which was 0.17 dBFS so above full scale. I've fixed the waveform preview warning for the next build.
We are talking about different signals. I wasn't referring to the ratio files, but to the output produced by waveutil in the "PerfectSineWaves" repository linked in the post I quoted. It truncates to the selected sample format without dither and with no option to apply dither, hence the quantisation artefacts shown in the RTA. From my point of view they are not useable as test signals.
Aside: I checked the program (Mathcad) I use for most of my articles here and the noise floor is around -240 dB for single or multiple tones using sine waves to generate the signals. I normally use a pretty simple scheme to generate test frequencies even though I have the functions to "go all the way". So, not perfect, but far greater than anything I've tested. If I move to a bit more rigorous methodology to generate the tones (still using sine waves) I can achieve the -320 dB or so mathematical noise floor, but that is not normally a concern, as I usually quantize to 16 bits (sometimes 24). This is for single captures, no averaging, and without windowing.
Scott, just a suggestion: ask a question instead of making statements based on incomplete information. Your posts are worded as fact, appearing to make claims about how and what is being done in other software, but these are often incorrect or misleading.
Can I ask what version of Multitone you're using, by the way?
1. MathNet isn't used for test tone generation at all. I do use it for precomputing simple sequences (when I feel lazy) and some basic FFT windows, as well as for various interpolation and least-squares fitting, but it's not used for much more than that. Most single and multiple tone test signals are generated using IFFT. Large multitones take more time due to the crest factor optimization process (not needed with single tones). Crest factor optimization is also done in the frequency domain but can require multiple iterations. A 32 tone multitone takes about 3 seconds on my 4 years old iMac that's running a Windows virtual machine with 4 allocated cores. By design, MT doesn't allocate more worker threads than the number of CPU cores, so 24 busy threads sounds very unlikely, unless you have a 24-core CPU.
2. MTA will certainly accept non-power of two FFT sizes: just type in the desired number.
3. Not sure about your point about differences between single tone and multitone generation. Of course, there's a difference in the code path to generate these. That doesn't mean they are not generated using the same method, which is IFFT. There are some other signals that are generated in the time domain. These are more complex waveforms such as the FM-modulated test tones, chirps, etc. I fully accept that these may have errors that are somewhat above -300dB. Not a problem for what these are used for.
4. As for repeatability of samples, be sure to turn off dither which is on by default in Multitone, set to 24 bits, I believe.
And again, I posted a number of examples (single and multiple tones) showing the errors in MT-generated signal down to well below -300dB. I don't really see a reason to pursue an even higher precision for test tone generation -- there is no hardware in existence that can make use of such tests.
Last edited:
Similar threads
- Poll
