DeltaWave null-testing audio comparator (beta)

[TomCapraro]

I did a further test to confirm that the alignment of version 1.0.28 works as well as version 1.0.26.
I extracted the DELTA file of both and analyzed the FFT on my spectrum analyzers, the result is identical.
The problem with version 1.0.28 only concerns the FFT display error, so I tell Paul not to focus on the alignment, that is fine ... he will just have to double-check the FFT amplitude match.

[esldude]

47 minutes ago, TomCapraro said:

I did a further test to confirm that the alignment of version 1.0.28 works as well as version 1.0.26.
I extracted the DELTA file of both and analyzed the FFT on my spectrum analyzers, the result is identical.
The problem with version 1.0.28 only concerns the FFT display error, so I tell Paul not to focus on the alignment, that is fine ... he will just have to double-check the FFT amplitude match.

Yes, I think my results were the same to 2 decimal places.  I know it was at least the same to 1 decimal place.  There is just an FFT display error. 

[pkane2001]

18 hours ago, esldude said:

I'm seeing the same problem as Tom. 

 

I compared one set of interconnects vs another.  Difference rms was -98 db.  In .26 this displays using a 2 k FFT as mostly lying between -115 and -120.  Doing this in .28 I get pretty much identical results on all the parameters.  But displaying the spectrum of delta now shows most of the spectrum around -72 db.  Like Tom an over 40 db difference.  And clearly too high for the results.  

 

So it is working, but the displayed FFT has a problem somewhere.  Results are fine, other displays are fine, but the spectrum of delta isn't right. 

 

Are the null values different as well, or is this just a problem with the FFT display?

[Arpiben]

@pkane2001

 

Hi Paul,

I don't understand how is drift / frequency offset corrected in cases like :

I was expecting to have the red corrected drift not straight after  ~1:47.

 

The Clock Drift window is still only refreshed in case of new drift correction applied or a close/open sequence in DW.

 

Rgds.

 

 

  

[esldude]

1 hour ago, pkane2001 said:

 

Are the null values different as well, or is this just a problem with the FFT display?

Here is first version .26 and then .28 screenshots.  The correlated nulls in the newer version are just a little better, but don't match the spectrum displayed.  So I would say it is an FFT display issue only. 

 

[pkane2001]

1 hour ago, Arpiben said:

@pkane2001

 

Hi Paul,

I don't understand how is drift / frequency offset corrected in cases like :

I was expecting to have the red corrected drift not straight after  ~1:47.

 

The Clock Drift window is still only refreshed in case of new drift correction applied or a close/open sequence in DW.

 

Rgds.

 

 

  

 

Hi Arpiben,

 

It's possible that the cross-correlation computation is thrown off if the offset becomes too large. This would happen more towards the end of the track, since the error keeps increasing from left to right. DeltaWave tries to ignore large outliers when computing drift value, and so corrects for the drift despite the large apparent error at the end.

 

Once corrected, all the offsets fall within measurable range, and so the final, corrected drift is flat. DW corrects for linear drift only, so any jumps that disappear between raw and corrected plots are usually due to the error being too large in the raw measurement.

 

 

 

[pkane2001]

1 hour ago, esldude said:

Here is first version .26 and then .28 screenshots.  The correlated nulls in the newer version are just a little better, but don't match the spectrum displayed.  So I would say it is an FFT display issue only. 

 

 

Thank you. Yes, that's strange. I'll have to review my changes to the spectrum plot in the last couple of versions.

[Arpiben]

8 minutes ago, pkane2001 said:

 

Hi Arpiben,

 

It's possible that the cross-correlation computation is thrown off if the offset becomes too large. This would happen more towards the end of the track, since the error keeps increasing from left to right. DeltaWave tries to ignore large outliers when computing drift value, and so corrects for the drift despite the large apparent error at the end.

 

Once corrected, all the offsets fall within measurable range, and so the final, corrected drift is flat. DW corrects for linear drift only, so any jumps that disappear between raw and corrected plots are usually due to the error being too large in the raw measurement.

 

 

 

 

Thanks. I found this behaviour when dealing with @Archimago different DACs files ( C&D).

IMO the drift curves are a bit misleading at the end even though the spectrum induced artefacts are clearly visible once drift correction is applied.

[pkane2001]

7 minutes ago, Arpiben said:

 

Thanks. I found this behaviour when dealing with @Archimago different DACs files ( C&D).

IMO the drift curves are a bit misleading at the end even though the spectrum induced artefacts are clearly visible once drift correction is applied.

 

Yes, unfortunately the method used to determine drift relies on the drift value not being excessive. In Archimago's tests, I found some tracks that had absolute phase flipped at different points in the file due to the large drift value. DW usually puts a note into the results summary when it detects this condition. I'll try to come up with a better way to do this without using cross-correlation.

[fas42]

Hallo !! What's going on here !? ... I was idly examining the comparison of Paul R's vinyl captures, and found these artifacts, in the Matched panel,

 

 

 

Of course the matching is very poor, because these are 2 distinct needle drops - and the prompt for using the alternative drift method was shown, which I said No to - but it gave these fairly regularly spaced jumps in the comparison waveform, only.

 

 

Results panel:

DeltaWave v1.0.28, 2019-05-17T21:27:46.7441291+10:00
Reference:  Etude In G Flat Major(192).wav[L] 2416640 samples 192000Hz 32bits, stereo, MD5=00
Comparison: Etude In G Flat Major(44.1~192)wav.wav[L] 2402304 samples 192000Hz 32bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:262144, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:Blackman, Spectrum Size:524288
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=50s
Discarding Comparison: Start=0s, End=48.2s

Initial peak values Reference: -24.598dB   Comparison: -24.516dB
Initial RMS values Reference: -39.846dB   Comparison: -39.68dB

Null Depth=18.449dB
X-Correlation offset: -3 samples
Drift computation quality, #1: Excellent (0.69μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -24.598dB   Comparison: -24.616dB
Final RMS values Reference: -39.84dB   Comparison: -40.024dB

Gain= 0.101dB (1.0117x) DC=0 Phase offset=-0.044683ms (-8.579 samples)
Difference (rms) = -39.93dB [-41.63dBA]
Correlated Null Depth=29.15dB [29.48dBA]
Clock drift: -124.18 ppm

Files are NOT a bit-perfect match (match=0.13%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 49.9875% when reduced to 6.78 bits

RMS of the difference of spectra: -72.3253449210009dB
gn=0.988443477510982, dc=0, dr=-0.000124180393, of=-8.5790526495

DONE!

Signature: 533a46dec359f59f99093ddd4eeff352

[Arpiben]

On 5/17/2019 at 2:13 PM, fas42 said:

Hallo !! What's going on here !? ... I was idly examining the comparison of Paul R's vinyl captures, and found these artifacts, in the Matched panel,

 

 

 

Of course the matching is very poor, because these are 2 distinct needle drops - and the prompt for using the alternative drift method was shown, which I said No to - but it gave these fairly regularly spaced jumps in the comparison waveform, only.

 

 

Results panel:

DeltaWave v1.0.28, 2019-05-17T21:27:46.7441291+10:00
Reference:  Etude In G Flat Major(192).wav[L] 2416640 samples 192000Hz 32bits, stereo, MD5=00
Comparison: Etude In G Flat Major(44.1~192)wav.wav[L] 2402304 samples 192000Hz 32bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:262144, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:Blackman, Spectrum Size:524288
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=50s
Discarding Comparison: Start=0s, End=48.2s

Initial peak values Reference: -24.598dB   Comparison: -24.516dB
Initial RMS values Reference: -39.846dB   Comparison: -39.68dB

Null Depth=18.449dB
X-Correlation offset: -3 samples
Drift computation quality, #1: Excellent (0.69μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -24.598dB   Comparison: -24.616dB
Final RMS values Reference: -39.84dB   Comparison: -40.024dB

Gain= 0.101dB (1.0117x) DC=0 Phase offset=-0.044683ms (-8.579 samples)
Difference (rms) = -39.93dB [-41.63dBA]
Correlated Null Depth=29.15dB [29.48dBA]
Clock drift: -124.18 ppm

Files are NOT a bit-perfect match (match=0.13%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 49.9875% when reduced to 6.78 bits

RMS of the difference of spectra: -72.3253449210009dB
gn=0.988443477510982, dc=0, dr=-0.000124180393, of=-8.5790526495

DONE!

Signature: 533a46dec359f59f99093ddd4eeff352

 

As previously mentioned by Paul, DW' s drift correction seems not to perform well when dealing with big values.

Another method/strategy has to be implemented for such cases.The current alternative correction, when proposed, is not helping.

Look at the phase amplitude ( before drift correction) in  Paul R' s captures. 

 

[fas42]

Drift correction shouldn't lead to abrupt transitions in level, one sample to the next, which weren't in the original waveform. Doing manual corrections doesn't alter these anomalies; they still regularly occur, in the displayed waveform.

[pkane2001]

10 hours ago, fas42 said:

Drift correction shouldn't lead to abrupt transitions in level, one sample to the next, which weren't in the original waveform. Doing manual corrections doesn't alter these anomalies; they still regularly occur, in the displayed waveform.

 

Drift correction can't introduce or fix sudden jumps in drift value. That's because the correction is linear, the drift is adjusted by the same amount at every sample. 

[pkane2001]

On 5/17/2019 at 8:13 AM, fas42 said:

Hallo !! What's going on here !? ... I was idly examining the comparison of Paul R's vinyl captures, and found these artifacts, in the Matched panel,

 

 

 

Of course the matching is very poor, because these are 2 distinct needle drops - and the prompt for using the alternative drift method was shown, which I said No to - but it gave these fairly regularly spaced jumps in the comparison waveform, only.

 

 

Results panel:

DeltaWave v1.0.28, 2019-05-17T21:27:46.7441291+10:00
Reference:  Etude In G Flat Major(192).wav[L] 2416640 samples 192000Hz 32bits, stereo, MD5=00
Comparison: Etude In G Flat Major(44.1~192)wav.wav[L] 2402304 samples 192000Hz 32bits, stereo, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain:False    EQ FFT Size:262144, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Upsample:False, Window:Hann
    Spectrum Window:Blackman, Spectrum Size:524288
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:False

Discarding Reference:  Start=0s, End=50s
Discarding Comparison: Start=0s, End=48.2s

Initial peak values Reference: -24.598dB   Comparison: -24.516dB
Initial RMS values Reference: -39.846dB   Comparison: -39.68dB

Null Depth=18.449dB
X-Correlation offset: -3 samples
Drift computation quality, #1: Excellent (0.69μs)

Trimmed 0 samples ( 0.00ms) front, 0 samples ( 0.00ms end)

Final peak values Reference: -24.598dB   Comparison: -24.616dB
Final RMS values Reference: -39.84dB   Comparison: -40.024dB

Gain= 0.101dB (1.0117x) DC=0 Phase offset=-0.044683ms (-8.579 samples)
Difference (rms) = -39.93dB [-41.63dBA]
Correlated Null Depth=29.15dB [29.48dBA]
Clock drift: -124.18 ppm

Files are NOT a bit-perfect match (match=0.13%) at 16 bits
Files are NOT a bit-perfect match (match=0%) at 32 bits
Files match @ 49.9875% when reduced to 6.78 bits

RMS of the difference of spectra: -72.3253449210009dB
gn=0.988443477510982, dc=0, dr=-0.000124180393, of=-8.5790526495

DONE!

Signature: 533a46dec359f59f99093ddd4eeff352

 

Frank,

 

As I said before, there are very large differences in phase between the two recordings. Enough to cause absolute phase to be inverted on some parts of the waveform, but not on others. That's something that cannot be measured or corrected properly using the current drift-correction algorithm: it can't deal with such large differences between two waveforms, and that's why you received the message about the error being too large. The alternate drift correction ignores all other portions of the recording and just measures the drift between the first few seconds and the last few seconds of the recording. Apparently, that's also not working well in this case due to the same large differences.

 

As I said in answer to Arpiben, I'll think about an alternative way to match up the waveforms in case of such large differences. But, this will take some thinking and experimentation, as I'm not aware of an existing method that will work as well as cross-correlation for most 'reasonable' cases.

[pkane2001]

Version 1.0.29b is now available for download. This version fixes the FFT/Spectrogram plot scaling issue introduced in the previous release.

 

 

 

[Arpiben]

@pkane2001

As an alternate way you may consider correcting the drift between beginning and the point of phase slope change ( instead of end ).

Rgds.

[fas42]

4 hours ago, pkane2001 said:

 

Frank,

 

As I said before, there are very large differences in phase between the two recordings. Enough to cause absolute phase to be inverted on some parts of the waveform, but not on others. That's something that cannot be measured or corrected properly using the current drift-correction algorithm: it can't deal with such large differences between two waveforms, and that's why you received the message about the error being too large. The alternate drift correction ignores all other portions of the recording and just measures the drift between the first few seconds and the last few seconds of the recording. Apparently, that's also not working well in this case due to the same large differences.

 

As I said in answer to Arpiben, I'll think about an alternative way to match up the waveforms in case of such large differences. But, this will take some thinking and experimentation, as I'm not aware of an existing method that will work as well as cross-correlation for most 'reasonable' cases.

 

I've got a funny feeling that what I'm talking about is being missed - look carefully at the comparison waveform in what I posted, in the Aligned Waveforms panel: there are 3 precise points where there is an abupt jump in the level; which do not exist at all in the Raw Waveforms plot. This is not a "phase reversal", this is a distortion introduced by DW.

[pkane2001]

58 minutes ago, fas42 said:

 

I've got a funny feeling that what I'm talking about is being missed - look carefully at the comparison waveform in what I posted, in the Aligned Waveforms panel: there are 3 precise points where there is an abupt jump in the level; which do not exist at all in the Raw Waveforms plot. This is not a "phase reversal", this is a distortion introduced by DW.

 

That's what I was talking about, Frank. When computing drift for Paul's two captures, the computed drift value is too large. This is due to the significant differences between the two waveforms. Correcting for such a large drift results in significant interpolation jumps, sometimes between just a few samples. That's just a side-effect of too large a drift correction. 

[fas42]

Okay, my understanding of how DW works was not sufficient to 'see' how that could occur - got it.

 

But, a bigger problem ... still with 1.0.28b, but I doubt 1.0.29b resolves it - the Manual Corrections panel is still stuffing up. Used a 200 LP @start, and not quite repeatable, the offset setting is ignored - the right number is displayed, but the matching is completely out. Even then selecting the original, first result line and applying fails to resynch.

[fas42]

Another glitch, I'm afraid ... zoomed in, time axis set to samples; initiated another Match, results came up as expected, with Original and Matched showing correct, zoomed in waveforms. Changed time axis to mins/secs, and the Original panels are now duplicates of the Matched panels displays

[pkane2001]

12 hours ago, fas42 said:

Another glitch, I'm afraid ... zoomed in, time axis set to samples; initiated another Match, results came up as expected, with Original and Matched showing correct, zoomed in waveforms. Changed time axis to mins/secs, and the Original panels are now duplicates of the Matched panels displays

 

That's a known issue, since only the results of the match are stored in memory. The original waveforms are lost after a match is run. You'll have to re-run the match to see the originals.

[fas42]

19 hours ago, pkane2001 said:

 

That's a known issue, since only the results of the match are stored in memory. The original waveforms are lost after a match is run. You'll have to re-run the match to see the originals.

 

Yes, I should have remembered that you said this in another context. Perhaps the tabs for Original, etc, should be closed if any operation means that this data is no longer available; to eliminate any confusion.

[Arpiben]

@pkane2001

Sorry for that, but I am still struggling with the following:

1. Phase Difference in Result tab
2. Clock drift curves result when dr=0 ( drift correction not applied ).

In 1., the values are not in accordance with delta phase graph.

In 2. , what is the meaning of the drift corrected curve if correction not applied? 

Do you mind elaborating? Thanks.

       

[pkane2001]

26 minutes ago, Arpiben said:

@pkane2001

Sorry for that, but I am still struggling with the following:

1. Phase Difference in Result tab
2. Clock drift curves result when dr=0 ( drift correction not applied ).

In 1., the values are not in accordance with delta phase graph.

In 2. , what is the meaning of the drift corrected curve if correction not applied? 

Do you mind elaborating? Thanks.

       

 

Delta phase plot is the actual phase difference from the two waveforms after they are matched. A simple subtraction of phase angles for each of the FFT frequency bins.

 

Drift plot is the measurement of phase offset through a correlation and phase offset measurement on different parts of the waveform.

 

[Arpiben]

12 minutes ago, pkane2001 said:

 

Delta phase plot is the actual phase difference from the two waveforms after they are matched. A simple subtraction of phase angles for each of the FFT frequency bins.

 

Drift plot is the measurement of phase offset through a correlation and phase offset measurement on different parts of the waveform.

 

 

When curves are not matched delta phase and phase values in result tab have discrepancies. Not a big deal, but I would like to understand why. In Result tab phase is provided for a range 0 Hz- 10 kHz for example. Result may be 0.2° when inband phase noise can have values greater than 5° or more. Result may be 0.2° when delta phase curve indicates 0.5° at 10.000 kHz. 

 

Drift plot shows corrected red curve when no correction applied in Result tab or logs, why?

Ex: