DeltaWave null-testing audio comparator (beta)

[fas42]

Net connection has big problems, so excuse minimal responses. Terrific work, Paul, the UA1000 sample looks good, for me; but the AuroraN24 wave shows inconsistent results - I can only process about 40 secs, and if I use the first 40s the match is extremely poor, 30dB nulls; but use the end 40s - then the match is excellent. 

[pkane2001]

Interesting result comparing generation 1 to Generation 8 of DA/AD loop of Bob Marley track posted by Dennis.

 

Seems that once phase is corrected for, Generation 1 is extremely similar to Generation 8. Slightly worse null, and slightly greater jitter. The effect of repeated filter application is obvious in the spectra comparison, and an obviously greater clock drift is measured in the 8th generation. Once these are corrected for, the remaining differences are very small, indeed. 

 

[mansr]

Once you compensate for all the differences, no difference remains.

[pkane2001]

4 minutes ago, fas42 said:

Net connection has big problems, so excuse minimal responses. Terrific work, Paul, the UA1000 sample looks good, for me; but the AuroraN24 wave shows inconsistent results - I can only process about 40 secs, and if I use the first 40s the match is extremely poor, 30dB nulls; but use the end 40s - then the match is excellent. 

 

With nonlinear EQ options, the number of samples used becomes very important. DW is computing an average of large-size FFT spectra, so if only a few of these can fit into the measured track, the noise will overwhelm the signal resulting in a poor correction.

[pkane2001]

22 minutes ago, mansr said:

Once you compensate for all the differences, no difference remains.

 

But that’s the point of DeltaWave -- to measure and to explain the differences. If no more differences remain, then they were all detected and reported. Goal reached 

 

[fas42]

Playing with the AuroraN24 file, I managed to get up to 70 secs to process - this memory scraper is good! - there was a 'magic' point at which the nulling hit 60dB, when 60 secs, from the start of the track, was input - but then worsened past this point. So complex aspects of the waveform and its envelope play a part as to how well DW can EQ the phase - would be interesting to get a better handle on this.

 

Doing this, a minor bug popped up - trying to trim up to 0.3 secs from the start of the Compare track did nothing; at 0.4 secs the trim function started to work.

[mansr]

9 hours ago, pkane2001 said:

But that’s the point of DeltaWave -- to measure and to explain the differences. If no more differences remain, then they were all detected and reported. Goal reached 

Sure, but is the decomposition of the difference necessarily correct and meaningful? Suppose you run a sine sweep through something exhibiting a frequency-dependent phase shift. The result is indistinguishable from clock drift. What does your program report in this case?

 

I'm not saying your tool isn't useful. You just need to be careful interpreting the results.

[pkane2001]

1 hour ago, mansr said:

Sure, but is the decomposition of the difference necessarily correct and meaningful? Suppose you run a sine sweep through something exhibiting a frequency-dependent phase shift. The result is indistinguishable from clock drift. What does your program report in this case?

 

I'm not saying your tool isn't useful. You just need to be careful interpreting the results.

 

That's fair. There's only so much information available in the processed signal. If two different actions lead to the same exact result, DW will report as the one that's more likely to have been applied. 

[Arpiben]

On 7/11/2019 at 4:14 AM, pkane2001 said:

Folks, please try a new version of DeltaWave, v1.0.34.

 

This version implements a different way of correcting for phase error that seems to work much better. Resulting phase looks clean and nearly perfect to me. But please, let me know what you find.

 

Some examples (check the null and jitter values, as well):

 

 

 

 

Hi Paul,

 

I am having some new issues with DW's latest release 1.035b.

 

With Phase EQ enabled and some tests files.  SHOW -> Stopped! Index was outside the bounds of the array.

 

at Wave.Analysis.FitPhaseCurve(Double[] x, Double[] y, Complex[] spectrum, Int32 sz, Int32 freq, Double[]& poly) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 0
   at Wave.Analysis.ApplyFreqCalibrationComplex(Double[]& LL, Double[]& L1, Int32 freq, Int32 size, Int32 cutoff, Double[]& polynomial, Int32& last_freq, Func`2& func) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 2240
   at Wave.WaveForm.ProcessAll(Double[] L, Double[] L1, Int32 freq, Int32 freq1, Int32 freq2, Int32 bits1, Int32 bits2, Boolean bMatch, Boolean bLoadOnly, Boolean bApplyManual, Boolean bUpdateCharts) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\WaveForm.cs:line 2416
2019-07-12 00:59:49.0550|INFO|Wave.WaveForm|Stopped! Index was outside the bounds of the array.
2019-07-12 00:59:49.0550|DEBUG|Wave.WaveForm|Progress Stopped!, , 100% 

 

The above is not happening with DW R1.034 & same test files.I am interested in the possible reason for such ( not enough samples/etc).

 

Well my files are dealing with real TIE measurements;i.e: very low wander/jitter& drift (  ~1ns/~1ppb/day).

I applied the TIE to a single tone and very well know that DW's clock correction doesn't work with such signals.

Later I will apply them to other functions and check them with DW.

I am only surprised that DW allows MATCH to provide much worst results than original without control or warning.

 

As a side remark:

In standards, 10 Hz is the line between Jitter and Wander. A HP filter applied to phase reveals Jitter (Noise) while a LP filter applied to phase reveals wander. Wander or the phase long term variations allow to estimate and correct the clock 'long' term issues ( t>0.1s)

Dealing with audio files, I have no idea if the 10 Hz value can be kept for LP=HP frequency cut. If not 100 Hz could be a good candidate.

Rgds.

 

 

[pkane2001]

37 minutes ago, Arpiben said:

 

Hi Paul,

 

I am having some new issues with DW's latest release 1.035b.

 

With Phase EQ enabled and some tests files.  SHOW -> Stopped! Index was outside the bounds of the array.

 

at Wave.Analysis.FitPhaseCurve(Double[] x, Double[] y, Complex[] spectrum, Int32 sz, Int32 freq, Double[]& poly) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 0
   at Wave.Analysis.ApplyFreqCalibrationComplex(Double[]& LL, Double[]& L1, Int32 freq, Int32 size, Int32 cutoff, Double[]& polynomial, Int32& last_freq, Func`2& func) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\Analysis.cs:line 2240
   at Wave.WaveForm.ProcessAll(Double[] L, Double[] L1, Int32 freq, Int32 freq1, Int32 freq2, Int32 bits1, Int32 bits2, Boolean bMatch, Boolean bLoadOnly, Boolean bApplyManual, Boolean bUpdateCharts) in C:\Users\ypa\Documents\Visual Studio 2015\Projects\Wave\Wave\WaveForm.cs:line 2416
2019-07-12 00:59:49.0550|INFO|Wave.WaveForm|Stopped! Index was outside the bounds of the array.
2019-07-12 00:59:49.0550|DEBUG|Wave.WaveForm|Progress Stopped!, , 100% 

 

The above is not happening with DW R1.034 & same test files.I am interested in the possible reason for such ( not enough samples/etc).

 

Well my files are dealing with real TIE measurements;i.e: very low wander/jitter& drift (  ~1ns/~1ppb/day).

I applied the TIE to a single tone and very well know that DW's clock correction doesn't work with such signals.

Later I will apply them to other functions and check them with DW.

I am only surprised that DW allows MATCH to provide much worst results than original without control or warning.

 

As a side remark:

In standards, 10 Hz is the line between Jitter and Wander. A HP filter applied to phase reveals Jitter (Noise) while a LP filter applied to phase reveals wander. Wander or the phase long term variations allow to estimate and correct the clock 'long' term issues ( t>0.1s)

Dealing with audio files, I have no idea if the 10 Hz value can be kept for LP=HP frequency cut. If not 100 Hz could be a good candidate.

Rgds.

 

 

 

Hi Arpiben,

 

What size file are you processing and what FFT size did you select for Phase EQ? If you can post the text from the Results tab, that'll help me troubleshoot.

 

Generally, DW tries to detect any part of the process that goes off the rails. In some cases it writes the error to the Results tab, in others it displays a message to the user, when the error is too large. It also writes a lot more detail to the log, if you turn on logging. If the error is not obvious or large in any one step, DW may not report it at all. I can add a check to ensure that the Match results don't make the initial null values worse, but in some cases, the null might be somewhat worse, while the overall match might be better, so it would be a warning rather than an error.

 

With Wander vs Jitter distinction, I'm not sure there's a value to computing these separately for audio. From DW perspective, these are the same -- both are the result of timing errors. In fact, I hesitated to call this value Jitter (I did it only because that made for a shorter screen label . In the results list, I call it a timing error). It represents an RMS timing error over all the samples in the file. The value is computed in the time domain,  so separating it into under 10Hz and over 10Hz values will take more work and processing time. Do you see a value to doing this, other than conforming to a naming convention? I'd rather change the label, then

 

 

[Arpiben]

1 hour ago, pkane2001 said:

 

Hi Arpiben,

 

What size file are you processing and what FFT size did you select for Phase EQ? If you can post the text from the Results tab, that'll help me troubleshoot.

 

Generally, DW tries to detect any part of the process that goes off the rails. In some cases it writes the error to the Results tab, in others it displays a message to the user, when the error is too large. It also writes a lot more detail to the log, if you turn on logging. If the error is not obvious or large in any one step, DW may not report it at all. I can add a check to ensure that the Match results don't make the initial null values worse, but in some cases, the null might be somewhat worse, while the overall match might be better, so it would be a warning rather than an error.

 

With Wander vs Jitter distinction, I'm not sure there's a value to computing these separately for audio. From DW perspective, these are the same -- both are the result of timing errors. In fact, I hesitated to call this value Jitter (I did it only because that made for a shorter screen label . In the results list, I call it a timing error). It represents an RMS timing error over all the samples in the file. The value is computed in the time domain,  so separating it into under 10Hz and over 10Hz values will take more work and processing time. Do you see a value to doing this, other than conforming to a naming convention? I'd rather change the label, then

 

 

 

Troubleshooting:

 

1.035b with Phase EQ Enabled: (same behaviour for smaller FFT sizes 4096 for instance)

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T15:11:33.1914654+02:00
Reference:  A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: True
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:True

Discarding Reference:  Start=0s, End=10s
Discarding Comparison: Start=0s, End=10s

Initial peak values Reference: 0dB   Comparison: 0dB
Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

Null Depth=44,048dB
Stopped! Index was outside the bounds of the array.
Signature: 927dc3938d8b2ef0ffa840afa1c6ab02

 

1.035b with Phase EQ Disabled:

 

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T15:25:54.7967053+02:00
Reference:  A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:True

Discarding Reference:  Start=0s, End=10s
Discarding Comparison: Start=0s, End=10s

Initial peak values Reference: 0dB   Comparison: 0dB
Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

Null Depth=44,048dB

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

Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,28dBA]
Clock drift: 0 ppm

 

Jitter/Wander distinction:

 

Honestly, I don't care about wording distinction, already used with it. The point is without proper filtering, I am afraid that in some cases, one might not be able to correct the phase variations. A few posts back you already pointed out some differences with phase for frequencies above or below 1 kHz.

The following picture may be more explicit, just replace the 24 Hour window by a 5 min one ( or typical average audio file length) 

 

 

 

The test files are based from TIE phase measurement dedicated equipment such as Annue 3500/Oscilloquartz/Symmetricom. 

Obviously I am realistic and don't expect DW to reach such precision. My point is to compare real clock phase measurements (low and high jitter) with DW. This will only cover the frequency drift/offset correction and not the Phase EQ ( Group Delay from the different transfer functions:filters,etc...) 😉

 

Rgds.

 

 

 

[Arpiben]

Hi Paul,

 

Just notice that in the working case my pasted text was incomplete, sorry.

Here is the complete one:

Nothing to complain about the phase estimation. 😊

Rgds.

 

1.035b with Phase EQ Disabled:

Performing raw processing only -- all matching turned off
DeltaWave v1.0.35, 2019-07-12T17:25:43.7253820+02:00
Reference:  A.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Comparison: B.wav[L] 106496 samples 3000Hz 32bits, mono, MD5=00
Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:4096, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:16384
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:True

Discarding Reference:  Start=0s, End=10s
Discarding Comparison: Start=0s, End=10s

Initial peak values Reference: 0dB   Comparison: 0dB
Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

Null Depth=44,048dB

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

Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,13dBA]
Clock drift: 0 ppm

Files are NOT a bit-perfect match (match=100%) at 16 bits
Files are NOT a bit-perfect match (match=83,74%) at 32 bits
Files match @ 100% when reduced to 12,5 bits

---- Phase difference (full bandwidth): 4,33363026596958E-05°
    0-10kHz: 0,00°
    0-20kHz: 0,00°
    0-24kHz: 0,00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -217,121670899852dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: ab0aff5adad46408e9b5bdb788e5289a

[Arpiben]

@pkane2001

 

Paul, no need to waste your time with previous errors. Despite the fact that curves were properly presented ( with my files ) in releases 1.033 & 1.034, errors were already there. At the end, no need to worry about and 1.035 have no regression at this level.

Rgds.

 

Log with DW v1.033:

 

2019-07-12 19:13:33.9923|DEBUG|Wave.WaveForm|Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: True
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:65536
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:True

2019-07-12 19:13:34.0334|INFO|Wave.WaveForm|Discarding Reference:  Start=0s, End=10s
2019-07-12 19:13:34.0485|INFO|Wave.WaveForm|Discarding Comparison: Start=0s, End=10s
2019-07-12 19:13:34.1206|INFO|Wave.WaveForm|
Initial peak values Reference: 0dB   Comparison: 0dB
2019-07-12 19:13:34.1367|INFO|Wave.WaveForm|Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

2019-07-12 19:13:34.1517|INFO|Wave.WaveForm|Null Depth=44,048dB
2019-07-12 19:13:34.1598|DEBUG|Wave.WaveForm|Progress Updating Charts, , 20%
2019-07-12 19:17:27.6192|INFO|Wave.WaveForm|FitPhaseCurve error (rms): linear=9,37757332651059E+151deg
2019-07-12 19:17:27.6348|ERROR|Wave.WaveForm|FitPhaseCurve error too large: linear=1,63669530394807E+150
2019-07-12 19:17:27.6348|ERROR|Wave.WaveForm|ApplyFreqCalibrationComplex: FitPhaseCurve failed
2019-07-12 19:17:27.6348|DEBUG|Wave.WaveForm|Progress Computing results, , 82%
2019-07-12 19:17:27.6348|INFO|Wave.WaveForm|
Trimmed 0 samples ( 0,00ms) front, 0 samples ( 0,00ms end)

2019-07-12 19:17:27.7130|DEBUG|Wave.WaveForm|Progress Computing results, , 85%
2019-07-12 19:17:27.8867|DEBUG|Wave.WaveForm|Progress Computing results, , 87%
2019-07-12 19:17:27.9007|DEBUG|Wave.WaveForm|Progress Computing results, , 90%
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,22dBA]
Clock drift: 0 ppm
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|

2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Files are NOT a bit-perfect match (match=100%) at 16 bits
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Files are NOT a bit-perfect match (match=83,74%) at 32 bits
2019-07-12 19:17:27.9639|INFO|Wave.WaveForm|Files match @ 100% when reduced to 12,5 bits
2019-07-12 19:17:27.9639|INFO|Wave.WaveForm|

2019-07-12 19:17:27.9719|DEBUG|Wave.WaveForm|Progress Updating charts, , 91%
2019-07-12 19:17:28.1744|INFO|Wave.WaveForm|---- Phase difference (full bandwidth): 1,80098071837204E-05°
2019-07-12 19:17:28.2125|INFO|Wave.WaveForm|    0-10kHz: 0,00°
2019-07-12 19:17:28.2456|INFO|Wave.WaveForm|    0-20kHz: 0,00°
2019-07-12 19:17:28.2787|INFO|Wave.WaveForm|    0-24kHz: 0,00°
2019-07-12 19:17:28.2837|INFO|Wave.WaveForm|Phase EQ not computed
2019-07-12 19:17:28.3579|INFO|Wave.WaveForm|Timing error (rms jitter): 0sec
2019-07-12 19:17:28.3660|DEBUG|Wave.WaveForm|Progress Updating charts, , 94%
2019-07-12 19:17:28.3770|DEBUG|Wave.WaveForm|Progress Updating charts, , 96%
2019-07-12 19:17:28.3770|DEBUG|Wave.WaveForm|Progress Updating charts, , 98%
2019-07-12 19:17:28.4332|INFO|Wave.WaveForm|
RMS of the difference of spectra: -229,851134440609dB
2019-07-12 19:17:41.4353|INFO|Wave.WaveForm|gn=1, dc=0, dr=0, of=0

2019-07-12 19:17:41.4493|INFO|Wave.WaveForm|DONE!

2019-07-12 19:17:41.4574|DEBUG|Wave.WaveForm|Progress [NOT Bit Perfect ] 83,74% Gain matching disabled. Phase offset=0ms Difference (rms) = -176,3dB [-178,69dBA] Correlated Null Depth=44,05dB [210,22dBA] Clock drift: 0 ppm, , 100%
2019-07-12 19:17:41.4574|INFO|Wave.WaveForm|Signature: 1ab5be21ec3cec9510f3874762dd16d0
 

[pkane2001]

6 minutes ago, Arpiben said:

@pkane2001

 

Paul, no need to waste your time with previous errors. Despite the fact that curves were properly presented ( with my files ) in releases 1.033 & 1.034, errors were already there. At the end, no need to worry about and 1.035 have no regression at this level.

Rgds.

 

Log with DW v1.033:

 

2019-07-12 19:13:33.9923|DEBUG|Wave.WaveForm|Settings: 
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: True
    EQ FFT Size:524288, EQ Frequency Cut: 0Hz - 384000Hz, EQ Threshold: -300dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:BlackmanHarris, Spectrum Size:65536
    Spectrogram Window:Lanczos, Spectrogram Size:32768, Spectrogram Steps:1024
    Dither:False
    Trim Silence:True

2019-07-12 19:13:34.0334|INFO|Wave.WaveForm|Discarding Reference:  Start=0s, End=10s
2019-07-12 19:13:34.0485|INFO|Wave.WaveForm|Discarding Comparison: Start=0s, End=10s
2019-07-12 19:13:34.1206|INFO|Wave.WaveForm|
Initial peak values Reference: 0dB   Comparison: 0dB
2019-07-12 19:13:34.1367|INFO|Wave.WaveForm|Initial RMS values Reference: -3,01dB   Comparison: -3,01dB

2019-07-12 19:13:34.1517|INFO|Wave.WaveForm|Null Depth=44,048dB
2019-07-12 19:13:34.1598|DEBUG|Wave.WaveForm|Progress Updating Charts, , 20%
2019-07-12 19:17:27.6192|INFO|Wave.WaveForm|FitPhaseCurve error (rms): linear=9,37757332651059E+151deg
2019-07-12 19:17:27.6348|ERROR|Wave.WaveForm|FitPhaseCurve error too large: linear=1,63669530394807E+150
2019-07-12 19:17:27.6348|ERROR|Wave.WaveForm|ApplyFreqCalibrationComplex: FitPhaseCurve failed
2019-07-12 19:17:27.6348|DEBUG|Wave.WaveForm|Progress Computing results, , 82%
2019-07-12 19:17:27.6348|INFO|Wave.WaveForm|
Trimmed 0 samples ( 0,00ms) front, 0 samples ( 0,00ms end)

2019-07-12 19:17:27.7130|DEBUG|Wave.WaveForm|Progress Computing results, , 85%
2019-07-12 19:17:27.8867|DEBUG|Wave.WaveForm|Progress Computing results, , 87%
2019-07-12 19:17:27.9007|DEBUG|Wave.WaveForm|Progress Computing results, , 90%
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Gain matching disabled.
Phase offset=0ms (0 samples)
Difference (rms) = -176,3dB [-178,69dBA]
Correlated Null Depth=44,05dB [210,22dBA]
Clock drift: 0 ppm
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|

2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Files are NOT a bit-perfect match (match=100%) at 16 bits
2019-07-12 19:17:27.9428|INFO|Wave.WaveForm|Files are NOT a bit-perfect match (match=83,74%) at 32 bits
2019-07-12 19:17:27.9639|INFO|Wave.WaveForm|Files match @ 100% when reduced to 12,5 bits
2019-07-12 19:17:27.9639|INFO|Wave.WaveForm|

2019-07-12 19:17:27.9719|DEBUG|Wave.WaveForm|Progress Updating charts, , 91%
2019-07-12 19:17:28.1744|INFO|Wave.WaveForm|---- Phase difference (full bandwidth): 1,80098071837204E-05°
2019-07-12 19:17:28.2125|INFO|Wave.WaveForm|    0-10kHz: 0,00°
2019-07-12 19:17:28.2456|INFO|Wave.WaveForm|    0-20kHz: 0,00°
2019-07-12 19:17:28.2787|INFO|Wave.WaveForm|    0-24kHz: 0,00°
2019-07-12 19:17:28.2837|INFO|Wave.WaveForm|Phase EQ not computed
2019-07-12 19:17:28.3579|INFO|Wave.WaveForm|Timing error (rms jitter): 0sec
2019-07-12 19:17:28.3660|DEBUG|Wave.WaveForm|Progress Updating charts, , 94%
2019-07-12 19:17:28.3770|DEBUG|Wave.WaveForm|Progress Updating charts, , 96%
2019-07-12 19:17:28.3770|DEBUG|Wave.WaveForm|Progress Updating charts, , 98%
2019-07-12 19:17:28.4332|INFO|Wave.WaveForm|
RMS of the difference of spectra: -229,851134440609dB
2019-07-12 19:17:41.4353|INFO|Wave.WaveForm|gn=1, dc=0, dr=0, of=0

2019-07-12 19:17:41.4493|INFO|Wave.WaveForm|DONE!

2019-07-12 19:17:41.4574|DEBUG|Wave.WaveForm|Progress [NOT Bit Perfect ] 83,74% Gain matching disabled. Phase offset=0ms Difference (rms) = -176,3dB [-178,69dBA] Correlated Null Depth=44,05dB [210,22dBA] Clock drift: 0 ppm, , 100%
2019-07-12 19:17:41.4574|INFO|Wave.WaveForm|Signature: 1ab5be21ec3cec9510f3874762dd16d0
 

 

Well, I did find some issues based on your logs. Phase EQ was being applied even though Match operation was not selected, and that was causing an error. I fixed this in 1.0.36, and also added an automatic FFT size selector for files that are too short. DW will now reduce FFT size when needed by the phase EQ operation.

 

Your files are fairly short, so I'd definitely recommend longer files and larger FFT size for EQ, if possible.

 

 

[fas42]

Hmmm ... getting multiple problems in DW32, v.36: with Phase EQ disabled, got a "Stopped! Index was outside the bounds of the array." message with one combo of completely dissimilar files; the Manual Corrections function is broken - NullReferenceException error thrown, and window has no results; and in v.34 when using Man. Corr., which worked fine, some displays weren't updated, the Delta ones being most obvious.

[pkane2001]

20 hours ago, fas42 said:

Hmmm ... getting multiple problems in DW32, v.36: with Phase EQ disabled, got a "Stopped! Index was outside the bounds of the array." message with one combo of completely dissimilar files; the Manual Corrections function is broken - NullReferenceException error thrown, and window has no results; and in v.34 when using Man. Corr., which worked fine, some displays weren't updated, the Delta ones being most obvious.

 

That's strange, Frank. I tested all those functions before posting, and the changes I made didn't seem to involve any of the things you're reporting. Just tested again, and still can't seem to break it. The null reference exception may actually be an indication of an out-of-memory condition that's likely with the 32-bit version. Can you please post the results text, so I can see where things went wrong?

 

[fas42]

Paul, the key one is that the Manual Corrections function brings up an error, as soon as invoked from the Process menu,

 

 

This was with a trivial, 18k WAV file, being compared to itself; the Results tab shows nothing unusual,

 

DeltaWave v1.0.36, 2019-07-14T11:26:59.3840000+10:00
Reference:  Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Comparison: Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:32768, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:32768
    Spectrogram Window:Hann, Spectrogram Size:4096, Spectrogram Steps:2048
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -11.743dB   Comparison: -11.743dB
Initial RMS values Reference: -21.341dB   Comparison: -21.341dB

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

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

Final peak values Reference: -11.743dB   Comparison: -11.743dB
Final RMS values Reference: -21.341dB   Comparison: -21.341dB

Gain= 0dB (1x) DC=0 Phase offset=0ms (0 samples)
Difference (rms) = -337.47dB [-373.07dBA]
Correlated Null Depth=316.23dB [306.1dBA]
Clock drift: 0 ppm

Files are a bit-perfect match at 16 bits

---- Phase difference (full bandwidth): 2.2039886273441E-11°
    0-10kHz: 0.00°
    0-20kHz: 0.00°
    0-24kHz: 0.00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -431.677877789612dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: e360cb18a97225d5889f06cb62c9909b

[pkane2001]

32 minutes ago, fas42 said:

Paul, the key one is that the Manual Corrections function brings up an error, as soon as invoked from the Process menu,

 

 

This was with a trivial, 18k WAV file, being compared to itself; the Results tab shows nothing unusual,

 

DeltaWave v1.0.36, 2019-07-14T11:26:59.3840000+10:00
Reference:  Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Comparison: Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:32768, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:32768
    Spectrogram Window:Hann, Spectrogram Size:4096, Spectrogram Steps:2048
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -11.743dB   Comparison: -11.743dB
Initial RMS values Reference: -21.341dB   Comparison: -21.341dB

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

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

Final peak values Reference: -11.743dB   Comparison: -11.743dB
Final RMS values Reference: -21.341dB   Comparison: -21.341dB

Gain= 0dB (1x) DC=0 Phase offset=0ms (0 samples)
Difference (rms) = -337.47dB [-373.07dBA]
Correlated Null Depth=316.23dB [306.1dBA]
Clock drift: 0 ppm

Files are a bit-perfect match at 16 bits

---- Phase difference (full bandwidth): 2.2039886273441E-11°
    0-10kHz: 0.00°
    0-20kHz: 0.00°
    0-24kHz: 0.00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -431.677877789612dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: e360cb18a97225d5889f06cb62c9909b

 

Thank you, Frank. Strange, but it looks like the package I'm using to create the installer is what's causing this particular problem. It doesn't happen before the installer package is created. I'll re-do the installer from scratch and re-upload 1.0.36. That should fix the problem.

 

[pkane2001]

26 minutes ago, fas42 said:

Paul, the key one is that the Manual Corrections function brings up an error, as soon as invoked from the Process menu,

 

 

This was with a trivial, 18k WAV file, being compared to itself; the Results tab shows nothing unusual,

 

DeltaWave v1.0.36, 2019-07-14T11:26:59.3840000+10:00
Reference:  Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Comparison: Windows XP Ding.wav[L] 8544 samples 22050Hz 16bits, mono, MD5=00
Settings:
    Gain:True, Remove DC:True
    Non-linear Gain EQ:False    Non-linear Phase EQ: False
    EQ FFT Size:32768, EQ Frequency Cut: 0Hz - 0Hz, EQ Threshold: -160dB
    Correct Drift:True, Precision:30
    Non-Linear drift Correction:False
    Upsample:False, Window:Hann
    Spectrum Window:Hann, Spectrum Size:32768
    Spectrogram Window:Hann, Spectrogram Size:4096, Spectrogram Steps:2048
    Dither:False
    Trim Silence:False

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

Initial peak values Reference: -11.743dB   Comparison: -11.743dB
Initial RMS values Reference: -21.341dB   Comparison: -21.341dB

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

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

Final peak values Reference: -11.743dB   Comparison: -11.743dB
Final RMS values Reference: -21.341dB   Comparison: -21.341dB

Gain= 0dB (1x) DC=0 Phase offset=0ms (0 samples)
Difference (rms) = -337.47dB [-373.07dBA]
Correlated Null Depth=316.23dB [306.1dBA]
Clock drift: 0 ppm

Files are a bit-perfect match at 16 bits

---- Phase difference (full bandwidth): 2.2039886273441E-11°
    0-10kHz: 0.00°
    0-20kHz: 0.00°
    0-24kHz: 0.00°
Timing error (rms jitter): 0sec

RMS of the difference of spectra: -431.677877789612dB
gn=1, dc=0, dr=0, of=0

DONE!

Signature: e360cb18a97225d5889f06cb62c9909b

 

OK, new version has been uploaded. It's still 1.0.36, so you'll need to uninstall the previous version from Windows Control panel before installing this new one. Manual Adjustment window should display without errors.

[fas42]

Fast work, I'm impressed !! ...

[fas42]

And lookin' good ... the not updating display of graphs when using Manual Corrections is still occurring, but is inconsistent, so far. Appears to happen when the results don't change, but not always - I'll see if a pattern emerges, over time.

[fas42]

A peculiar one - unless I'm doing something 'wrong' - applying filtering before and after processing yields a very poor match,

 

 

Using either Filter 1, or Filter 2, alone, as set above, works as expected, giving very good nulls.

[pkane2001]

8 hours ago, fas42 said:

A peculiar one - unless I'm doing something 'wrong' - applying filtering before and after processing yields a very poor match,

 

 

Using either Filter 1, or Filter 2, alone, as set above, works as expected, giving very good nulls.

 

A 15kHz high-pass filter will certainly eliminate most of the recognizable musical content from the file. What remains is noise, filter stop-band, and a few remnants of the real audio signal. Higher frequencies exhibit higher phase noise, so I would expect timing error/correlated-null to be worse when using them to compute a null, as compared to when lower frequencies are included. But that doesn't explain why applying the two filters independently would produce a very different result, so let me test this and I'll get back to you.

 

 

 

 

[pkane2001]

8 hours ago, fas42 said:

A peculiar one - unless I'm doing something 'wrong' - applying filtering before and after processing yields a very poor match,

 

 

Using either Filter 1, or Filter 2, alone, as set above, works as expected, giving very good nulls.

 

Ah, that's a bug! Thanks for finding it, Frank. If there are two HP or two LP filters selected, the logic applies the most drastic of the two filters before and after processing, ignoring the pre- and post- selection. When using a mix of HP and LP filters, the logic works as expected... I'll fix this ASAP.

[modmix]

Comparing the same file gives "NOT Bit Perfect" with Non-Linear Calibration either EQ selected (see attached image).

No Non-Linear Calibration or Non-linear Drift Correction results in "BIT PERFECT!"

Any explanation?
TIA
Ulli