DeltaWave null-testing audio comparator (beta)

[pkane2001]

2 hours ago, Arpiben said:

 

Hi Paul,

 

I did not retrieve the reported behaviour with previous cases: pure tones or audio files.😟

But I have it with the following files. TIE values obtained with several shows: 3.5 ms / 4.4 ms / 5.6 ms / 7.8 ms 

 

A.wav 10.99 MB · 1 download

B.wav 10.99 MB · 1 download

 

Please do not play them !

A :1000 kHz 0 dBFs 

B: 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz

 

DW Jitter estimation seems to be tricked with pure tones. Reported values are not correct for such cases.

With TIE= 1ms instead of 100 ns reported jitter values are: 83400 s / 39560 s

 

Rgds 

 

 

 

Can you please post the expression you use to generate 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz?

 

I'm pretty sure I've fixed the variable jitter value when pressing 'Show' multiple times. The result I get for your A/B files is consistently 4.4ms.

 

[pkane2001]

1 hour ago, pkane2001 said:

 

Can you please post the expression you use to generate 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz?

 

I think I got it, but I'm not getting the huge values for jitter that you posted: 

 

[Arpiben]

3 hours ago, pkane2001 said:

 

Can you please post the expression you use to generate 1000 kHz 0 dBFs + TIE 100 ns sinus 0.1 Hz?

 

I'm pretty sure I've fixed the variable jitter value when pressing 'Show' multiple times. The result I get for your A/B files is consistently 4.4ms.

 

 

A*sin(2*pi*f0*(t+TIE*z(t))

z(t)=sin(2*pi*fjitter*t) -> sinusoïdal jitter

z(t)= Gaussian (-1,1) or other statistical distribution

z(t)=1 for fixed phase error

 

B.wav file was with:

TIE=10E-7

fjitter= 0,1Hz

 

Rgds.

[TomCapraro]

While you were having coffee and thought how to get a great null-test by looping a dac and adc, I started drinking coffee and thinking about myself.😁
Since Paul introduced an alignment function for periodic signals, I created a pseudo-periodic 64k white noise signal.
Activating the alignment function, with this signal, I get an amazing null ... and we see it ...

 

Observe the values ...                                                                       

[TomCapraro]

The settings used ...

[TomCapraro]

And here when I disable the alignment of periodic signals ...

 

 

[TomCapraro]

I couldn't get more than that.
How does it look like?
Do you want me to place the signal so you can try it too?

[pkane2001]

1 hour ago, TomCapraro said:

I couldn't get more than that.
How does it look like?
Do you want me to place the signal so you can try it too?

 

Sure, please post them!

 

I also have an idea for implementing a different clock drift correction functionality for the periodic signal analysis. This may help with DAC/ADC loopback analysis using sine waves and other simple, repetitive functions.

 

[TomCapraro]

1 hour ago, pkane2001 said:

 

Sure, please post them!

 

I also have an idea for implementing a different clock drift correction functionality for the periodic signal analysis. This may help with DAC/ADC loopback analysis using sine waves and other simple, repetitive functions.

 

This is the original signal that you will have to try in loopback

White_PN_64k_20_20000_96.0k_Float_LR.wav

[TomCapraro]

ZzZzZzZzZ.....😁

[Arpiben]

ZzZzZz no no no....😉

 

Hi Paul,

 

For keeping everyone awake here are a few minor remarks:

 

1 Jitter metric:

Reading your explanation about how it is calculated, a few posts back, I realized that when dealing with certain waveforms, the reported value may not relate to any physical rms Jitter. Nevertheless, the metric is very useful for improving any alignment.

I even tried it with rectangular functions but those are, in principle , not encountered in audio 😊

"A*sign(sin(2*pi*f0*(t+TIE*z(t)))"

 

Jitter metric measures the difference between two waveforms as an error in timing. Existing measures, such as RMS difference and correlated null are both related to the magnitude of the amplitude error, although correlated null is also related to timing.

This new measure computes an RMS timing error between the two waveforms. Assuming the amplitudes of the two waveforms are perfectly matched, this number would be the actual RMS jitter. Reported in seconds (microseconds, nanoseconds, picoseconds). The smaller the number, the smaller the overall match error. In effect, that's another number that can be used to judge the quality of the match.

 

2. Memory issues:

Trying to DW oversample big files ( 50 million samples)  leads to probable memory issues.

To be honest with such sizes I am also having issues with Python 😊

 

Stopped! Array dimensions exceeded supported range.

 

 

3. THD:

It seems that the Harmonic reported values (H1 ,H3, H5,...) are scaled with different parameters that the ones currently set: windowing, FFT size,...

I was expecting to retrieve more or less the levels shown in spectra but this is not the case.

 

4 Curve Overlay:

The curve overlay is static, meaning that one needs to keep same curve parameters before and after.

 

Rgds.

[pkane2001]

5 hours ago, Arpiben said:

ZzZzZz no no no....😉

 

Hi Paul,

 

For keeping everyone awake here are a few minor remarks:

 

1 Jitter metric:

Reading your explanation about how it is calculated, a few posts back, I realized that when dealing with certain waveforms, the reported value may not relate to any physical rms Jitter. Nevertheless, the metric is very useful for improving any alignment.

I even tried it with rectangular functions but those are, in principle , not encountered in audio 😊

"A*sign(sin(2*pi*f0*(t+TIE*z(t)))"

 

Jitter metric measures the difference between two waveforms as an error in timing. Existing measures, such as RMS difference and correlated null are both related to the magnitude of the amplitude error, although correlated null is also related to timing.

This new measure computes an RMS timing error between the two waveforms. Assuming the amplitudes of the two waveforms are perfectly matched, this number would be the actual RMS jitter. Reported in seconds (microseconds, nanoseconds, picoseconds). The smaller the number, the smaller the overall match error. In effect, that's another number that can be used to judge the quality of the match.

 

2. Memory issues:

Trying to DW oversample big files ( 50 million samples)  leads to probable memory issues.

To be honest with such sizes I am also having issues with Python 😊

 

Stopped! Array dimensions exceeded supported range.

 

 

3. THD:

It seems that the Harmonic reported values (H1 ,H3, H5,...) are scaled with different parameters that the ones currently set: windowing, FFT size,...

I was expecting to retrieve more or less the levels shown in spectra but this is not the case.

 

4 Curve Overlay:

The curve overlay is static, meaning that one needs to keep same curve parameters before and after.

 

Rgds.

 

Hi Arpiben,

 

1. RMS Jitter is computed as the timing difference between samples in Reference and Comparison files. In effect, the calculation takes into account the timing difference of all the individual samples. So, yes, this metric is different than the usual jitter measurements, but it's also much more accurate, at least in theory 

 

2. Large files will be a problem due to memory constraints. This is not something I can address in the near future, as that will require significant restructuring of the logic and data handling in DW. You can always trim the file by skipping some seconds or minutes from the front or the end  of the file in DW to reduce the number of samples kept in memory.

 

3. I'll have to check, but the values for H1... H9 should be scaled the same as on the FFT chart. If they are not, this is likely a bug.

 

4. Curve overlay requires the same FFT size for both, the current, and the overlay charts. If the FFT size is different, a proper comparison would require resampling the frequency data which I didn't want to do. It's not hard, so if you can make an argument for why this might be important, I might add it

 

Regards,

 

    -Paul

 

 

 

[pkane2001]

7 hours ago, TomCapraro said:

ZzZzZzZzZ.....😁

 

I know, I know... No major new features or releases in a couple of weeks. Sorry! 

 

I've been spending my time testing a new metric - non-linearity. Trying to see if this is something that can be usefully measured from the complex music recordings or possibly from frequency/amplitude sweeps.

 

Here's a non-linearity plot derived from a music recording using DW. Units will have to be adjusted, but this is starting to look promising. 

 

 

[Arpiben]

1 hour ago, pkane2001 said:

 

Hi Arpiben,

 

1. RMS Jitter is computed as the timing difference between samples in Reference and Comparison files. In effect, the calculation takes into account the timing difference of all the individual samples. So, yes, this metric is different than the usual jitter measurements, but it's also much more accurate, at least in theory 

 

2. Large files will be a problem due to memory constraints. This is not something I can address in the near future, as that will require significant restructuring of the logic and data handling in DW. You can always trim the file by skipping some seconds or minutes from the front or the end  of the file in DW to reduce the number of samples kept in memory.

 

3. I'll have to check, but the values for H1... H9 should be scaled the same as on the FFT chart. If they are not, this is likely a bug.

 

4. Curve overlay requires the same FFT size for both, the current, and the overlay charts. If the FFT size is different, a proper comparison would require resampling the frequency data which I didn't want to do. It's not hard, so if you can make an argument for why this might be important, I might add it

 

Regards,

 

    -Paul

 

 

 

 

1.&2. Ok.

4. No argument from my side just got tricked once or twice but now I know. 😉

 

3. Reading and calculating THD directly from spectrum chart is giving much closer results vs theory.

Ex. rectangular wave -> THD= 0,483 or -6.31 dB with all harmonics (around 0.38 up to H9) 

 

Thanks & Regards Paul.

[TomCapraro]

1 hour ago, pkane2001 said:

 

I know, I know... No major new features or releases in a couple of weeks. Sorry! 

 

I've been spending my time testing a new metric - non-linearity. Trying to see if this is something that can be usefully measured from the complex music recordings or possibly from frequency/amplitude sweeps.

 

Here's a non-linearity plot derived from a music recording using DW. Units will have to be adjusted, but this is starting to look promising. 

 

 

Can you learn more about the non-linearity of the recordings?
Thanks again Paul.

[TomCapraro]

2 hours ago, pkane2001 said:

 

 

1. RMS Jitter is computed as the timing difference between samples in Reference and Comparison files. In effect, the calculation takes into account the timing difference of all the individual samples. So, yes, this metric is different than the usual jitter measurements, but it's also much more accurate, at least in theory 

 

Regards,

 

    -Paul

 

 

 

Question Paul, in your opinion since you wrote that the jitter measured by DW takes into account the time difference between the samples of the reference and comparison file, and given that with the use of a pseudoperiodic signal I got 32.2ps, do you think that did the measured jitter cover the entire length of the file (about 22 seconds), or did it take the RMS difference of the period formed by 65536 samples?
This question arises from the fact that with that signal the function of alignment of the periodic signals has brought improvements both in the difference spectrum and in the very low value of the jitter.

[pkane2001]

1 hour ago, TomCapraro said:

Can you learn more about the non-linearity of the recordings?
Thanks again Paul.

 

If you have the original digital file and the one that passed through the DAC/ADC loop, then yes. It's the non-linearity of the DAC/ADC process that this can measure.

[pkane2001]

1 hour ago, TomCapraro said:

Question Paul, in your opinion since you wrote that the jitter measured by DW takes into account the time difference between the samples of the reference and comparison file, and given that with the use of a pseudoperiodic signal I got 32.2ps, do you think that did the measured jitter cover the entire length of the file (about 22 seconds), or did it take the RMS difference of the period formed by 65536 samples?
This question arises from the fact that with that signal the function of alignment of the periodic signals has brought improvements both in the difference spectrum and in the very low value of the jitter.

 

The jitter measurement is using the whole file, not just one FFT frame. If there are 5 million samples in a file, each of the 5 million samples will contribute to the RMS jitter value.

[TomCapraro]

Very clear, thanks Paul.
Very interesting is the measurement of the conversion process D / A-A / D, I think it is one of the things I am most interested in.
One could assess which dac or adc worsens the process.
I will not sleep at night if I do not implement the function now😊

[TomCapraro]

Is the linearity test set with corrections? or will it be an automatic process function?
Since there are linear order differences (amplitude-response in frequency) and non-linear order differences (thd, jitter, imd, noise) will the algorithm linearize the linear part from the non-linear part?

[pkane2001]

15 minutes ago, TomCapraro said:

Is the linearity test set with corrections? or will it be an automatic process function?
Since there are linear order differences (amplitude-response in frequency) and non-linear order differences (thd, jitter, imd, noise) will the algorithm linearize the linear part from the non-linear part?

 

Yes, the process can measure both. I’m not yet at the point where I tried correcting for these distortions, but I don’t see any reason why this shouldn’t work.

 

Sorry, you may be not getting much sleep for a while if you wait for this new feature, I’m still at the early stages of research.

 

[TomCapraro]

The software is also excellent, that will be the icing on the cake😏

[esldude]

Here is what I get using TomCaproro's modulated white noise signal using a loopback vs a loopback a few minutes later.  This is about what I get using music the same way. 

 

 

I get good result comparing the loopback vs the original, but not as good as Tom is getting.  I also don't get the low picosecond jitter that way.  Though I get that low jitter comparing two loopbacks. 

 

A signal I was working on with similar thinking behind it is 997 hz at -6 db mixed with white noise at -6 db.  That actually worked a little better for me.  Here is that signal comparing original to loopback.  

 

[esldude]

Here is an interesting result using the 32 multi-tone test signal Amir uses from the AP test company.   This is the original vs loopbacked result. 

 

[vortecjr]

1 hour ago, esldude said:

Here is an interesting result using the 32 multi-tone test signal Amir uses from the AP test company.   This is the original vs loopbacked result. 

 

Can you post a link to the source file used in this test?