Beta Test: Multitone Loopback Analyzer software

[Music1969]

Did you try to type it?

I hadn't - I assumed we can only choose from the list, like how you can't export 24bit - needs to be 32/64bit

 

[pkane]

I hadn't - I assumed we can only choose from the list, like how you can't export 24bit - needs to be 32/64bit

try typing it. Can't guarantee it'll work, but it may depending on how fast your computer is in processing FFTs.

 

[Music1969]

try typing it. Can't guarantee it'll work, but it may depending on how fast your computer is in processing FFTs.

I only want to save a .WAV file

Does this still need CPU powah?

 

[pkane]

I only want to save a .WAV file

Does this still need CPU powah?

no, that's just for recording.

 

[Music1969]

no, that's just for recording.

For generating offline files, is there any reason it needs to be linked to sample rate of an output device?

Can the offline file generation be independent of devices ?

Sometimes I get crashes when I have to start the recording, to create offline file. Even when I try to stop the recording.

 

[pkane]

For generating offline files, is there any reason it needs to be linked to sample rate of an output device?

Can the offline file generation be independent of devices ?

Sometimes I get crashes when I have to start the recording, to create offline file. Even when I try to stop the recording.

Sure, anything is possible, but the point of Multitone was not to generate test files, but to run loopback tests

 

[Music1969]

Sure, anything is possible, but the point of Multitone was not to generate test files, but to run loopback tests

Noted, but now that it can generate so many cool things, it has overtaken REW .

Maybe you can consider as a feature request to re-do how the test file generator works?

Or spin out a seperate .WAV generator if that's easier?

Only requesting your consideration !

Keep up the great work

 

[pkane]

Update to the preview version 1.0.49:

https://app.box.com/s/qbrh3czrvudclkqs9n8lm806k3hzmjx5

• Some bug fixes for the reported issues
• Added Amplitude Spectrum Density display option (scales spectrum display per sqrt(Hz)) to remove the effect of FFT gain on noise floor
• Added the ability to create new, custom display variables in Results window

To add a new display variable, the logic and the formatting is the same as it is for titles:

https://distortaudio.org/multitone-exp.html

Since this is a somewhat advanced feature, I thought I'd just record a video showing how to use this. Watch most of the action in the Results window:

 

[Rantapossu]

Update to the preview version 1.0.49:

https://app.box.com/s/qbrh3czrvudclkqs9n8lm806k3hzmjx5

• Some bug fixes for the reported issues
• Added Amplitude Spectrum Density display option (scales spectrum display per sqrt(Hz)) to remove the effect of FFT gain on noise floor
• Added the ability to create new, custom display variables in Results window

To add a new display variable, the logic and the formatting is the same as it is for titles:

https://distortaudio.org/multitone-exp.html

Since this is a somewhat advanced feature, I thought I'd just record a video showing how to use this. Watch most of the action in the Results window:

We're not worthy!!!

I am amazed!

 

[Rantapossu]

@pkane Out of 6 bugs I reported: Four are fixed and two are not fixed .

This is one of the old bugs, ENOB is still printed wrongly on the "Results" -window (when using the calibration file). It's correct on the "Spectrum" view:

You don't need to hook up the APU to verify this, only add this calibration file:

20 60 0 20000 60 0

Of course all other values are 60 dB off without the APU, but you can see the ENOB difference between the "Results" -window and "Spectrum" -view easily.

 

[Rantapossu]

@pkane Out of 6 bugs I reported: Four are fixed and two are not fixed .

This is one of the old bugs, ENOB is still printed wrongly on the "Results" -window (when using the calibration file). It's correct on the "Spectrum" view:

View attachment 231470

You don't need to hook up the APU to verify this, only add this calibration file:

20 60 0 20000 60 0

Of course all other values are 60 dB off without the APU, but you can see the ENOB difference between the "Results" -window and "Spectrum" -view easily.

Actually it's only wrong on the first channel (this time it's left) when doing two channel measurements (This time without APU and with -60 dB calibration file):

If you use this:

The bug is on the Right channel:

 

[Rantapossu]

This is the second old bug:

If you change both of the measurement to "none" with the sweeps, it still shows the last graph when there shouldn't be anything visible.

The first measurement is IMD, the second TD+N.

This one is done like this: First the Measurement #1: IMD -> none, then the Measurement #2: TD+N -> none. And TD+N is still visible:

This one is done like this: First the Measurement #2: TD+N -> none, then the Measurement #1: IMD -> none. And IMD is still visible:

 

[pkane]

This is the second old bug:

If you change both of the measurement to "none" with the sweeps, it still shows the last graph when there shouldn't be anything visible.

The first measurement is IMD, the second TD+N.

This one is done like this: First the Measurement #1: IMD -> none, then the Measurement #2: TD+N -> none. And TD+N is still visible:

View attachment 231516

This one is done like this: First the Measurement #2: TD+N -> none, then the Measurement #1: IMD -> none. And IMD is still visible:

View attachment 231517

Thanks for reporting this one. I decided this was not worth a fix. If you want a blank chart — click the red X

 

[Rantapossu]

Is there a way to do the 2 channel calculations or is it still on the development state?

Seems that only the left channel field is editable.

{tdn-60}db is obviously only for the first channel and gives the left channel value for the current right channel and an error for the previous right channel measurement:

{tdn-60}db and {tdn2-60}db give the right values, but I'll have to use two rows and of course there are 4 wrong values visible (the white ones):

 

[Rantapossu]

Is there a way to do the 2 channel calculations or is it still on the development state?

Seems that only the left channel field is editable.

{tdn-60}db is obviously only for the first channel and gives the left channel value for the current right channel and an error for the previous right channel measurement:

View attachment 231533

{tdn-60}db and {tdn2-60}db give the right values, but I'll have to use two rows and of course there are 4 wrong values visible (the white ones):

View attachment 231540

I think that {IF(channelNumber=0, tdn-60, tdn2-60)} should do the trick, but channelNumber gives value "0" for both channels and it shows two times the left channel value.

{IF(channelNumber=1, tdn-60, tdn2-60)} gives two times the right channel value, so the "IF" -conditional statement seems to work ok.

 

[pkane]

I think that {IF(channelNumber=0, tdn-60, tdn2-60)} should do the trick, but channelNumber gives value "0" for both channels and it shows two times the left channel value.

{IF(channelNumber=1, tdn-60, tdn2-60)} gives two times the right channel value, so the "IF" -conditional statement seems to work ok.

I may need to fix this for two channels. The plan was to use the "unnumbered" variables to represent the current channel (1 or 2, or...) and to use variables with a number appended to them to represent only that specific channel. I think I messed that up at the last moment before sending out the update

For example use {tdn} to represent TD+N of the current channel. This will work correctly for channel 1 and 2 or any other, in the future. Use {tdn1} to represent TD+N of channel 1, regardless of which channel result is being displayed, and use {tdn2} to represent the second channel.

Does this make sense? I'll fix this to work like this, ASAP.

 

[Rantapossu]

That would make sense for me.

But you'll need to redo that YouTube video then

 

[pkane]

That would make sense for me.

But you'll need to redo that YouTube video then

Yes, season 2 pilot episode is coming soon

 

[pkane]

A few quick fixes based on @Rantapossu reports: https://app.box.com/s/qbrh3czrvudclkqs9n8lm806k3hzmjx5

Should fix ENOB value is different between channels when applying calibration file. Also adds support for two types of variables:

• Un-numbered refer to the current channel they appear in
• Numbered refer to the result from the that number channel.

{snr} refers to SNR in either channel and will display the result for that channel, {snr1} will always show SNR in channel 1, {snr2} will always show SNR in channel 2.

Video to be updated in the near future

 

[Rantapossu]

Are you sure that you uploaded the correct version?

ENOB is still wrong too: