• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). Come here to have fun, be ready to be teased and not take online life too seriously. We now measure and review equipment for free! Click here for details.

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

D

Deleted member 17820

Guest
#1
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

Major Contributor
Joined
Jul 21, 2018
Messages
7,145
Likes
13,999
Location
The Neverlands
#2
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

Major Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
10,807
Likes
15,411
#3
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

Major Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
10,851
Likes
10,361
Location
Riverview FL
#4
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:

1597294669294.png
 

RayDunzl

Major Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
10,851
Likes
10,361
Location
Riverview FL
#5

Blumlein 88

Major Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
10,807
Likes
15,411
#6
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.
 
OP
D

Deleted member 17820

Guest
Thread Starter #7
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.
 
OP
D

Deleted member 17820

Guest
Thread Starter #8
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

Major Contributor
Forum Donor
Joined
Feb 23, 2016
Messages
10,807
Likes
15,411
#9
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

Major Contributor
Joined
Jul 21, 2018
Messages
7,145
Likes
13,999
Location
The Neverlands
#10
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

Major Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
10,851
Likes
10,361
Location
Riverview FL
#11
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.

1597296694046.png


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

1597297004667.png
 
OP
D

Deleted member 17820

Guest
Thread Starter #12
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

Major Contributor
Central Scrutinizer
Joined
Mar 9, 2016
Messages
10,851
Likes
10,361
Location
Riverview FL
#13
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.

1597335513024.png
 
Last edited:

AnalogSteph

Addicted to Fun and Learning
Joined
Nov 6, 2018
Messages
937
Likes
772
Location
.de
#14
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.
 

Similar threads

Top Bottom