Jump to content
IGNORED

DeltaWave null-testing audio comparator (beta)


Recommended Posts

@esldude Do you mind repeating one of your tests with a 3-4min white noise file?

I understood your point now 😉

I consider myself as an audio layman, but @Jud's point is quite valid since I think that during DAW or mixing, tracks may undergo or not some drift correction...  

As far as I understand things ( surely wrongly), the encountered behaviour may be due to:

1. File

2. DAP

3. ADC

4. DW

Need to eliminate variables. Not so easy as it may appear 😊.

 

Link to comment
21 hours ago, esldude said:

Actually some of these were done that way.  Some were with a Win10 machine and some with a Macbook pro.  The loopbacks on the Zen Tour were done both ways.  Those several days apart were first Mac and then later Win.  

 

Actually, I do want to understand the source in more detail. Here's why.

 

When comparing to the original, any loop-back copies appear to have a similar residual drift, as you reported. Even when the loop-back equipment is different. For example:

image.thumb.png.038de5eed85ae65d3def5b1826c155ff.png

 

But if content is causing the issue, then comparing the two loopbacks to each other should also reveal a similar pattern. So, I tried it, and it doesn't! The two loop-back recordings using different equipment but same track are much more similar to each other than the original compared to either loopback, and lacks the same distinctive pattern:

 

image.thumb.png.a0f2864fb397cdccb95546aafd5428d5.png

 

So, two possibilities that I can think of (am I missing any?)

 

1. There exists the same exact algorithm problem in matching the original to any loopback recording, even when using different equipment resulting in almost exactly the same drift pattern. Or

 

2. The source feeding the loopback equipment is introducing a similar timing/drift into each recording, regardless of equipment used. The question is, what can do that? What are you using to feed the data from the PC to the DAC? What protocol (USB, SPDIF, ?) What player software? Any resampling or DSP in player or at the OS/driver level? Any chance that the cable can cause timing errors or other issues? Very curious!

Link to comment
10 hours ago, esldude said:

Ok using Bob Marley in this case.  Starts with original vs 1st generation, and finishes with 7th gen vs 8th generation.  The pattern isn't identical, but the basic pattern of drift makes it all the way through them all.  March DAC feeding Zen Tour ADC. 

 

Here's another test. If the data was causing the very unique drift pattern, then it shouldn't matter how the drift was generated. This seems to be confirmed by the different loop-back equipment producing a similar pattern in your tests.

 

What if we try to add the same amount of drift in Audacity, using @fas42' s method? If the content of the file is causing the problem, then the same residual drift pattern should be detected there. 

 

Here's Bob Marley fourth generation compared to the original. The recognizable pattern in the residual drift is there, drift measured at 2.41ppm:

image.thumb.png.9df968871e2c51ee4dde8e5fe113e8b6.png

 

Now, let's do the same with the artificially induced drift in Audacity, applied on top of the the original file (same scale as above), drift of 2.83ppm:

image.thumb.png.6a9493541107c94b58b7959ec94ae976.png

 

And now, the same but zoomed in a bit further. No similar pattern is detectable now:

image.thumb.png.0df5a46012a84d22f0bb86f42b2fd186.png

 

So, if not passed through the loop-back mechanism, it appears that the distinctive drift pattern doesn't show.

 

This doesn't prove that the content is not at fault here, but it does give some evidence against it.

 

EDIT: As another test, I added artificial 2.83ppm drift to the 4th generation wav file. Then compared that to the original. Same exact pattern remains, undisturbed. DW also computed the drift correctly (2.83 + original 2.41 = 5.24ppm):

image.thumb.png.76fbece544672c182e79ce7b2ad7f8e9.png

Link to comment

Did some more loopbacks.  Using the Zen Tour with its own clock.  One set with a Macbook over Thunderbolt.  One set with a Lenovo over USB.   The same patterns emerged.  Mac first and Lenovo 2nd.  Both of my test music files produced the patterns already seen. 

 

1333725794_CaramZtloop3mac.thumb.png.2c04fb14ac75bfe1c5fe1e6bf7867328.png1053796638_Caramztloop3lenovo.thumb.png.32c64e9ccb880deae208e1b89eb86a3e.png1786549754_Fleckztloop3mac.thumb.png.8fb8f158eadfbb0524b77a0e2328c06f.png1682820637_Fleckztloop3lenovo.thumb.png.b26bdeee45c630f8d459c478a5573d45.png

 

 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
2 hours ago, pkane2001 said:

 

Here's another test. If the data was causing the very unique drift pattern, then it shouldn't matter how the drift was generated. This seems to be confirmed by the different loop-back equipment producing a similar pattern in your tests.

 

What if we try to add the same amount of drift in Audacity, using @fas42' s method? If the content of the file is causing the problem, then the same residual drift pattern should be detected there. 

 

Here's Bob Marley fourth generation compared to the original. The recognizable pattern in the residual drift is there, drift measured at 2.41ppm:

image.thumb.png.9df968871e2c51ee4dde8e5fe113e8b6.png

 

Now, let's do the same with the artificially induced drift in Audacity, applied on top of the the original file (same scale as above), drift of 2.83ppm:

image.thumb.png.6a9493541107c94b58b7959ec94ae976.png

 

And now, the same but zoomed in a bit further. No similar pattern is detectable now:

image.thumb.png.0df5a46012a84d22f0bb86f42b2fd186.png

 

So, if not passed through the loop-back mechanism, it appears that the distinctive drift pattern doesn't show.

 

This doesn't prove that the content is not at fault here, but it does give some evidence against it.

 

EDIT: As another test, I added artificial 2.83ppm drift to the 4th generation wav file. Then compared that to the original. Same exact pattern remains, undisturbed. DW also computed the drift correctly (2.83 + original 2.41 = 5.24ppm):

image.thumb.png.76fbece544672c182e79ce7b2ad7f8e9.png

You are forgetting I see the patterns when using the March DAC feeding the Zen Tour without any loopback in use. 

 

A bit more curious were these results.  First the Zen Tour connected to the USB Windows machine playing into the 18i20 ADC which is USB connected to the Macbook.  The drift magnitude is about 5 times larger, but the same pattern.  This is the Anna Caram track. 

 

1776756515_Ztfeedscaramto18i20.thumb.png.1bb7b7db23a66f8519b7255d4fce55a9.png

 

Here is a Focusrite Forte playing into the 18i20 ADC.  Lower drift magnitude than above, but higher than loopbacks.  Yet pretty much the same pattern again. 

 

1341902606_fortefeedsCaram18i20.thumb.png.c417157e42d0f29c7e48ca7741976bd5.png

 

March Dac playing into the 18i20 ADC.

91763728_MarchplayingCaramto18i20.thumb.png.6c4b4dfe4736b6b6c71855b5fe81c6ae.png

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
Just now, esldude said:

You are forgetting I see the patterns when using the March DAC feeding the Zen Tour without any loopback in use. 

 

A bit more curious were these results.  First the Zen Tour connected to the USB Windows machine playing into the 18i20 ADC which is USB connected to the Macbook.  The drift magnitude is about 5 times larger, but the same pattern.  This is the Anna Caram track. 

 

1776756515_Ztfeedscaramto18i20.thumb.png.1bb7b7db23a66f8519b7255d4fce55a9.png

 

Here is a Focusrite Forte playing into the 18i20 ADC.  Lower drift magnitude than above, but higher than loopbacks.  Yet pretty much the same pattern again. 

 

1776756515_Ztfeedscaramto18i20.thumb.png.1bb7b7db23a66f8519b7255d4fce55a9.png

 

 

 

Yes, and that's why I'd like to know the source configuration. I don't suspect the loopback equipment is causing this, but it is possible that the source software/PC/cable/converter/resampler/OS/DSP might be.

 

If the content of the original file with added drift is causing this, then we should see the same pattern when comparing original to Audacity-induced drift version. That isn't happening, so it is likely something else.

Link to comment
1 minute ago, pkane2001 said:

 

Yes, and that's why I'd like to know the source configuration. I don't suspect the loopback equipment is causing this, but it is possible that the source software/PC/cable/converter/resampler/OS/DSP might be.

 

If the content of the original file with added drift is causing this, then we should see the same pattern when comparing original to Audacity-induced drift version. That isn't happening, so it is likely something else.

I was just about to ask about this.  I had already done it the other way.  I added 10 ppm drift to the original file.  Compared it and the pattern remains.  So we did something different.  Here is the original 10 ppm fast vs the capture of the March playing into the 18i20.

 

1646413630_OriginalCaram10ppmfastvs18i20captureofMarch.thumb.png.9c9c4673de0e592b60834031d23b647f.png

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
3 minutes ago, esldude said:

I was just about to ask about this.  I had already done it the other way.  I added 10 ppm drift to the original file.  Compared it and the pattern remains.  So we did something different.  Here is the original 10 ppm fast vs the capture of the March playing into the 18i20.

 

1646413630_OriginalCaram10ppmfastvs18i20captureofMarch.thumb.png.9c9c4673de0e592b60834031d23b647f.png

 

Looks like 80ppm drift? How did you add it?

 

Link to comment
4 minutes ago, pkane2001 said:

 

Yes, and that's why I'd like to know the source configuration. I don't suspect the loopback equipment is causing this, but it is possible that the source software/PC/cable/converter/resampler/OS/DSP might be.

 

If the content of the original file with added drift is causing this, then we should see the same pattern when comparing original to Audacity-induced drift version. That isn't happening, so it is likely something else.

I'm at a loss as to what else you want to know.  I've done this with different laptops, ADC, DAC, clocking etc.  

 

The Zen Tour captures of other DACs, were my Win 10 Lenovo playing the track via Foobar ASIO with all the DACs USB connected.  The Zen Tour was Thunderbolt connected via Macbook Pro.  I've recorded with Audacity on the Mac.  I did a couple with Reaper on the Mac with no difference.  I also used Reaper to play a couple on the Win10 machine with no difference. 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
3 minutes ago, pkane2001 said:

 

Looks like 80ppm drift? How did you add it?

 

The compare file in both cases was from an 18i20 capture of a March DAC.  70.89 vs the original, and 80.89 vs the original sped up 10 ppm in Audacity.

 

So did you use the original as Ref, and 10 ppm fast as Compare?

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
8 minutes ago, esldude said:

The compare file in both cases was from an 18i20 capture of a March DAC.  70.89 vs the original, and 80.89 vs the original sped up 10 ppm in Audacity.

 

Just trying to understand. So you took a file captured over loop-back, then added 10ppm drift to it? I tried that too, and the pattern remained unchanged after drift addition.

 

Did you also try to add drift to the original file and see if the pattern is visible in such a comparison? That's one of the tests  I did above.

Link to comment
22 minutes ago, pkane2001 said:

 

Just trying to understand. So you took a file captured over loop-back, then added 10ppm drift to it? I tried that too, and the pattern remained unchanged after drift addition.

 

Did you also try to add drift to the original file and see if the pattern is visible in such a comparison? That's one of the tests  I did above.

I played the file over the March DAC.  Its output captured by the 18i20 ADC. 

I used this for the compare file in both cases. 

 

First I compared to the original file. 

Second compared to the original file sped up 10 ppm. 

 

The compare file capture was unchanged in both cases. 

 

I agree that if the content modulated the software during alignment you'd expect the original vs the original sped up to show the same pattern and it does not.  I did also do that test myself. Still leaves me wondering where the pattern is coming from. 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
16 minutes ago, esldude said:

I played the file over the March DAC.  Its output captured by the 18i20 ADC. 

I used this for the compare file in both cases. 

 

First I compared to the original file. 

Second compared to the original file sped up 10 ppm. 

 

The compare file capture was unchanged in both cases. 

 

I agree that if the content modulated the software during alignment you'd expect the original vs the original sped up to show the same pattern and it does not.  I did also do that test myself. Still leaves me wondering where the pattern is coming from. 

 

We must be doing something different. I took your Caram A M ZT44 file, compared it to the original. The same pattern as you're seeing:

image.thumb.png.1760081b42f607f55e4a9980a1802a71.png

 

Then, took the same file, sped it up around 10ppm in Audacity, and compared them. None of the same pattern is visible:

image.thumb.png.1b4a980bcd08e749d18dd72e9d0ba2a6.png

Link to comment
8 minutes ago, pkane2001 said:

 

We must be doing something different. I took your Caram A M ZT44 file, compared it to the original. The same pattern as you're seeing:

image.thumb.png.1760081b42f607f55e4a9980a1802a71.png

 

Then, took the same file, sped it up around 10ppm in Audacity, and compared them. None of the same pattern is visible:

image.thumb.png.1b4a980bcd08e749d18dd72e9d0ba2a6.png

Yes I agree.  When I compare a file to itself sped up the pattern is not there.  

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
3 minutes ago, pkane2001 said:

 

Then it's not clock drift that's causing it, and it's not file contents. The question remains, what? :)

I assume the upper frequencies are not in phase in a capture vs an original.  Could that be resulting in the corrected drift pattern in combination with file content?  Remember in the 18i20 and Forte captures the pattern was there, but the amplitude of the pattern was different (larger).  I know the Forte has a mimimum phase filter with mostly post ringing rather than a more conventional filter. 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
11 minutes ago, esldude said:

I assume the upper frequencies are not in phase in a capture vs an original.  Could that be resulting in the corrected drift pattern in combination with file content?  Remember in the 18i20 and Forte captures the pattern was there, but the amplitude of the pattern was different (larger).  I know the Forte has a mimimum phase filter with mostly post ringing rather than a more conventional filter. 

 

I see what you're saying. A low-pass filter prior to comparing the files would tell us if that's the case. The phase difference algorithm applies a weight to all the frequencies based on their magnitude, so higher frequencies should normally be ignored. But, if there is some high magnitude high-frequency content that's out of phase it could potentially affect the computation.

 

EDIT: no, sorry. Just tried applying a 10K low pass filter to both files prior to processing, and the pattern is still there, apparently unchanged:

image.thumb.png.6ca6485193466b2e2c82f503507430ea.png

Link to comment

Wasted enough time on this for now.  I can see if it is still there in the next version where I believe you said you were improving precision.  Just puts a bee in my bonnet to see that pattern over so many changes, and not know how it gets there. 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
2 minutes ago, esldude said:

Wasted enough time on this for now.  I can see if it is still there in the next version where I believe you said you were improving precision.  Just puts a bee in my bonnet to see that pattern over so many changes, and not know how it gets there. 

 

I'll continue thinking about it. It's either a software glitch which needs a fix, or an actual physical phenomenon which needs to be explained :)

 

 

Link to comment

Some excellent detective work being done here! :) Haven't properly digested the above posts, but my gut feeling is that it's the subtle errors in the copies combining with how the software is doing the correlating, which "fools' the algorithm into 'mismatching' in a distinct pattern - perhaps the order in which operations are done within DW will make a significant, ummm, difference.

 

My instincts are that the most important thing to get right at the outset are to correct for drift, to the maximum degree possible, using every possible angle of attack on the issue. Only then should finer points in other areas be addressed.

 

Still half asleep, so if this all sounds like nonsense - then I have an excuse!  :P

Link to comment

Don't know why I didn't think of this earlier.  I was always using the left channel.  So if content interacts with the software the right channel should not have the same pattern.  When I tried that the same pattern is there in the various configurations in the right channel as well.  Plus with L+R.  

 

I did notice another curiosity.  Using the Anna Caram track the left always shows .01 ppm more drift.  With separate DACs and ADCs it was true, with external clocking and with loopbacks with a common clock it was true.  You might get .85 ppm for the left and you get .84 ppm for the right channel.  Loopbacks you get .01 ppm on the left and 0 ppm on the right.  BTW I was very surprised to see .01 ppm on loopbacks when I first did them last week.  You should be seeing 0 ppm on those.   The other test track I've been using shows the same on both channels and 0 ppm on loopbacks. 

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment
10 minutes ago, esldude said:

Don't know why I didn't think of this earlier.  I was always using the left channel.  So if content interacts with the software the right channel should not have the same pattern.  When I tried that the same pattern is there in the various configurations in the right channel as well.  Plus with L+R.  

 

I did notice another curiosity.  Using the Anna Caram track the left always shows .01 ppm more drift.  With separate DACs and ADCs it was true, with external clocking and with loopbacks with a common clock it was true.  You might get .85 ppm for the left and you get .84 ppm for the right channel.  Loopbacks you get .01 ppm on the left and 0 ppm on the right.  BTW I was very surprised to see .01 ppm on loopbacks when I first did them last week.  You should be seeing 0 ppm on those.   The other test track I've been using shows the same on both channels and 0 ppm on loopbacks. 

 

Dennis, you were on to something when you thought of phase. Except it’s the phase of the lower frequencies that is the problem here, not the higher ones. High pass filter of 800Hz or so eliminates the pattern completely. Needs to be applied in Audacity since DW applies filters at the end of processing, and not at the beginning.

 

What causes these errors remains to be determined, but we are getting closer! 

Link to comment
23 minutes ago, fas42 said:

It could be helpful to get a very precise idea of how the drift correction algorithm operates, as a set of steps - would this be at all possible, Paul?

 

Probably not in detail, but the algorithm is to measure offsets of samples at multiple locations in the waveforms.  Then, a linear regression is used to fit a line to the offsets, the slope of the line is the drift, the  intercept is the offset.

Link to comment
13 minutes ago, pkane2001 said:

 

Dennis, you were on to something when you thought of phase. Except it’s the phase of the lower frequencies that is the problem here, not the higher ones. High pass filter of 800Hz or so eliminates the pattern completely. Needs to be applied in Audacity since DW applies filters at the end of processing, and not at the beginning.

 

What causes these errors remains to be determined, but we are getting closer! 

I was about to ask about that.  As I tried cutting frequencies at both ends, and came to the conclusion the filtering must be done after alignment.  Now I know this might complicate matters, do you think having an option to filter prior to alignment might be worthwhile.  Or maybe that filtering prior to alignment when filtering is selected is simply a better way to go about it?

And always keep in mind: Cognitive biases, like seeing optical illusions are a sign of a normally functioning brain. We all have them, it’s nothing to be ashamed about, but it is something that affects our objective evaluation of reality. 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...