I tried to do a Null Test for DAC's and failed :(

[Deleted member 17820]

HI guys, this is Mike. So I was thinking and messing around today and preparing sound files for a DAC vs DAC null test. Here is what I did.

1. Created a audio file with pink, sine, and sweeps
2. Tested to see if my built in realtek soundcard could capture the same file multiple times to get a null.
(I did this in audacity at 24bit/48khz sample. I flipped polarity to test for null.)

Step 2 is where I failed. No matter how many times I recording my test audio into the PC they were too different to get any null, just a weird phasey VERY partial null.

Now before you guys knock me for using a stock soundcard, I had a full 16 track studio set up before but sold of almost all me gear when my family was dealing with cancer, so now I have no mics/interfaces.

What I am wondering is if anyone with a higher quality recording interface is able to recored a sound sample and get it to null between 2 captures. If not then it seems a null test is useless?
And if the sound is never the same twice does that mean the music we here is also so different each time!?

Thanks for the help.
And I did align each file to the sample.

 

[solderdude]

Pkane is the guy who can answer this (or Blumlein) but IMHO the samplerate of the 'receiver' should be higher preferably 192/24.

 

[Blumlein 88]

Some questions to clarify.

Did you record the results and null them with the original file? Or did you record the file once and then twice and null both recordings?

 

[RayDunzl]

If there is any timing difference, they won't null.

I assume you are comparing the file to the capture.

Example, with music, with one sample time timing difference:

 

[RayDunzl]

As @solderdude almost mentioned, try the compare using this:

https://www.audiosciencereview.com/...test-deltawave-null-comparison-software.6633/

 

[Blumlein 88]

Ray beat me to it I was going to point you to Deltawave.

And yes, even going thru some cabling and back into the sound card is enough for the timing to disrupt the nulls somewhat. Not to mention precise level matching. Deltawave does a good job of matching levels, matching timing, and matching speed of the recordings all of which reduce how good the nulls are. Paul (pkane on ASR) wrote it for some of us making null testing more practical to do.

 

[Deleted member 17820]

Some questions to clarify.

Did you record the results and null them with the original file? Or did you record the file once and then twice and null both recordings?

I recorded 3 times and compared the recordings.

 

[Deleted member 17820]

If there is any timing difference, they won't null.

I assume you are comparing the file to the capture.

Example, with music, with one sample time timing difference:

View attachment 77836

Seems crazy to me that a one sample difference can have such an effect!
PS I am grateful for the help!

 

[Blumlein 88]

I recorded 3 times and compared the recordings.

I would have expected better results than what you are describing in that case.

I have done what you are describing with a fairly good recording interface. I was doing it to see if one found anything between different interconnects. Not that I thought I would. I got nulls of more than 90 db between recordings that way.

Maybe if you attached some of your recordings as zip files we could take a look at them in Deltawave.

Also if you are using Windows, make sure the system is using the same sample rate and bit depth so it isn't resampling your output files.

 

[solderdude]

That's why Paul, (pkane) develloped the software.
Consider that a clock for digital audio is not superstable and that no X.xxxxxxx MHz clock generators will ever have the exact same frequency and phase over a longer time.
To get an exact null you need the clocks to be exact or 'splice' the recorded sample in short 'blocks' and hope that the delta in clocks isn't changing that much in that chosen time period (Serge) which I thought pkane also incorporated.
So a small 'timing' difference between the clock of the DAC and the ADC will result in errors that become worse at higher frequencies.

 

[RayDunzl]

Seems crazy to me that a one sample difference can have such an effect!

The difference from one sample to the next would might be less at higher sample rates, as there would be less difference from one sample to the next, but for 44.1k here is what you get with one sample difference.

Low frequency almost nulls, but higher frequencies don't. At higher frequencies the sample value moves quickly in amplitude from one sample to the next.

Zooming in on the peak on the null:

Instead of summing equal plus and minus values (red, if time aligned), you sum a + and a + (black line, one sample delay) when comboning for the "null".

 

[Deleted member 17820]

I notice all the files I see are mono, even the "music" one. I was using stereo files but I don't see why that would make a difference. I will try with mono again.

 

[RayDunzl]

I notice all the files I see are mono, even the "music" one. I was using stereo files but I don't see why that would make a difference. I will try with mono again.

Just consider them all to be "Left Track".

To save screen real estate, the tracks above are all left channel - stereo split to mono - which results in a left and right track each named mono -and delete the right track as it is going to show the same symptoms.

Stereo track, copied and pasted, and "Split Stereo to Mono" It doesn't combine the channels.

 

[AnalogSteph]

You really start seeing these issues when dealing with devices of limited pitch accuracy. Years ago I was trying to take RMAA measurements of my Clip+ with its at best 0.04% deviation (that's after folks figured out a better configuration for the clock generator PLL to bring things down from 0.25%), and some tests in RMAA really don't appreciate that. RMAA pretty much need DAC and ADC clocks to be sync'd.

Is there any application out there that would allow for very fine-grained SRC? In the past I've resorted to hex-editing WAV headers and then importing that into Audacity so that would do its thing upon exporting, but it's not really what I'd call convenient.