Beta Test: Multitone Loopback Analyzer software

[Grooved]

Found the setting for 32 multitone :

Beta Test: Multitone Loopback Analyzer software

This is a software beta-test for IMD and THD aficionados with an intense desire for multi-tone audio testing :) The start of the documentation and the download website is here: https://distortaudio.org/multitone.html (for 64-bit Windows) Multi-tone Analyzer (MA) was more of an experiment than...

audiosciencereview.com

Not sure for the 1kHz test

 

[KSTR]

Incoherent averaging is usually only useful in the frequency domain. It can produce a more precise frequency/amplitude measurements because it excludes time/phase from the calculation. It is also easier to do

Coherent averaging uses time-aligned samples (i.e., the same starting phase in the frequency domain). This can result in lower noise, higher SNR more quickly (fewer averages) than when using incoherent averaging. Here's a plot stolen from an on-line book Understanding Digital Signal Processing (2nd Edition). The top line is the SNR gain per number of averages (X-axis) for coherent averaging, the bottom line is SNR gain for incoherent:

While certainly correct, I find this graph misleading in practice.

In practice, coherent (or time-domain) averaging reduces the FFT baseline noise floor by 10*log(N), N=number of averages, just the same way the FFT size itself reduced the baseline noise. However, it does not make the noise floor smoother unless a very large number of averages is used (1000 or so).

Spectrum magnitude averaging does not reduce the FFT baseline noise floor at all, it just makes it smoother and cover a smaller level span. A smooth noise floor makes it much easier to identify components peaking out.

Without overlapped FFT-processing the benefit of coherent averaging is minimal/nonexistent. Aquiring 32 coherent averages of a 64k FFT takes just as long (and gives almost the exact same result) as a 2M FFT (64k *32) without any averaging.
However, with large FFT block overlap, like 16x (93.75%), the coherent averaging is much faster as the all the frames except the first are aquired in 1/16th of the time. Overlap is most useful when using narrow windows where large sections of the block have only little impact on the result, basically throwing away the information that would be available there.

But, with 32 coherent averages the smoothness of the noise floor is not great so it is harder to seperate real components from random spikes. I seldom see an improvement larger than 10dB improvement for the "safe" baseline noise floor where components stick out clearly to not get confused with noise. What's missing in current software (@JohnPM) is an option to apply additional magnitude averaging on the output of a silding window of coherent averages. That would really help a lot to reduce the roughness of the noise floor (down low in frequency it will remain rough compared to an equivalent full-size magnitude average, though)

For precision level measurement of components I fount coherent averaging having error bands of +-0.2dB or so whereas magnitude averaging always gives larger than real result (not a bad thing, actually), the closer the component is to the noise floor the larger the error (several dB easily).

 

[pkane]

While certainly correct, I find this graph misleading in practice.

In practice, coherent (or time-domain) averaging reduces the FFT baseline noise floor by 10*log(N), N=number of averages, just the same way the FFT size itself reduced the baseline noise. However, it does not make the noise floor smoother unless a very large number of averages is used (1000 or so).

Spectrum magnitude averaging does not reduce the FFT baseline noise floor at all, it just makes it smoother and cover a smaller level span. A smooth noise floor makes it much easier to identify components peaking out.

Without overlapped FFT-processing the benefit of coherent averaging is minimal/nonexistent. Aquiring 32 coherent averages of a 64k FFT takes just as long (and gives almost the exact same result) as a 2M FFT (64k *32) without any averaging.
However, with large FFT block overlap, like 16x (93.75%), the coherent averaging is much faster as the all the frames except the first are aquired in 1/16th of the time. Overlap is most useful when using narrow windows where large sections of the block have only little impact on the result, basically throwing away the information that would be available there.

But, with 32 coherent averages the smoothness of the noise floor is not great so it is harder to seperate real components from random spikes. I seldom see an improvement larger than 10dB improvement for the "safe" baseline noise floor where components stick out clearly to not get confused with noise. What's missing in current software (@JohnPM) is an option to apply additional magnitude averaging on the output of a silding window of coherent averages. That would really help a lot to reduce the roughness of the noise floor (down low in frequency it will remain rough compared to an equivalent full-size magnitude average, though)

For precision level measurement of components I fount coherent averaging having error bands of +-0.2dB or so whereas magnitude averaging always gives larger than real result (not a bad thing, actually), the closer the component is to the noise floor the larger the error (several dB easily).

The difference is that coherent average of the same signal produces a new signal that sounds exactly like the original, but with greater SNR. If you take multiple loopbacks of the same piece of music and use coherent averaging you can still listen to the result and it will sound just like the original, but will have lower noise floor. You won't recognize an incoherently averaged signal, since all the time/phase information is destroyed in the process. So, it depends a lot on what you're trying to measure as to which one you might want to use.

 

[pkane]

Thinking more about coherent/incoherent averaging, I ran a test. 10 averages, white is coherent (time-aligned), blue is incoherent (amplitude only):

And 20 averages:

 

[JohnPM]

Why are the even harmonic levels and phases changing in the coherently averaged results? Broadly speaking anything with random phase relative to the fundamental will tend to zero in the coherently averaged version (or its mean within the averaging period, which should tend to zero as the averaging is increased). Anything harmonically related shouldn't change.

 

[pkane]

Why are the even harmonic levels and phases changing in the coherently averaged results? Broadly speaking anything with random phase relative to the fundamental will tend to zero in the coherently averaged version (or its mean within the averaging period, which should tend to zero as the averaging is increased). Anything harmonically related shouldn't change.

I think that was the property of how I had my measurement loopback connected (mostly by accident). I had a two channel output from a DAC with one of the input channels inverted feeding an ADC that differentially summed two inputs to mono. This caused even harmonic cancellation, but obviously not exact due to the differences between the two channels.

Here's the same DAC but with a different ADC and no inversion/differential summing:

20 incoherent averages:

And 20 coherent (all harmonics present, and phases seem to match):

 

[JohnPM]

I think that was the property of how I had my measurement loopback connected (mostly by accident). I had a two channel output from a DAC with one of the input channels inverted feeding an ADC that differentially summed two inputs to mono. This caused even harmonic cancellation, but obviously not exact due to the differences between the two channels.

Can't think why that should produce even harmonic residuals with phases that vary relative to the fundamental, which seems to be what the coherent averaging result implies.

 

[pkane]

Can't think why that should produce even harmonic residuals with phases that vary relative to the fundamental, which seems to be what the coherent averaging result implies.

I suspect that a little phase difference between the harmonics in the two channels causes the differential phase to vary between captures. See them dancing:

 

[morillon]

Hello
do you think it will be possible to add the possibility, just like rew, to create test signal wav files?
This will allow you to easily test wifi streamers in multitones etc.
thank you
;-)
ps and possibility of use kaiser 12 or more?
;-)

 

[pkane]

Hello
do you think it will be possible to add the possibility, just like rew, to create test signal wav files?
This will allow you to easily test wifi streamers in multitones etc.
thank you
;-)
ps and possibility of use kaiser 12 or more?
;-)

Hi morillon,

Sure, I’m in the middle of a rewrite of the internals — as I said in the beginning, Multitone was never meant to be released to others, so I took some shortcuts to get the result I wanted Now I decided to take some time and clean up some of those shortcuts.

I can certainly add the ability to save test signals — something I was planning to do anyway.

I intentionally removed some extra FFT window types to simplify user choice. As it is, there are still too many. Why would you want Kaiser 12?

 

[morillon]

just that being able to compare a large number of solutions under virtins I was able to see how much in the cases that interest us the use of kaisers offers much greater readability than what you are presenting...
from the 12th, in all circumstances the results are convincing...

 

[pkane]

just that being able to compare a large number of solutions under virtins I was able to see how much in the cases that interest us the use of kaisers offers much greater readability than what you are presenting...
from the 12th, in all circumstances the results are convincing...

Ok, I’ll experiment some more and add it if it makes a difference.

 

[morillon]

like ....
not many difference with 18
try it...tell me what you see
;-)

I have been here recently...
by no means an expert...
I have the chance to use virtins..
and I admit I do not understand why I see here so many documents with such a low resolution in fft, like jtest of armin....(especially in cases where we can avoid a d/a-a/d conversion ... such as cases of streamer drive etc.)

 

[edechamps]

when I try flexasio and attempt to use settings it crashes the app in Windows 11

Hello, FlexASIO author here. I realize I'm late to the party, but please don't hesitate to reach out to me (either here or on GitHub) if you are experiencing issues with FlexASIO. Incompatibilities between FlexASIO and ASIO apps can be due to bugs in FlexASIO, bugs in the app, or a combination of the two. (Just because it works in REW doesn't mean it's not FlexASIO's fault. Software compatibility is more complicated than that.)

I can help untangle things and discuss it with @pkane if I suspect a bug in his app. Feedback is always welcome as it often results in improvements/bug fixes in FlexASIO, in the ASIO app, or both.

To start with, I would suggest sharing a FlexASIO log that captures the crash. The log will show precisely when the crash is occurring which makes troubleshooting much easier.

 

[pkane]

@Archimago took Multitone for a spin in his recent blog article (second half):

https://archimago.blogspot.com/2022/05/musings-hunt-for-150db-thd-with-victors.html

I'm in the process of a revamping the tool adding new features and improving existing functionality. Here's an example showing different types of averages (amplitude, coherent, and hybrid). Should be available shortly, as I'm just finishing testing all the changes.

 

[morillon]

thank you for all your efforts!

 

[Moto]

@pkane really looking forward to the new averages. Any idea when this version will be available?
@edechamps I sort of lost track of this but will get a log.

 

[pkane]

@pkane really looking forward to the new averages. Any idea when this version will be available?
@edechamps I sort of lost track of this but will get a log.

A day or two. I’ve been spending some time validating the results against all the measurement software I can get my hands on. What makes it more difficult is that almost none produce results that are consistent with the others

 

[Dilettante]

Thank you for the software! One of the very few even a novice like myself can reasonably comprehend.

Few notes:

• "Processing" spinner is drawn over other windows if Multitone analyser is behind of any "normal" window.
• WASAPI / ASIO are sometimes stuck to 44.1KHz, restarting the app helps.

 

[morillon]

Hello
just
had you kept the idea of, such as rew , being able to produce wav files of test signals ... your proposals can be richer, even customizable
will be nice...
;-)