DeltaWave null-testing audio comparator (beta)

[fas42]

Finally some time to breathe!

 

Consider the situation where the two waveform are in fact identical in content, but differ because the clock rates don't match. To synchronise, the rates must match, and the starting points must coincide; what DW doesn't evaluate precisely enough is the starting positions - the offset, IOW.

 

There would be a number of ways of going about it; one way I explored was to slightly alter the drift. to make the delta look worse; that is, the mismatch is no longer even, it steadily gets worse, or better going along the sample, the nulled audio gets louder or softer as it plays. Then start playing with the offset, feed in values either side of the current value and see what happens to the delta; in some key range of values, a true null will occur at some point along the clip; you now have the means to properly fine tune. Try a couple of slight variations of offset; that null will move a certain distance along the x axis; you can now almost calculate a value which precisely places the null at the exact start of the matched waveforms; a comparison now with the right offset will show the volume of the mismatch steadily increase along the sample - what's needed now is to fine tune the drift - and the value originally worked out by DW is very close. Insert this, and try slight variations on either side; the better choice will decrease the slope of the amplitude envelope.

 

Does this make sense so far?

 

[pkane2001]

1 hour ago, fas42 said:

Finally some time to breathe!

 

Consider the situation where the two waveform are in fact identical in content, but differ because the clock rates don't match. To synchronise, the rates must match, and the starting points must coincide; what DW doesn't evaluate precisely enough is the starting positions - the offset, IOW.

 

There would be a number of ways of going about it; one way I explored was to slightly alter the drift. to make the delta look worse; that is, the mismatch is no longer even, it steadily gets worse, or better going along the sample, the nulled audio gets louder or softer as it plays. Then start playing with the offset, feed in values either side of the current value and see what happens to the delta; in some key range of values, a true null will occur at some point along the clip; you now have the means to properly fine tune. Try a couple of slight variations of offset; that null will move a certain distance along the x axis; you can now almost calculate a value which precisely places the null at the exact start of the matched waveforms; a comparison now with the right offset will show the volume of the mismatch steadily increase along the sample - what's needed now is to fine tune the drift - and the value originally worked out by DW is very close. Insert this, and try slight variations on either side; the better choice will decrease the slope of the amplitude envelope.

 

Does this make sense so far?

 

 

Yes, Frank. Offset calculation needs to be improved, and I did that with the previous version, and now have something that's even better in the new, unreleased one. The offset precision in previous versions was around 1/1000 of a sample. The new version is about 1000x better

 

That does produce much better nulls with Audacity-edited files. The improvement with 'naturally-produced' (organic?) files is smaller, primarily because there really are large differences in the form of noise and distortions that cover up any imprecision in the offset calculation. 

 

Now, I thought you were going to share an example of some files and values that demonstrated these issues in DeltaWave? Do you have an example that I can try to reproduce?

 

Here's your original example of a rate-adjusted Bob Marley file compared to the original. If you recall, with the previous versions of DW the null was around 91-92dB, or almost 16bits. With the new version, the null is somewhat improved . I added a 20k low-pass filter to eliminate the effect of Audacity resampling filter:

[fas42]

57 minutes ago, pkane2001 said:

 

Yes, Frank. Offset calculation needs to be improved, and I did that with the previous version, and now have something that's even better in the new, unreleased one. The offset precision in previous versions was around 1/1000 of a sample. The new version is about 1000x better

 

Paul, you've got the situation completely in hand ... .

 

 

57 minutes ago, pkane2001 said:

That does produce much better nulls with Audacity-edited files. The improvement with 'naturally-produced' (organic?) files is smaller, primarily because there really are large differences in the form of noise and distortions that cover up any imprecision in the offset calculation. 

 

OK, those "noise and distortions" are exactly what what we're trying to chase down ...

 

57 minutes ago, pkane2001 said:

Now, I thought you were going to share an example of some files and values that demonstrated these issues in DeltaWave? Do you have an example that I can try to reproduce?

 

Here's your original example of a rate-adjusted Bob Marley file compared to the original. If you recall, with the previous versions of DW the null was around 91-92dB, or almost 16bits. With the new version, the null is somewhat improved . I added a 20k low-pass filter to eliminate the effect of Audacity resampling filter:

 

Also working on that very same Audacity adjusted, 1 sample in 352.8k difference in rate pairing that I posted about earlier - DW produces this,

 

 

Bob Marley comes through loud and clear - the values are,

 

 

After numerous iterations, end up with,

 

 

with these slightly amended values,

 

 

Nothing but white noise can be heard at the beginning of the track, and a 1/3rd of the way through the music starts to raise its presence; the spikes tell it all. Note the interesting ripple to the waveform envelope noise.

[esldude]

Wow so 1 millionth of a sample? I look forward to this new version.

[pkane2001]

6 hours ago, esldude said:

Wow so 1 millionth of a sample? I look forward to this new version.

 

Actually, it's even better than that. That was a conservative estimate  But again, interestingly, this helps more with synthetic files. There are some differences in the measurements of 'natural' files, as well, but these are not nearly as major.

 

Not that these are interesting to anyone, but here are the results of synthetic tests with the new algorithm. Error computed at 40 equally spread fractional offsets between -1 and 1, using the Bob Marley track:

RMS Error: 3.74850425401327E-09, Max Error: 7.0000006902049E-09

And here's the same test, except with randomly generated offsets between -1 and 1 samples:

RMS Error: 3.63808775772764E-09, Max Error: 7.2971281239731E-09

Amazing how a little tweak to the algorithm could make such a huge difference! Previous results were between 1e-3 and 1e-4.

[fas42]

Okay, a rather annoying bug has arisen - the manual correction values are not stable; the values of offset and drift are reported in the table as being reset to zero; and the zero is transferred to the entry boxes, if selected. This started to happen after a major session of using the correction process and that window was closed, to be opened again. I suspect I will have restart DW, to restore stability.

 

Earlier on I noted some intermittent misbehaviour where values from a line item weren't being transferred correctly - but this is much worse.

[pkane2001]

50 minutes ago, fas42 said:

Okay, a rather annoying bug has arisen - the manual correction values are not stable; the values of offset and drift are reported in the table as being reset to zero; and the zero is transferred to the entry boxes, if selected. This started to happen after a major session of using the correction process and that window was closed, to be opened again. I suspect I will have restart DW, to restore stability.

 

Earlier on I noted some intermittent misbehaviour where values from a line item weren't being transferred correctly - but this is much worse.

 

That sounds like you ran out of memory, Frank.  The way memory is used in DW can eventually cause an out of memory condition if you keep processing large files and don’t restart it. This is because it loads the full waveform for both files and all the intermediate  processing steps require additional memory. Eventually memory becomes fragmented, so the large memory blocks needed can no longer be allocated.

 

 

[fas42]

Don't think so - after restart, exactly the same behaviour manifested, in the Manual window! There is some pattern that if a value is not changed "in the right way" then the line item doesn't get updated properly - after some laborious, repetitive clicking and changing of entries it settled down, and behaved itself, from then on.

 

Also, trying to align on a very narrow bandwidth of the Marley original and 1st copy - getting this 'interesting' result,

 

 

[pkane2001]

12 hours ago, fas42 said:

Don't think so - after restart, exactly the same behaviour manifested, in the Manual window! There is some pattern that if a value is not changed "in the right way" then the line item doesn't get updated properly - after some laborious, repetitive clicking and changing of entries it settled down, and behaved itself, from then on.

 

Also, trying to align on a very narrow bandwidth of the Marley original and 1st copy - getting this 'interesting' result,

 

 

 

If this is reproducible, let me know the steps. I’ve not seen this behavior before, and I had the optimizer run for an hour or longer.

[fas42]

Managed to replicate a specific instance,

 

 

The sequence was:

 

Start DW

Run match from saved settings

Open Corrections window, and tick cache file data, manually update the drift and offset numbers to values found earlier to give better results, and Apply

 

Note that the last run used zero for the offset, rather than displayed value - hence very poor nulling. If I now select the 2nd run line, the offset will be set to zero. I have had instance where both drift and offset were set to zero, and it took some fiidling with typing in numbers, to get the values to take.

[fas42]

Another one ... narrow bandwidth matching, of Marley, orig and 1st gen; where files were upsampled in Audacity to 176.4k - the gain matching completely lost the plot, the Matching, Delta panels show this too. Whereas, the 44.1k versions are handled fine ...

 

[pkane2001]

12 hours ago, fas42 said:

Another one ... narrow bandwidth matching, of Marley, orig and 1st gen; where files were upsampled in Audacity to 176.4k - the gain matching completely lost the plot, the Matching, Delta panels show this too. Whereas, the 44.1k versions are handled fine ...

 

 

Thank you, Frank. I'll take a look. Seems like all the other calculations are working fine, but the level difference computation is thrown off by the narrow-band filter.

 

[TomCapraro]

hello these days I did some tests, I recorded twice with the same dac and the same ADC of the signals (sweep and pink noise) and I made the comparison of the signals (rec1 with rec2)
The null test drops to the noise except in the initial part of the files (the first 5/6 seconds), being able to notice that the cause is a worse alignment than the signal part beyond 5/6 seconds.
If this software could solve this problem it would be perfect.

[pkane2001]

9 minutes ago, TomCapraro said:

hello these days I did some tests, I recorded twice with the same dac and the same ADC of the signals (sweep and pink noise) and I made the comparison of the signals (rec1 with rec2)
The null test drops to the noise except in the initial part of the files (the first 5/6 seconds), being able to notice that the cause is a worse alignment than the signal part beyond 5/6 seconds.
If this software could solve this problem it would be perfect.

 

Hi Tom,

 

Yes, I'm working on putting the automatic trim function back in. I removed it because it was often too aggressive in removing mismatched parts of the waveform, sometimes leaving very little of the waveform to match. The new version should handle this a little better

[TomCapraro]

👍

[pkane2001]

DeltaWave 1.0.26b is now available for download

 

Changes in 1.0.26b

• Changed silence trim function to also auto-trim mismatched parts of the waveforms front and back (up to 5 secs each)
• Added Correlated Null chart showing average Correlated Null over time
• Improved precision of offset and drift calculations
• Changed the gain difference calculation to improve performance with narrow filters
• Improved match performance with less than 10 seconds of waveform data
• Added more decimal places to the display in the Manual Adjustments results table

Please report any issues/problems. The beta test is completing soon, at which point the updates and new versions will become more of a regular, scheduled activity.

[fas42]

First tryout of 26b - tackled that comparison mentioned in my last bug report, where the gain was badly calculated; good news is that the the levels now match, the bad news is that drift correction is still inadequately handled, out by 2 samples in the middle, out by 4 samples at the end of the track. Plus, going into Manual to try improving, that reseting bug in the window still exists - the calculated offset value was lost; so need to manually re-enter.

[fas42]

And having issues with repeatability - each time I do a comparison run, the numbers change, sometimes dramatically. In the Manual window, whether Cache File Data is ticked makes a huge difference, redoing the initial run changes values significantly; and even rerunning Match from the main window also alters numbers slightly.

[pkane2001]

4 hours ago, fas42 said:

First tryout of 26b - tackled that comparison mentioned in my last bug report, where the gain was badly calculated; good news is that the the levels now match, the bad news is that drift correction is still inadequately handled, out by 2 samples in the middle, out by 4 samples at the end of the track. Plus, going into Manual to try improving, that reseting bug in the window still exists - the calculated offset value was lost; so need to manually re-enter.

 

Interesting, I tried to reproduce the problem with disappearing offset, and never could, but I did fix an issue that I thought could've caused it. 

 

Drift correction will never handle a nonlinear drift, if that's what you're referring to. You're destroying most of the signal when using this narrow-band filter. And drift correction requires a lot of data to measure to a sub-sample accuracy, so you are starving it by removing all but the 200Hz in the  middle  

 

As you can see, the initial measurement shows this dip, as well as the final one. That dip cannot be corrected, and is likely an artifact of having discarded most of the data in both waveforms.

 

[pkane2001]

42 minutes ago, fas42 said:

And having issues with repeatability - each time I do a comparison run, the numbers change, sometimes dramatically. In the Manual window, whether Cache File Data is ticked makes a huge difference, redoing the initial run changes values significantly; and even rerunning Match from the main window also alters numbers slightly.

 

See if you have the Trim setting turned on. The new trimming function may work slightly differently when performed in an automatic calculation in the main window or when invoked from the Manual Adjustment window. Turn it off and see if the results become more repeatable.

 

[TomCapraro]

I tried with the same signals to perform the null test, now it works very well.
Comparing the two recordings, the null test brings the residue in the noise I checked also through the spectrum analyzer.
There is a slight rise around 10-15hz but it is normal since the power supply is not very stable and the signal oscillates in a non-linear way.
The problem I pointed out has been solved.
If there are other small problems they will be resolved but starting from this base that turns out to be almost perfect, at least for how I use it.
Thanks Paul.

[TomCapraro]

ah ... I forgot to say that the software immediately realizes the quality change of the DAC because I also redid a loopback with a better dac and the null test (between original and recorded signal) produces a cancellation much more evident.

[Jud]

3 hours ago, TomCapraro said:

ah ... I forgot to say that the software immediately realizes the quality change of the DAC because I also redid a loopback with a better dac and the null test (between original and recorded signal) produces a cancellation much more evident.

 

That’s a quite interesting application - which DACs produce the most consistent results and lowest noise.

 

Edit: Hmm, and under which environmental (e.g., electrical) conditions....

[TomCapraro]

40 minutes ago, Jud said:

 

That’s a quite interesting application - which DACs produce the most consistent results and lowest noise.

 

Edit: Hmm, and under which environmental (e.g., electrical) conditions....

The electrical conditions appear to be under the same clock, with the same cables, and with the same ADC that recorded them.

[pkane2001]

9 hours ago, fas42 said:

First tryout of 26b - tackled that comparison mentioned in my last bug report, where the gain was badly calculated; good news is that the the levels now match, the bad news is that drift correction is still inadequately handled, out by 2 samples in the middle, out by 4 samples at the end of the track. 

 

Frank, trying to reproduce the error with narrow-band drift correction. Are you testing with original 44.1k files, or upsampled ones?

 

Here's what I get with original 44.1k (I did have to trim 1 second from the front and the back of the file). Looks reasonably good to me: