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

[earlevel]

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.

OK, I also was referring to the repository, but you said 'Why aren't your "perfect" test tones...'. The only perfect ones are in the "perfect" folder, so you can see how I assumed you were referring to those. I don't think he claims any non-3-4-6-ratio to be "perfect".

He does claim his utility is "The most accurate sine wave generation utility available", and that, of course, is another matter. So I suppose it's problematic to begin with to refer to a repository as "PerfectSineWaves", which includes perfect sine ave and the ability to create them, along with the ability to create imperfect test tones.

And as a nit-picky aside, the claim of the repository is, "Perfect and bit-perfect PCM encoded sine wave audio test tones". I'll accept that it can create perfect PCM encoded sine waves, within strict limitations, but "bit-perfect" is a term normally used for processes, and doesn't fit this data-accuracy context. "Bit-perfect" doesn't mean "error-free". For instance, bit-perfect is often used to describe digital music playback, even though music is never encoded error-free.

 

[scottd]

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.

View attachment 257326


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.

Well for point number 2, I must be losing my mind. I do realize the presets are powers of two, but I thought for sure I typed in other values and saw them pop back to a power of two. But I cannot reproduce that today. I tried everything. But now that I can change that value, I can have better control over the output length.

Also, sorry to cause the wild goose chase. Reminds me of my wife the other day who works from home and the office is far away. A guy made her drive to the office because his server wouldn't boot. Before going she told him to check the time because invalid time can prevent booting. He said it was good. She drove there and found the time was good. But the date was bad, as well as the am/pm setting.

From an end-user point of view, the difference between your multitone generation and single tone generation is frequency selection. For multitone, the program is selecting the exact frequencies, not the user. So the program can choose frequencies that are valid for the FFT length and sample rate selections in effect. But for single frequencies, I am able to choose a frequency, 15 KHz in my test case. That seems to be a part of the problem. For the 44100 rate I'm testing with, the sample pattern needs to repeat every 44100 / gcd (44100, 15000) = 147 cycles. So unless the end used dusts off his grade school math book and uses a whole number multiple of the sample rate divided by the GCD of sample rate and sine frequency, it will not be possible to get the expected output.

Thanks to my newfound ability to enter the FFT size, I can retest using FFT size set to whole number multiples of 147. That improves the output, but it's still not at the level of the multitone generation. It still lacks an exact repeating pattern.

I uploaded some wave files made by MTA (here). The two files were made with the same settings except for FFT size. The file with _147 in the name uses FFT size 1470000. This one hits the 15 KHz frequency exactly as best I can tell (zero crossings). But the exact sample values don't repeat like they do with multitone generation. Without a repeating sample value, I don't think precise FFT results can be expected. So I took the FFT over the whole 68 seconds. Of course the results aren't perfect because there is no repeating pattern. I get the expected -3.01 dB at 15 KHz, but at the neighboring frequency before it comes in at -201 dB. This is the double precision option, so I expected the neighboring frequencies to be below -325 or so.

The other file has the power of 2 FFT size. Its frequency is 14999.985294 Hz according to the FFT applied to the whole file. Probably more accurate is a zero crossing count over the whole 68 second file. That gives 14999.979166 Hz. Again, I don't think the exact frequency matters to most people. But if the file is named 15 KHz and the GCD of that and the sample rate work out such that a small repeating sample count can produce the exact frequency, then it seems like it should be an easy case to hit right on the money.

I don't understand how IFFTW can produce a pattern that doesn't repeat based on the FFT size. Thanks for looking.

 

[pkane]

From an end-user point of view, the difference between your multitone generation and single tone generation is frequency selection. For multitone, the program is selecting the exact frequencies, not the user. So the program can choose frequencies that are valid for the FFT length and sample rate selections in effect. But for single frequencies, I am able to choose a frequency, 15 KHz in my test case. That seems to be a part of the problem. For the 44100 rate I'm testing with, the sample pattern needs to repeat every 44100 / gcd (44100, 15000) = 147 cycles. So unless the end used dusts off his grade school math book and uses a whole number multiple of the sample rate divided by the GCD of sample rate and sine frequency, it will not be possible to get the expected output.

Multitone automatically adjusts requested or computed tone frequencies (multitone or single tone) to the closest frequency that is periodic with the FFT. The user isn't required to do any computations to make this work This is so that rectangular window can be used, along with multiple averages. You can see the actual frequency being displayed in the measurement box, at least for the single tone:

 

[scottd]

. . .
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.)
. . .

Thanks for the feed back. I just finished a massive rework to fix the level problem. I also removed the 3:1 and 6:1 examples from the perfect directory due to imperfect level. That leaves the only 4:1 examples as 'perfect'.
I at least had to try calculating true peak. Even for the very simplest multitone example, the direct mathematical solution has hundreds of terms.
So I took a different approach. 16x upsampling of the generator function is used to locate each peak. Then a binary search is used to zoom in on the actual peak, until the exact 128-bit precision input value is isolated.
It turns out that much precision isn't really useful. The reason is that the quantization error introduced during encoding masks the high precision level of the binary search determined value. For example, a 1KHz sine at 44100 that starts as 1.0 true peak ends up at 1.000000046117993 after 24-bit encoding. To address this problem, the utility has a finetune option that adjusts the level in a loop and narrows in on the one that best matches the target without going over. For this example the result is 0.9999999830729031 which is not actually better, but at least it fixes the original out of range result.
The end result is that the new wave files have true peak amplitude accurate to roughly 16 digits for f64 format. The 32 bit format results in 9 or so digits of amplitude match, and 7 or so digits for 24-bit.
To measure the true peak amplitude of the generated wave files, the utility uses FFT upsampling of at least 1024:1, and much higher in most cases. This simple FFT upsampling command isn't suitable for any wave file. But for periodic wave files with repeating pattern of say 32K samples or less, it works well. The utility now recognizes when an input wave file is composed of a repeating pattern, including the common case where the final pattern instance is chopped part way through. The utility operates on a single instance of the pattern and upsamples to the largest power of 2 sample count less than 2^25.