DeltaWave null-testing audio comparator (beta)

[pkane2001]

7 hours ago, esldude said:

https://www.dropbox.com/s/0jciymo33xv14sx/Bob Marley all generations.zip?dl=0

 

These I uploaded earlier for Frank were all saved in 32 bit float from Audacity with it set to default internally to 32 bit float.  Unless it says otherwise in the file name it is 32 bit float.  I did leave the original as 16 bit, and 1st, 4th and 8th gen copies with both 24 bit and 32 bit float.  No dither in use at all.   Other than the original reference file in 16 bit, all the other generations were 24 bit files when I opened them in Audacity. 

 

Though not part of those files,  I opened the original and reduced it .38 db and saved as 32 bit pcm, float and 24 bit pcm.  Both 32 bit versions error out.  The 24 bit version shows a 200+db null depth.  I haven't tried saving it as 16 bit.  I know about what to expect.  The issue seems to be getting 32 bit to work on Frank's and my end of things right now. 

 

Thanks, guys. As I said, 32-bit floating point format has been working, it's 32-bit/24-bit integer formats. I've tracked down a problem and will have a fix ASAP. Meanwhile, I'm following up on the tests that Frank reported to try to understand what could've caused them. The likely contender for the lower than expected null for 16-bit files appears to be the use of overlap-add and the choice of the FFT window. This is similar to what I had fixed before in other parts of the software, but appears to behave slightly differently, so I'll need more time to investigate. 

 

[pkane2001]

5 minutes ago, esldude said:

Unless I misunderstood, the current version of the software is not working for me at 32 bit float. That was one of the logs I posted. Those 32 bit float files in the Dropbox link will error out.

 

I'll check again on 32-bit floating, but that's a format I've been using extensively during testing. It's not the same as 32-bit signed PCM -- that's an integer format, not floating point.

[pkane2001]

3 hours ago, esldude said:

Yes I'm clear on integer and float.  If there is any particular way I can do a comparison that is helpful describe it and I'll run it later today.

 

Thanks, Dennis. I got your multi-generation 32-bit floating point files and they load fine in DW. I also see that 24-bit and 32-bit integer sample files do not, and I know why. It'll be fixed ASAP. If you do have a file or two that are 32-bit floating point and fail to load, I'd like to see those.

 

[pkane2001]

A pre-release of v1.0.19. This should address a lot of the issues that @fas42 and @esldude have reported, as well as adds a few new features and enhancements. Let me know what you think:

 

https://drive.google.com/open?id=1STW_HC903Lq8x0JKhDfUBkEFCay8fQ1L

 

• Should get better nulls with Audacity-processed 16-bit files
• Should read 24- and 32-bit integer WAV format correctly
• Should display correct offset value
• Adds silence trimming option (on by default)
• Adds scale display and other enhancements in the spectrogram windows
• Changes the waveform Y axis to display in dB rather than 1 to -1 floating point
• Fixes the 100% that's really a 'nearly 100%' display

Regards,

 

    -Paul

[pkane2001]

42 minutes ago, TomCapraro said:

saluti dall'Italia, ho letto questo e sono molto interessato perché è un ottimo software. Ho usato l'audio diff maker e dal confronto Deltawave mi dà un potenziale molto alto. Ho fatto un sacco di test e penso che abbiamo raggiunto un buon punto.
Per me sarebbe necessario migliorare la rappresentazione di alcuni segnali, come quelli che vi mando, tra forma d'onda e delta spettrale. Lo noterai quando analizzi i segnali. Sono multitoni AAA e BBB, il rumore bianco a -130 dB è stato aggiunto in BBB. Non so se chiedo troppo ma, il software sarebbe fantastico se l'asse del tempo potesse essere ridimensionato in secondi ---> millisecondi ---> microsecondi ---> nanosecondi.

ecco i file https://wetransfer.com/downloads/04a20e67db339b50dcff1170ad150fd420190323174008/4c0b6f174934426f1e3bbb13a0f3e23520190323174008/cbd394

congratulazioni 

 

Hi Tom,

 

I'm glad you like the software! I agree, time representation can be improved. I'll take a look at your files, thank you for uploading!

 

Regards,

 

   -Paul

[pkane2001]

38 minutes ago, Arpiben said:

 I am having sample counting discrepancy issues with beta release v1.0.19 ( not tested with previous ones ).

 

Whenever comparing two identical files with one of them having 1 sample truncated at the beginning then DeltaWave truncates or counts 7 samples less systematically from 44.1 kSps up to 768 kSps .

The above discrepancy value is valid, for example, when dealing with 30s chirps from 1Hz to Nyquist Hz amplitude 0.5

 

File 1:  pitched.wav[L] 1323000 samples 44100Hz 32bits, MD5=00
File 2: pitched_drift.wav[L] 1322992 samples 44100Hz 32bits, MD5=00  (Instead of 1322999)

 

A probable consequence is that the matched result may sometimes be compromised; observed with high sampling rates (768/384 kSps)

Rgds.

 

 

The number of samples shown next to the file name is what's reported by the file reader, this is before DW does any processing. Are you saying that the file actually has 7 more samples in it, but DW reports 7 less?

[pkane2001]

Version 1.0.20b is now available!

 

This incorporates fixes for reported issues, including everything in v1.0.19, as follows:

• Better nulls with Audacity-processed 16-bit files 
• Read 24- and 32-bit integer WAV formats correctly
• Display correct offset value in Results tab
• Added silence trimming option (on by default)
• Added scale display and other enhancements in the spectrogram windows, including annotation support
• Right-click now removes the last annotation added to the chart
• Changed the waveform Y axis to display in dB rather than 1 to -1 floating point by default
• Added the option to switch between dB and floating point view of Y axis
• Fixed the 100% that’s really a ‘nearly 100%’ display
• Fixed the installer so previous versions are removed from the list of installed packages
• Handled different number of samples in left and right channels when working on L+R mono mix-down channel
• Added an optional, more stable drift correction method if the normal method does not converge
• Various minor spelling/terminology fixes

As always, all comments, issues, suggestions are more than welcome!

[pkane2001]

1 minute ago, mansr said:

Sounds like something is limiting the number of samples to multiples of 8.

 

That sounds like a good possibility.

[pkane2001]

20 minutes 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 assume a bug  I’ll see if I can reproduce and then fix.

[pkane2001]

4 hours ago, TomCapraro said:

Unfortunately, with my AAA -> BBB files it still doesn't give accurate results.
The waveform delta is correct at -130dB, while the difference value shown in the report is -51.98dB ... why?
Then, if the delta of the waveform is -130dB, shouldn't the FFT of the spectrum of delta at 65536 points show a carpet of noise of about -175dB? instead there is a line that starts at -70dB and ends at -130dB.
If I take the delta wave and load it on the FFT of my spectrum analyzer it gives me the exact value of -175dB.

 

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

 

[pkane2001]

4 hours ago, TomCapraro said:

Unfortunately, with my AAA -> BBB files it still doesn't give accurate results.
The waveform delta is correct at -130dB, while the difference value shown in the report is -51.98dB ... why?
Then, if the delta of the waveform is -130dB, shouldn't the FFT of the spectrum of delta at 65536 points show a carpet of noise of about -175dB? instead there is a line that starts at -70dB and ends at -130dB.
If I take the delta wave and load it on the FFT of my spectrum analyzer it gives me the exact value of -175dB.

 

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?

 

[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.

[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.

 

[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:

 

 

 

[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!

[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?

 

[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.

[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

[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.

[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.