DeltaWave null-testing audio comparator (beta)

[pkane2001]

2 hours ago, fas42 said:

Note the peculiar "Files match @ 79% when reduced to 23.94 bits" detail.

 

Yes, I need to fix that. When the files match better than 50%, the calculation goes wonky since it's trying to compute how many (fewer) bits are needed to reach 50% match, which can't possibly happen since it's already better than 50%. I guess I never expected files to match so well 

 

[pkane2001]

8 hours ago, Arpiben said:

 

That was my first assumption.

In fact it seems related to Mono/Stereo files... With a mono Audacity chirp, DW read the correct samples value when set with Right or Left+Right channel. With Left setting in DW, I got samples discrepancy. Anyhow still not fully clear why?

I think I see the problem... With mono files, there is no Right or Left channel, and no L+R mix-down possible

It's a bug that DW is trying to process channels that are not there, but then you probably shouldn't be selecting them. I'll put in a check for this condition.

[TomCapraro]

7 hours ago, pkane2001 said:

 

For the new files you uploaded, here's what I get:

 

 

This is the actual waveform that is produced by subtracting the two files. The single number, -82dB or -95dBA represents an RMS (root-mean-square) of all the values in the delta waveform. It's an average.

 

Based on the RMS value, It looks like the values were produced from a 16-bit waveform. Is this correct?

 

Spectrum of this delta waveform (above) is this:

 

The values here appear a lot lower than the RMS average, but that's because this spectrum is an average over the whole 20 seconds of the delta file. You can see that some values here also rise to about -96dB. That's easier to see if you view this on a Log scale:

 

 

Looks like there's a 50Hz line that isn't nulling out as well as the other frequencies. Mains frequency is 50Hz, perhaps?

 

Regards,

 

    -Paul

 

Here the files are not AAA and BBB here are ultimo1 and ultimo2.
The graphs are correct and I get them the same, what does not convince me is the value of ppm drift that if not active and active remains fixed at 0.85ppm.
this also happens with other files

 

[TomCapraro]

7 hours ago, pkane2001 said:

 

I'm not sure where you see the values you posted. Here's what I get when comparing AAA and BBB files. All averages and spectrum values are well below -260dB.

 

Where do you see -70dB and -130dB values?

 

I think you were wrong to insert the BBB file, I see a AAA to AAA comparison.
In the comparison you must enter BBB.

[Arpiben]

6 hours ago, pkane2001 said:

I think I see the problem... With mono files, there is no Right or Left channel, and no L+R mix-down possible

It's a bug that DW is trying to process channels that are not there, but then you probably shouldn't be selecting them. I'll put in a check for this condition.

 

Thanks.

If it helps pay attention that transforming my test files into Stereo ( L=R ) also brings DW sample reading issues.

Now DW reads 11 519 996 samples  instead of 11 519 999 samples for all comparison: Left / Right / Left + Right

 

Reference:  pitched.wav[L+R] 11520000 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[L+R] 11519996 samples 384000Hz 32bits, MD5=00

[pkane2001]

2 hours ago, Arpiben said:

 

Thanks.

If it helps pay attention that transforming my test files into Stereo ( L=R ) also brings DW sample reading issues.

Now DW reads 11 519 996 samples  instead of 11 519 999 samples for all comparison: Left / Right / Left + Right

 

Reference:  pitched.wav[L+R] 11520000 samples 384000Hz 32bits, MD5=00
Comparison: pitched_drift.wav[L+R] 11519996 samples 384000Hz 32bits, MD5=00

 

Thanks, I'll dig into it some more. You mentioning that this was a different behavior between mono and stereo files set off the alarm bells  yesterday 

 

[pkane2001]

3 hours ago, TomCapraro said:

I think you were wrong to insert the BBB file, I see a AAA to AAA comparison.
In the comparison you must enter BBB.

 

I was obviously in a rush last night  Let me redo this slowly this time, and I'll post what I find!

 

 

[pkane2001]

4 hours ago, TomCapraro said:

I think you were wrong to insert the BBB file, I see a AAA to AAA comparison.
In the comparison you must enter BBB.

 

Examining  AAA and BBB files...

 

There is a large difference right at the end of the track, in the last few milliseconds, that causes this poor RMS result. Here's what it looks like, zoomed-in:

 

For the rest of the track, the difference is tiny, below -130dB:

 

As you can see, the RMS delta value is -51.98dB because of these last few milliseconds. Let's trim the last 100 milliseconds and see if the result improves:

 

Better. The null is now almost -140dB RMS. So there was something in the original file, right at the end of the track, that caused a very large difference of almost 90dB in the RMS null!

Also notice that the Correlated Null value didn't change much -- that's because it is much less sensitive to a few bad results than the RMS value.

 

[Arpiben]

50 minutes ago, pkane2001 said:

 

Thanks, I'll dig into it some more. You mentioning that this was a different behavior between mono and stereo files set off the alarm bells  yesterday 

 

 

You are correct. But you know that the more one digs the more one finds ☺️

Looking at @TomCapraro files you will also notice discrepancies among samples count depending on DW L/R/L+R selection....

Thanks. 

[TomCapraro]

44 minutes ago, pkane2001 said:

 

Examining  AAA and BBB files...

 

There is a large difference right at the end of the track, in the last few milliseconds, that causes this poor RMS result. Here's what it looks like, zoomed-in:

 

For the rest of the track, the difference is tiny, below -130dB:

 

As you can see, the RMS delta value is -51.98dB because of these last few milliseconds. Let's trim the last 100 milliseconds and see if the result improves:

 

Better. The null is now almost -140dB RMS. So there was something in the original file, right at the end of the track, that caused a very large difference of almost 90dB in the RMS null!

Also notice that the Correlated Null value didn't change much -- that's because it is much less sensitive to a few bad results than the RMS value.

 

excellent now after cutting the last milliseconds the spectrum shows the correct value at -175dB.

now the question of the files ultima1 + ultima 2 and the drift value shown with and without activation remains

[pkane2001]

4 hours ago, TomCapraro said:

Here the files are not AAA and BBB here are ultimo1 and ultimo2.
The graphs are correct and I get them the same, what does not convince me is the value of ppm drift that if not active and active remains fixed at 0.85ppm.
this also happens with other files

 

 

There is a clock drift value of 0.85ppm. If Drift Correction is turned off, the approximate value is still computed and reported, but not corrected. In this case you will see this in Results:

Drift found, but not corrected: 0.8551ppm

Using your files, here is how the drift was computed:

 

 

 

[TomCapraro]

47 minutes ago, pkane2001 said:

 

There is a clock drift value of 0.85ppm. If Drift Correction is turned off, the approximate value is still computed and reported, but not corrected. In this case you will see this in Results:

Drift found, but not corrected: 0.8551ppm

Using your files, here is how the drift was computed:

 

 

 

Yes with deactivated drift correction it shows 0.85ppm
With the dritf correction activated the value does not change.
Try these files to better understand, without correction shows 0.01ppm, activating the correction the value remains unchanged.
With version 1.019 the activation of the drift brought the value to 0ppm.

https://we.tl/t-PNycTCO4kO

[pkane2001]

6 minutes ago, TomCapraro said:

Yes with deactivated drift correction it shows 0.85ppm
With the dritf correction activated the value does not change.
Try these files to better understand, without correction shows 0.01ppm, activating the correction the value remains unchanged.
With version 1.019 the activation of the drift brought the value to 0ppm.

https://we.tl/t-PNycTCO4kO

 

Right. With version 1.0.20 I added the drift value to the report, even if drift correction is turned off. This can help you decide if correction is needed or not.

 

When drift correction is not enabled, DeltaWave uses a quick approximation to compute the drift value. It might be slightly different than the value computed when the correction is enabled.

 

To get the scale of what 0.01ppm drift means, the difference between 0.01ppm and 0ppm is a 1 sample offset in a file containing 100 million samples. At 44.1KHz, this is equivalent to one sample delay between the start and end of a 38 minute recording!

[TomCapraro]

17 minutes ago, pkane2001 said:

 

Right. With version 1.0.20 I added the drift value to the report, even if drift correction is turned off. This can help you decide if correction is needed or not.

 

When drift correction is not enabled, DeltaWave uses a quick approximation to compute the drift value. It might be slightly different than the value computed when the correction is enabled.

 

To get the scale of what 0.01ppm drift means, the difference between 0.01ppm and 0ppm is a 1 sample offset in a file containing 100 million samples. At 44.1KHz, this is equivalent to one sample delay between the start and end of a 38 minute recording!

thank you...!!! now everything is clarified
If in the software you adopt a scale in the time axis between seconds -> milliseconds ---> microseconds ---> nanoseconds it becomes something extraordinary

[pkane2001]

6 minutes ago, TomCapraro said:

thank you...!!! now everything is clarified
If in the software you adopt a scale in the time axis between seconds -> milliseconds ---> microseconds ---> nanoseconds it becomes something extraordinary

 

 

[pkane2001]

2 hours ago, TomCapraro said:

thank you...!!! now everything is clarified
If in the software you adopt a scale in the time axis between seconds -> milliseconds ---> microseconds ---> nanoseconds it becomes something extraordinary

 

Is this what you want to see?  minutes : seconds : milliseconds . microseconds + 100 nsec?

 

[TomCapraro]

13 minutes ago, pkane2001 said:

 

Is this what you want to see?  minutes : seconds : milliseconds . microseconds + 100 nsec?

 

... maybe I ask too much it would be nice if you changed the value by just scrolling with the scroll 

[pkane2001]

1 minute ago, TomCapraro said:

... maybe I ask too much it would be nice if you changed the value by just scrolling with the scroll 

 

I'm not sure I understand. You can simply zoom-in on any part of the waveform even now. As you zoom in, the time labels will show more decimal places. Just use your mouse scroll wheel after placing the cursor anywhere in the plot that you want to zoom.

[TomCapraro]

29 minutes ago, pkane2001 said:

 

I'm not sure I understand. You can simply zoom-in on any part of the waveform even now. As you zoom in, the time labels will show more decimal places. Just use your mouse scroll wheel after placing the cursor anywhere in the plot that you want to zoom.

I know, at the moment it is so
I just wanted to know if it was possible to show the values directly when the zoom was changed with the scroll wheel
Show the value directly without having to do the calculation for all the zeros after the comma
In other words: if the waveform has an offset of 50 nanoseconds, a scale in nanoseconds should appear
In any case, thanks the same ... !!!

[pkane2001]

5 hours ago, Arpiben said:

 

You are correct. But you know that the more one digs the more one finds ☺️

Looking at @TomCapraro files you will also notice discrepancies among samples count depending on DW L/R/L+R selection....

Thanks. 

 

Please dig some more Here's an updated version 1.0.21 that should fix the missing samples issue. Let me know what you find!

 

https://deltaw.org

 

Regards,

 

      -Paul

[fas42]

Paul, could you give me a better idea of how drift is calculated, and how it's compensated for? I did an exercise of grabbing successive 3 second chunks of the Bob Marley B start and final copies last night, and the drift was going all over the place for each snippet: 1.04, 10.82, 6.53, 4.03. 4.01, 4.53 was what I got ... the delta will be struggling to be of value if this is not handled well.

[pkane2001]

2 minutes ago, fas42 said:

Paul, could you give me a better idea of how drift is calculated, and how it's compensated for? I did an exercise of grabbing successive 3 second chunks of the Bob Marley B start and final copies last night, and the drift was going all over the place for each snippet: 1.04, 10.82, 6.53, 4.03. 4.01, 4.53 was what I got ... the delta will be struggling to be of value if this is not handled well.

 

3 seconds is not nearly enough. A minute or more are needed to establish a good trend for computing drift.

[fas42]

IOW, the Bob Marley track of a touch over 30 secs can't be processed properly by DW ... ?

[pkane2001]

12 minutes ago, fas42 said:

IOW, the Bob Marley track of a touch over 30 secs can't be processed properly by DW ... ?

 

It can, but 3 seconds is not enough. 

[pkane2001]

2 minutes ago, pkane2001 said:

 

It can, but 3 seconds is not enough. 

 

I’ll explain a little later.