Beta Test: Multitone Loopback Analyzer software

[Rantapossu]

Anyway,the use case is very limited so I leave it alone

You can play the correctly generated 16-bit test tone with the external 16-bit device and record it with your E-MU as 24/44 with no problems, if you want.

 

[Sokel]

You can play the correctly generated 16-bit test tone with the external 16-bit device and record it with your E-MU as 24/44 with no problems, if you want.

That's how I generated it.

 

[Rantapossu]

Could it be the 24-bit dither, does it affect to the savings too?

 

[Rantapossu]

You can use this too:

"The Audio Test File Generator"

 

[Sokel]

You can use this too:

"The Audio Test File Generator"

That's the generated files all the way from 16 to 32.
It can be something wrong with me,I don't know.

 

[Sokel]

And that's a nice 32-192.

 

[Rantapossu]

This is my 16/44.1:

(Test file generated with: http://www.tropicalcoder.com/AudioTestFileGen.htm )

 

[Sokel]

This is my 16/44.1:

(Test file generated with: http://www.tropicalcoder.com/AudioTestFileGen.htm )

View attachment 222878

Yep,much cleaner.Thank you!

 

[Grooved]

That's how I generated it.

View attachment 222873

Could it be the 24-bit dither, does it affect to the savings too?

Yes, the dither setting in REW is applied to saved file. You should use dither equal or lower to the format:

- 16bit file with 16bit dither:

- 24bit file with 16bit dither:

- 16bit file with 24bit dither:

 

[Sokel]

Yes, the dither setting in REW is applied to saved file. You should use dither equal or lower to the format:

- 16bit file with 16bit dither:
View attachment 222904

- 24bit file with 16bit dither:
View attachment 222905

- 16bit file with 24bit dither:
View attachment 222906

Yes,now works well with Rew files too! (generated with 16bit dither)
Thank you!

(they also look nice in the RTA)

 

[JohnPM]

Also, it is quite common for ASIO drivers to use int32LSB as transport format, even if the underlying hardware is 24-bit only (e.g. SPDIF)

Probably the issue. The only way I have found to get clean conversions with the typically encountered 24-bit data in a 32-bit format is to treat the data as 24-bit. If it gets treated as 32-bit you end up with a truncation of your output data when the bottom byte gets discarded with the artefacts that generates and conversion problems and harmonic artefacts on your input data if it is converted using a scale factor for 32-bit. Even then it is possible to encounter odd issues if a frequency is used which has an integer number of samples in its period, since the effects of the repeated pattern of truncations may not be fully eliminated by the dither at some gains. 1 kHz is an awkward choice of digital test tone because of that, better to use 997 Hz or 999 Hz.

 

[Grooved]

Probably the issue. The only way I have found to get clean conversions with the typically encountered 24-bit data in a 32-bit format is to treat the data as 24-bit. If it gets treated as 32-bit you end up with a truncation of your output data when the bottom byte gets discarded with the artefacts that generates and conversion problems and harmonic artefacts on your input data if it is converted using a scale factor for 32-bit. Even then it is possible to encounter odd issues if a frequency is used which has an integer number of samples in its period, since the effects of the repeated pattern of truncations may not be fully eliminated by the dither at some gains. 1 kHz is an awkward choice of digital test tone because of that, better to use 997 Hz or 999 Hz.

I just tested 997kHz in Multitone with 24bit, 24bit+24bit dither, 32floating point and 32bit.
Is it because of the truncation you're talking about that results are different, especially between both 24 and both 32?

24bit no dither:

24bit+24bit dither:

32floating point:

32bit:

 

[KSTR]

@Grooved , are you using ASIO?
Because I see what I call the "conversion artifact bug" in all of your four plots, the one I've shown above in my plots when using ASIO.

24bit with no dither should have looked like this:

The -300dB "holes" at certain FFT bins are a good indicator whether undithered data gets handled properly.

And 24bit with dither it should look like this:

The dithering evens out the baseline noise floor as expected. Harmonics are again all below intrinsic processing noise.

I can only get this perfect pureness with WASAPI/exlusive.

 

[KSTR]

Probably the issue. The only way I have found to get clean conversions with the typically encountered 24-bit data in a 32-bit format is to treat the data as 24-bit. If it gets treated as 32-bit you end up with a truncation of your output data when the bottom byte gets discarded with the artefacts that generates and conversion problems and harmonic artefacts on your input data if it is converted using a scale factor for 32-bit. Even then it is possible to encounter odd issues if a frequency is used which has an integer number of samples in its period, since the effects of the repeated pattern of truncations may not be fully eliminated by the dither at some gains. 1 kHz is an awkward choice of digital test tone because of that, better to use 997 Hz or 999 Hz.

Exploring this, I find MT seems to always use a bin center (even when not selecting rectangular window). Therefore the repeat length of a sine at any of those bin typically will be the full 2^k FFT size and thus avoids the 1kHz@48kHz problem of only 48 sample values ever used. Exceptions are bins numbers (=number of periods in FFT-blocksize) matching 2^n at which sequence length is reduced by a corresponding factor. These are a fractional frequencies so little chance we use them by accident, plus it looks like MT only uses the integer part of a user-defined test frequency.

Now the nice thing is that MT can use arbitrary FFT sizes and by that we have full control over the period length and sample distribution, as well as getting exact frequencies even though on a bin center.

To illustrate, 441Hz sine with FFT size of 44100:

Artifacts appear as the repeat length is very short (100 samples). Note the exact output frequency.

The same but changing the test frequency to 442Hz, the artifacts disapear as 442 is not a divisor of 44100:

Basically we are getting artifacts whenever using a frequency which is a divisor of the sample rate , for example 960Hz @ 48kHz:

==> as we can see, we need to apply some extra tricks to coax MT into putting out compromised test signals.
With any of the common 2^n preset FFT sizes a 1kHz sine @ 48kHz is safe as 1kHz is not the actual test frequency

 

[pkane]

Exploring this, I find MT seems to always use a bin center (even when not selecting rectangular window). Therefore the repeat length of a sine at any of those bin typically will be the full 2^k FFT size and thus avoids the 1kHz@48kHz problem of only 48 sample values ever used. Exceptions are bins numbers (=number of periods in FFT-blocksize) matching 2^n at which sequence length is reduced by a corresponding factor. These are a fractional frequencies so little chance we use them by accident, plus it looks like MT only uses the integer part of a user-defined test frequency.

Now the nice thing is that MT can use arbitrary FFT sizes and by that we have full control over the period length and sample distribution, as well as getting exact frequencies even though on a bin center.

To illustrate, 441Hz sine with FFT size of 44100:
View attachment 223013
Artifacts appear as the repeat length is very short (100 samples). Note the exact output frequency.

The same but changing the test frequency to 442Hz, the artifacts disapear as 442 is not a divisor of 44100:
View attachment 223015

Basically we are getting artifacts whenever using a frequency which is a divisor of the sample rate , for example 960Hz @ 48kHz:
View attachment 223017

==> as we can see, we need to apply some extra tricks to coax MT into putting out compromised test signals.
With any of the common 2^n preset FFT sizes a 1kHz sine @ 48kHz is safe as 1kHz is not the actual test frequency

I could, of course, support fractional frequencies in the generator selector. Not sure if that's of a value to an average user, though.

Looking at this low-level performance issue, here's a WASAPI recording (digital loopback) on the same computer. REW generator was used, dithered to 24 bits and locked to 256k FFT, Chebyshev 200 window used for both:

The same signal (REW generated) recorded by MT

 

[JohnPM]

I don't see that in the V5.20.9 release or later builds, which version are you using Paul?

 

[pkane]

I don't see that in the V5.20.9 release or later builds, which version are you using Paul?

5.20.7, it would appear. Let me update and try again.

 

[KSTR]

Looking at this low-level performance issue, here's a WASAPI recording (digital loopback) on the same computer. REW generator was used, dithered to 24 bits and locked to 256k FFT, Chebyshev 200 window used for both:

Hhm, not sure I do understand this, REW has only JAVA or ASIO.
Anyway, cross-recording didn't work for me with either configuration, MT-->REW or REW-MT, see post #830, always got the artifacts in the recorder application even when the simultanueous recording in the program that ran the generator was 100% OK.

Important note on the issues seen in that post #830. There is no change when I use MT's own generated signal saved to file (32bit, with 64 it's working OK)
WASAPI/ex creates the familiar artifacts when left at 0dB during playback. Any other gain always gives correct result (as long as I don't clip).
The source file is clean when throwing it a REW.
==> MT's import seems to do something odd... which is fixed with a small gain change (for WASAPI, at least)

And time to report two other quirks:
- external test signal file is not reloaded even re-selecting it... making it awkward to test variations of the test signal with the same name. I have to load a different file, start measurement, abort it, and finally reload the test file.
- the red "sample-rates doesn't match" info is never cleared when sample rate does match again.

 

[pkane]

Hhm, not sure I do understand this, REW has only JAVA or ASIO.
Anyway, cross-recording didn't work for me with either configuration, MT-->REW or REW-MT, see post #830, always got the artifacts in the recorder application even when the simultanueous recording in the program that ran the generator was 100% OK.

Important note on the issues seen in that post #830. There is no change when I use MT's own generated signal saved to file (32bit, with 64 it's working OK)
WASAPI/ex creates the familiar artifacts when left at 0dB during playback. Any other always gain gives correct result (as long as I don't clip).
The source file is clean whan throwing it a REW.
==> MT's import seems to do something odd... which is fixed with a small gain change (for WASAPI, at least)

And time to report two other quirks:
- external test signal file is not reloaded even re-selecting it... making it awkward to test variations of the test signal with the same name. I have to load a different file, start measurement, abort it, and finally reload the test file.
- the red "sample-rates doesn't match" info is never cleared when sample rate does match again.

REW played using FlexASIO driver into digital loopback driver. Multitone was recording over WASAPi, same driver.

 

[JohnPM]

NP. I've been back and forth on conversions lately trying (and failing) to find a universal solution, so for the next build I have added a check box to control whether 32-bit data should be treated as 24-bit or not since there are some situations where resolution can be higher than 24-bit. Progress is also being made (with Pavel Hofman's generous help) on direct WASAPI exclusive support