Beta Test: Multitone Loopback Analyzer software

[pkane]

Thanks for the suggestion, but that did not help.

Rather frustrating. I've rebooted the machine, powered down all the devices and back up. If I change the recording device sample rate using ASIO you have to run it till it hangs. Close it, and then reopen where it has the new sample rate. If you select the new sample rate and close it without running, then it hangs on the first run.

Not sure what's going on, but maybe the log file will give some clues. Run the test one more time, kill MT if if you have to and then restart it. Then, right-click on the MT icon near top right:

You should see notepad open with the log file loaded. Upload the file and I can see if there's anything obvious.

Otherwise, the few things that got me before: having wrong driver selected (in or out), having wrong channels selected, etc. Beyond that, may need to try to reinstall ASIO driver(s).

 

[Music1969]

The algorithm is designed not to place any of the fundamental tones where they would:

• Overlap any of the harmonics from any of the tones
• Overlap any ot the even-order IMD products (2nd, 4th, 6th, 8th, 10th, etc.)
• May reduce overlap with odd order IMD products starting with 3, but will not eliminate these

Thanks, that is definitely what I am looking for !

I was more-so asking if you were confident in the maths itself - or if you wanted to share it for someone to check.

Or if its propriety or you are confident, thats fine of course !

When will this be added to your software to use ?

 

[pkane]

Thanks, that is definitely what I am looking for !

I was more-so asking if you were confident in the maths itself - or if you wanted to share it for someone to check.

Or if its propriety or you are confident, thats fine of course !

When will this be added to your software to use ?

I'll share the algorithm at a later point, as it's still under development. The current version has been tested and absolutely does at least the first two:

• Eliminates overlap of any of the harmonics with any of the tones
• Eliminates overlap of any ot the even-order IMD products (2nd, 4th, 6th, 8th, 10th, etc.)

 

[Music1969]

The current version has been tested and absolutely does at least the first two:

Current version has already been updated to spread the tones more, like you showed?

 

[pkane]

Current version has already been updated to spread the tones more, like you showed?

Not yet.

 

[Blumlein 88]

Okay here is the log file after it hangs where I closed it, reopened, and took the log file.

 

[pkane]

Okay here is the log file after it hangs where I closed it, reopened, and took the log file.

Hmm, the only thing I see (something you had a problem with before) is the driver change processing. Can you try turning it off in settings?

 

[Blumlein 88]

Hmm, the only thing I see (something you had a problem with before) is the driver change processing. Can you try turning it off in settings?
View attachment 230960

Okay that took care of it. I don't know how it got checked. I didn't do it unless it was an errant mouse click. I somehow didn't notice it either. Called myself looking for any changes and missed it.

Thanks.

 

[pkane]

Current version has already been updated to spread the tones more, like you showed?

It's up there now. Please give it a try: https://app.box.com/s/qbrh3czrvudclkqs9n8lm806k3hzmjx5

 

[Music1969]

It's up there now. Please give it a try: https://app.box.com/s/qbrh3czrvudclkqs9n8lm806k3hzmjx5

Works well ! Nicely spread out (not bunched up in any one region)

To the naked eye it looks a lot more 'orderly' than REW's NID tones like I posted

But if you're confident it does those key things you mentioned (to essentially achieve the same as REW's NID tones) then thats all thats needed.

REW only had 16 NID tones between 20-20kHz so maybe thats why it looks less 'orderly' to the naked eye.

 

[pkane]

Works well ! Nicely spread out (not bunched up in any one region)

To the naked eye it looks a lot more 'orderly' than REW's NID tones like I posted

But if you're confident it does those key things you mentioned (to essentially achieve the same as REW's NID tones) then thats all thats needed.

REW only had 16 NID tones between 20-20kHz so maybe thats why it looks less 'orderly' to the naked eye.

View attachment 230986

I don't know what John did to generate the 16 NID multitone, so can't speak to how or why these are differently spread out. Here's the result of my measuring the overlaps of 32 tones in MT:

IMD Order 1: overlap = 0%

IMD Order 2: overlap = 0%

IMD Order 3: overlap = 0.161290322580645%

IMD Order 4: overlap = 0%

IMD Order 5: overlap = 0.119226596019387%

IMD Order 6: overlap = 0%

 

[Music1969]

I don't know what John did to generate the 16 NID multitone, so can't speak to how or why these are differently spread out. Here's the result of my measuring the overlaps of 32 tones in MT:

IMD Order 1: overlap = 0%

IMD Order 2: overlap = 0%

IMD Order 3: overlap = 0.161290322580645%

IMD Order 4: overlap = 0%

IMD Order 5: overlap = 0.119226596019387%

IMD Order 6: overlap = 0%

Looks like your algo does the job !

Thank you !

 

[Music1969]

I don't know what John did to generate the 16 NID multitone

Moreso out of interest than necessity, maybe @JohnPM can share details of the maths for selecting the 16 frequencies for NID tones (20-20kHz)?

How those specific frequencies are selected

If possible

 

[KSTR]

Moreso out of interest than necessity, maybe @JohnPM can share details of the maths for selecting the 16 frequencies for NID tones (20-20kHz)?

How those specific frequencies are selected

If possible

(and to @pkane)
I reverse-engineered a NID MT from REW and extracted the multiplier sequence for a set of 24 tones (you can get more tones by using a high sample rate), and it goes like this
1, 5, 12, 29, 49, 81, 119, 141, 207, 263, 359, 459, 543, 729, 775, 909, 1097, 1213, 1405, 1649, 1853, 2077, 2461, 2653
Obviously, that sequence is the secret sauce and I would be interested in the theory/math behind it as well.

Using the sequence, to span, for example, a 1000:1 range (like 20Hz to 20kHz) you'd use the subset of that list going from 1 to 909 so that all tones are within the range, and that happen to be 16 tones total.
Next, to place them on the actual frequencies within the selected range for the sample rate and FFT size, you need to find a constant bin number multiplier to obtain the FFT frequency numbers from the multiplier sequence.
Say, for a 16k FFT at 48kHz, bin width is 48000/16384 = ~2.93Hz.
20Hz/2.93 = 6.82, so the required constant bin number multiplier is 7.
Thus, the populated FFT bins are:
7*1, 7*5, 7*12, 7*29, 7*49, ...

The constant bin number multiplier gives an interesting feature for the resulting FFT of a device under test, it keeps all the bins in between clean, all IMD components are also at multiplies of this bin frequency. By this, when zooming in, the real noise floor and the IMD component spikes can be much better told apart because of the strictly regular pattern.

 

[JohnPM]

There's actually a typo in the sequence, which I have fixed for the next REW build - the 12 should be 13. The factors are a subset of primes (edit: well, some primes, but all odd) chosen to eliminate inter-harmonics up to 4th order, the work was done by Evans and Rees.

 

[Rantapossu]

This is probably the first inconsistent bug I've found:

The label doesn't update on the "Compare to:" -selector (Test3 -recording here in this example, Test1 and Test2 work fine).

The tricky and inconsistent part is how to make it repeatable:

It never happens on the first recording of the session
Sometimes it doesn't happen even on the second record of the session
Most likely it will happen on the third record of the session and when it kicks in, it will happen every time with a new record until you close MT
Somehow it even depends on your computer. With this computer, it does it every time at least on the third record, with the other I have managed to get 3 times without any problems. I spend at least an hour and didn't solve the exact behaviour.

You can try to replicate the result with this (And as normally debugging my strange bugs, don't skip any steps...)

- Restart MT
- Make a measurement
- Rename it and close the measurement history window
- Make a measurement
- Rename it and close the measurement history window
- Make a measurement
- Rename it and close the measurement history window
- Open the "Compare to:" -selector and check the result.
- If not the result we are searching for, try the 4th time and if still not there, restart MT and start the sequence again.

It will be there, I have seen it tens of times...

 

[Rantapossu]

This bug in the other hand is easy to replicate:

Select a couple of old records to plot:

Press the "Clear" -button:

Open to the "Measurement history" -window:

The selections are still active and it you select another one, all the three selection above will still be selected, but not shown in the plot:

You'll have to manually tick of all the three previous selection to make them unselected.

(The third selected 23:30:19 measurement was recorded with a different FFT size and that's why it's not visible on the first graph, please ignore it, it is not a part of this bug...)

 

[pkane]

There's actually a typo in the sequence, which I have fixed for the next REW build - the 12 should be 13. The factors are a subset of primes (edit: well, some primes, but all odd) chosen to eliminate inter-harmonics up to 4th order, the work was done by Evans and Rees.

Thanks for posting the link, John. I didn't see this paper before, but it does provide an insight into how to improve my algorithm (which is based on a primes sequence).

 

[DonH56]

The various IEEE data converter standards (1057, 1241, 1658) as well as many other online (and free) resources describe how to generate relatively prime sequences for simulation and testing (the standards all focus on testing but the concept is the same). I use that method in all of my programs to maintain independent bins for tones and their (sub and supra) harmonics. Prime numbers should also get you there, I think, but the recipe the IEEE (etc.) uses also lets you choose frequencies related to your sampling rate for simulated and real-world testing without having to worry about binning and windowing, assuming you have enough points in the FFT to get close enough to the desired test tone frequency. I really like not having to window my data.

There used to be a big data converter app note from Analog Devices describing their approach using relatively prime numbers. I can't find it in my files at the moment, may have just a paper copy, it's that old (me too).

It turns out that most of the time if the sampling rate is even and you choose an odd multiplier to get to frequency it will also avoid overlaps. I have gotten lazy in some recent programs and just done that, but it does not always work.

 

[Music1969]

(and to @pkane)
I reverse-engineered a NID MT from REW and extracted the multiplier sequence for a set of 24 tones (you can get more tones by using a high sample rate), and it goes like this
1, 5, 12, 29, 49, 81, 119, 141, 207, 263, 359, 459, 543, 729, 775, 909, 1097, 1213, 1405, 1649, 1853, 2077, 2461, 2653
Obviously, that sequence is the secret sauce and I would be interested in the theory/math behind it as well.

Using the sequence, to span, for example, a 1000:1 range (like 20Hz to 20kHz) you'd use the subset of that list going from 1 to 909 so that all tones are within the range, and that happen to be 16 tones total.
Next, to place them on the actual frequencies within the selected range for the sample rate and FFT size, you need to find a constant bin number multiplier to obtain the FFT frequency numbers from the multiplier sequence.
Say, for a 16k FFT at 48kHz, bin width is 48000/16384 = ~2.93Hz.
20Hz/2.93 = 6.82, so the required constant bin number multiplier is 7.
Thus, the populated FFT bins are:
7*1, 7*5, 7*12, 7*29, 7*49, ...

The constant bin number multiplier gives an interesting feature for the resulting FFT of a device under test, it keeps all the bins in between clean, all IMD components are also at multiplies of this bin frequency. By this, when zooming in, the real noise floor and the IMD component spikes can be much better told apart because of the strictly regular pattern.

Thanks @KSTR @JohnPM @pkane @DonH56

I actually stumbled on this feature in REW when I thought the normal multitone I see used everywhere is too orderly- tones line up with harmonics.

I googled something like "random spacing multitone" and stumbled on REW's manual and saw NID's description looked to be perfect

To me this is one of the more interesting measurements - closer to music (not perfect) than most other popular measurements

The white noise version is a very tough test but perhaps pink noise more representative of music , as it slopes down with increasing frequencies

I'm happy this discussion will actually improve REW and pkanes software - something good came out of my initial silly google search

Maybe @amirm can use this in future