Why Isn't Digital SRC Perfectly Repeatable?
walter88
Thread Starter
#1
16th July 2013
Old 16th July 2013
  #1
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Why Isn't Digital SRC Perfectly Repeatable?

I mean, it is perfectly repeatable, as long as the distance from start of encode to audio is EXACTLY the same, but if that distance is changed by even one sample, the SRC result is completely different.

I only found this after a client complained that one SRC pass sounded different from another SRC pass from identical audio, so I looked at their files, found out they were right, and decided to do some tests.

I took a 96k file, made a copy of it, and on the copy I cut off one sample from the very front of the file and saved it. Then I put both of those 96k files (the original and the copy) into an SRC program and converted them to 44.1k.

I lined up the audio of the two 44.1 files (most easily done by aligning the ends of the files) and did a null test. And the files were different, and couldn't be nulled. And the audible null test difference wasn't exactly subtle. The difference could also easily be seen in the waveforms.

This same difference is evident in DAW renders with SRC if the encode start point (which might be based on marker, clip edge, position on the track, etc.) changes by even one sample relative to the audio.

I tried this with ten different SRC programs (Izotope, r8brain, Wavelab Crystal, Nykiel, Apple, FinalCD, SOX, SSRC, PPHS, Reaper), and they all exhibit this behavior.

Can anyone tell me why this is, can it be fixed, and if there are any SRC programs that have been fixed for this?

I don't find this repeatability problem with digital plugins like EQ, limiters, or compressors. Those repeatability results can often null exactly if made from identical source audio with plugins no matter how much lead-in the source file has. (i.e. if you run a render with plugins, and then chop a second off the front of the source file and re-run with plugins, the two results when lined up will oftentimes null). Why can't digital SRC do the same?

Last edited by walter88; 16th July 2013 at 10:16 AM.. Reason: changed title
#2
16th July 2013
Old 16th July 2013
  #2
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

you tried to null the 44.1 kHz files ?
you can't do that.
if you have two 96 kHz files, remove one sample from one file, then src both to 44.1 kHz, how can you sample align the two files now ? you can't.
you need to src both files back up to 96 kHz, add your one sample back to the file you removed it from, then try and null @ 96 kHz.
there will be a difference because src involves LPF.
walter88
Thread Starter
#3
16th July 2013
Old 16th July 2013
  #3
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by stinkyfingers View Post
you tried to null the 44.1 kHz files ?
you can't do that.
if you have two 96 kHz files, remove one sample from one file, then src both to 44.1 kHz, how can you sample align the two files now ? you can't.
you need to src both files back up to 96 kHz, add your one sample back to the file you removed it from, then try and null @ 96 kHz.
Sorry, maybe I wasn't clear, but I think you misunderstood what I was trying to say. The point is, SRC is not repeatable from identical source audio if the leadin to the source audio is changed by even one frame. If you try exactly what I said, you will see that in the waveforms of the final 44.1 files. Yes I can try to null the 44.1 files by lining up start of audio in the waveforms, and they should null, but they don't because they're not the same.
#4
16th July 2013
Old 16th July 2013
  #4
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

of course the 44.1 kHz waveform will look different. you shifted the samples.
the src is the same, though. you just can't line up the files to null them.

edit: think of it like this...i'll use 48 kHz instead of 44.1 kHz because i suck at math, but the principal is the same.
if you remove one sample from a file at 96 kHz, then convert that file to 48 kHz, that is equal to removing a half of a sample at 48 kHz. you can't do that because the smallest increment you can 'use' for any given sample rate is one sample.
so take your two 96 kHz files, remove one sample from one file, then src both to 48 kHz and try and nudge one file one half sample to line them up. you can't.
walter88
Thread Starter
#5
16th July 2013
Old 16th July 2013
  #5
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
You could remove one second from the front of the 96k file and you'd still get this audio discrepancy I'm talking about. Sorry I have to go, but I'm 99.9% sure I'm right on this, if anybody's willing to try my test. Sorry, but I'll be back tomorrow.
Quote
1
#6
16th July 2013
Old 16th July 2013
  #6
Gear maniac
 
Johnscottguitar's Avatar
 
Joined: Feb 2011
Posts: 158

So if we took 2 samples out of the 96 and did the null test at 48 it should work
Quote
1
#7
16th July 2013
Old 16th July 2013
  #7
Lives for gear
 
FabienTDR's Avatar
 
Joined: Mar 2012
Location: Frankfurt/Germany

Quote:
Originally Posted by walter88 View Post
I mean, it is perfectly repeatable, as long as the distance from start of encode to audio is EXACTLY the same, but if that distance is changed by even one sample, the SRC result is completely different.

[...]

Why can't digital SRC do the same?


This is a misunderstanding. A digital signal shifted by 1 sample (within a limited space) IS NOT the same as the original signal, even if these leading/trailing samples have zero values. The "shifted" data truly represents a different (analogue) waveform! Or in other words, the zeroes "before" and "after" a piece of visible (digital) "waveform" contains (analogue) information, too!

I recommend a closer look at the Nyquist theorem. You seem to have a fundamentally wrong understanding about how digitally sampled signal work (no offence! Not understanding the sampling theorem is widely established in the audio "engineering" scene ). Keep in mind that the samples of a digital signal are infinitely small, the digital signal has no idea of the "between", and this implies that zeroes in a digital waveform can carry information which isn't visible directly.

Digital SRC is repeatable. It does this perfectly. Your experiment however is heavily flawed. You compared two different (continuous) waveforms, even if their digital representation looked similar. The SCR algos knew better and delivered correct results!

Most audio editors draw completely wrong waveforms. These naive drawings are probably the main reason why digital audio is so much misunderstood. This is also a good reason why naive digital null tests are pointless. Our ears, as well as recording and playback electronics don't care about the digital dataset. It's the continuous signal that counts! Remember, Nyquist mentions an input and output bandlimiting filter! This is the essential point, but people prefer to ignore at least one half of the theorem and like to call digital audio "problematic", "flawed" or worse: "stepped". It's wrong, digital audio is continuous. Technically speaking, modern digital audio is even easily 100 times more continuous than the best "analogue" storage technology can offer. Yes!

http://www.youtube.com/watch?v=cIQ9IXSUzuM
Quote
2
walter88
Thread Starter
#8
16th July 2013
Old 16th July 2013
  #8
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by Johnscottguitar View Post
So if we took 2 samples out of the 96 and did the null test at 48 it should

work
Right. Put the two 48k files on separate tracks in a DAW, exactly align the ends of the files (that will align the preceding audio, because samples were only removed from the front of the 96k copy), invert the phase on one of
the tracks, and playback both together. They will not completely cancel because the audio in the two 48k files is not the same. The SRC from 96 to 48 has been done two different ways with two different results from the same, identical 96k audio.

I guess this is how all digital SRC currently works, but I'd like to know if there is a fix, because it leaves the chance for "many different versions of the same thing" out there that can't be proven they're the same thing (because they're measurably different). Plus it's technically not what anyone would expect (at least not me). I thought SRC was just a fixed math process that never varied for the same source program, but apparently that's not the case.

-----------------------------

EDIT: the 96 to 48 test I described above does not illustrate the 96 to 44.1 problem I was originally talking about (the 96 to 48 works fine and nulls without a problem, no matter the leadin on the 96k original). If doing the test above, do it 96 to 44.1 to see the problem I was talking about.

Last edited by walter88; 17th July 2013 at 12:05 AM.. Reason: mistakenly identified 96 to 48 as a problem.
#9
16th July 2013
Old 16th July 2013
  #9
Lives for gear
 
FabienTDR's Avatar
 
Joined: Mar 2012
Location: Frankfurt/Germany

@Walter, this is definitely not how SRCs work. SRCs are most of all bandlimiters! In other words, they are best imagined as filters (rather than trashing/guessing machines). They make sure that the output signal can be stored and reconstructed from the target format without introducing non-linear garbage (aliasing in this case).


On a final note. A time shifted version of exactly the same continuous signal will have a totally different representation when stored digitally. But the re-constructed and inverse time shifted continuous waveforms will null perfectly! Again, looking at the digital storage data of audio signals is pointless. It has nearly no meaning in the context of human perception.
#10
16th July 2013
Old 16th July 2013
  #10
Lives for gear
 
jackbraglia's Avatar
 
Joined: Jul 2010
Location: NYC

Quote:
Originally Posted by FabienTDR View Post
This is a misunderstanding. A digital signal shifted by 1 sample (within a limited space) IS NOT the same as the original signal, even if these leading/trailing samples have zero values. The "shifted" data truly represents a different waveform! Or in other words, the zeroes "before" and "after" a piece of visible "waveform" contain information, too!
Fabien is spot-on here. And it demonstrates how many people have a fundamental misunderstanding of how sampling works.

But on a side note; why does this even matter? The audio will sound the same whether it nulls or not.
#11
16th July 2013
Old 16th July 2013
  #11
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

you need to use something like iZotope RX2 to see the interpolated waveform. switch between linear and 64x interpolation and compare.
Alexey Lukin
Verified Member
#12
16th July 2013
Old 16th July 2013
  #12
Lives for gear
 
Alexey Lukin's Avatar
 
Joined: Dec 2007
Posts: 972

Verified Member
Quote:
Originally Posted by walter88 View Post
I took a 96k file, made a copy of it, and on the copy I cut off one sample from the very front of the file and saved it. Then I put both of those 96k files (the original and the copy) into an SRC program and converted them to 44.1k.
The output files are different because when you shift the file at 96k by 1 sample, it corresponds to a time shift of your 44k file by 0.46 samples. Would you expect the file to be the same if you time-shift it by 0.46 samples? No.
Quote
3
walter88
Thread Starter
#13
16th July 2013
Old 16th July 2013
  #13
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by FabienTDR View Post
On a final note. A time shifted version of exactly the same continuous signal will have a totally different representation when stored digitally. But the re-constructed and inverse time shifted continuous waveforms will null perfectly! .
Fabien, Multiple 48k SRC passes from identical 96k sources (not time shifted) DO all null. All I'm saying is if the audio in the source 96k is time shifted (by removing leading samples), the re-constructed inverse time shifted 48k don't null, as I would have originally expected. The AUDIO in the two 48k files is not identical, although both were processed by the same converter. So I agree both 48k files are correct. That's not my point. My only point is the repeatablility from the same original audio (disregarding the offset from the 2 missing samples).

Does it matter? Maybe. If there's a measurable difference in the two 48k files (which there is), somebody somewhere can hear the difference.

I'm just looking for a possible fix for this (besides ensuring exact sample accurate leadin every time).

.... (has anybody even tried this?)
#14
16th July 2013
Old 16th July 2013
  #14
Lives for gear
 
FabienTDR's Avatar
 
Joined: Mar 2012
Location: Frankfurt/Germany

I get your point. Have you compared the continuous waveforms? They won't null, but they will be extremely close, probably up to -130dB over the full audible bandwidth. I think you would definitely say both are the same. Only their digital data is different, but the reconstructed waveforms will null on any analogue measurements equipment (over the audible bandwidth).

There's nothing to worry about, except that the peak level of the digital storage will be different (it had no proper meaning anyway). The peak level of the continuous signals will be virtually the same.

walter88
Thread Starter
#15
16th July 2013
Old 16th July 2013
  #15
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by FabienTDR View Post
I get your point.

Actually I'm wrong about the 48k, I guess because of the multiple from 96. Those will null if samples are removed from the orig 96K, and the 48k files realigned. I was making assumption. Sorry, sorry.

My issue is now ONLY about the 96k to 44.1 where the repeatability is an issue. Those tests I still stand by. Alexey explained why, I just want to know is there a possible fix?
#16
16th July 2013
Old 16th July 2013
  #16
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

add .46 samples of offset to one of the 44.1 kHz files you are trying to null and they will (most likely) null...
nms
#17
16th July 2013
Old 16th July 2013
  #17
nms
Lives for gear
 
nms's Avatar
 
Joined: Nov 2009
Location: Canada
Posts: 3,765

When you shift it by 1 sample you are forcing it to do this. There is no way around it as this has to happen.

A better test is to convert from 96 to 44 then back to 96 and try lining up the files. Do this and let us know what you find.
Alexey Lukin
Verified Member
#18
16th July 2013
Old 16th July 2013
  #18
Lives for gear
 
Alexey Lukin's Avatar
 
Joined: Dec 2007
Posts: 972

Verified Member
Quote:
Originally Posted by walter88 View Post
Alexey explained why, I just want to know is there a possible fix?
The only possible “fix” is to cut the 96 kHz file in multiples of 320 samples: 320, 640, 960, etc. Then your 44.1 kHz files will “match”.
walter88
Thread Starter
#19
17th July 2013
Old 17th July 2013
  #19
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by Alexey Lukin View Post
The only possible “fix” is to cut the 96 kHz file in multiples of 320 samples: 320, 640, 960, etc. Then your 44.1 kHz files will “match”.
That sounds like a lot of work . I guess I'll stick to the "keep the sample accurate identical leadin for all future SRC from this particular file" approach. Problem is, there are many ways to stray from that path in the course of a project (including DAW SRC renders with adjusted clip edges, etc.). Not that I'd ever do that, but there are a lot of options in the workflow that could easily generate technically different SRC results because of this. Not that the results would be "wrong", just unexpected.

So maybe I'll just forget about this completely. Unless someone wants to invent a magic wizard "make this audio always the same" sort of thing.

Honestly, being a naive engineer, I never expected this. I thought a 96k to 44.1k SRC would always create an identical 44.1 conversion, no matter what the leadin or leadout or whatever in the 96k source. This was a big surprise to me and a few other naive engineers I showed this to.
Alexey Lukin
Verified Member
#20
17th July 2013
Old 17th July 2013
  #20
Lives for gear
 
Alexey Lukin's Avatar
 
Joined: Dec 2007
Posts: 972

Verified Member
It's not dissimilar to an A/D converter: feed the same record twice, get different wave files. Nothing wrong with that.
#21
17th July 2013
Old 17th July 2013
  #21
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

pink noise generated at 96 kHz.
one file was SRC to 44.1 kHz, and one file had the first one second removed, then it was SRC to 44.1 kHz.
the files null to -inf except for the first one second that i chopped off one of the files...obviously.
it doesn't matter if you remove one sample or 44,100 samples from one file pre-SRC, the files will null if you line them up correctly.
Attached Files
File Type: wav pink96_src44.wav (1.68 MB, 8 views) File Type: wav pink96_minus1second_src44.wav (1.51 MB, 7 views) File Type: wav pink96_src44_null.wav (1.68 MB, 3 views)
#22
17th July 2013
Old 17th July 2013
  #22
Lives for gear
 
Joined: Feb 2013
Location: long beach california
Posts: 581

#23
17th July 2013
Old 17th July 2013
  #23
Lives for gear
 
Rust Creep's Avatar
 
Joined: May 2009
Location: Louisiana
Posts: 2,048

I hope all of this work and thought is going into some killed teacks

Sent from my HTC6435LVW
walter88
Thread Starter
#24
17th July 2013
Old 17th July 2013
  #24
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by stinkyfingers View Post
it doesn't matter if you remove one sample or 44,100 samples from one file pre-SRC, the files will null if you line them up correctly.
Thanks for doing this. But it does matter if you remove one sample or 44100 samples, because you removed exactly 44100 samples, and that's one of the magic numbers that works. Try removing one sample or ten samples or anything but one of the magic numbers, and the results can never be nulled.
#25
17th July 2013
Old 17th July 2013
  #25
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

again, the results can be nulled perfectly, you just need to time align them.
i have done all these tests and more so i tell you from experience.
by removing one sample, all you are doing is changing the duration of one of the files. the remaining samples are unchanged and get converted exactly the same in both files and will null.
walter88
Thread Starter
#26
17th July 2013
Old 17th July 2013
  #26
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by stinkyfingers View Post
again, the results can be nulled perfectly, you just need to time align them.
i have done all these tests and more so i tell you from experience.
by removing one sample, all you are doing is changing the duration of one of the files. the remaining samples are unchanged and get converted exactly the same in both files and will null.
Sorry, but I have to disagree. I get the same null result removing exactly 44100 samples here just as you did, but virtually anything else (including one sample and ten samples) can never be nulled. I'm using Wavelab Crystal Resampler. Mind telling me what converter you're using?

Last edited by walter88; 17th July 2013 at 07:16 AM.. Reason: added Resampler
Quote
1
#27
17th July 2013
Old 17th July 2013
  #27
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

i can't stress enough how important time alignment is to make the null.
you can not (sample accurate) align the files at 44.1 kHz, so you can't make the null. you can try something like Diffmaker, which uses 'sub-sample' time alignment, but that is pretty much just oversampling both files. you can do that manually if you have a good editor & eyes.
anyway, for SRC i use iZotope linear phase and/or Reaper's 'extreme' setting. it doesn't matter, though. the 'problem' is not the SRC, it's the methods you are using for testing.
walter88
Thread Starter
#28
17th July 2013
Old 17th July 2013
  #28
Gear maniac
 
Joined: Feb 2013
Posts: 179

Thread Starter
Quote:
Originally Posted by stinkyfingers View Post
i can't stress enough how important time alignment is to make the null.
you can not (sample accurate) align the files at 44.1 kHz, so you can't make the null. you can try something like Diffmaker, which uses 'sub-sample' time alignment, but that is pretty much just oversampling both files. you can do that manually if you have a good editor & eyes.
anyway, for SRC i use iZotope linear phase and/or Reaper's 'extreme' setting. it doesn't matter, though. the 'problem' is not the SRC, it's the methods you are using for testing.
So you've tried one sample or ten sample removal, convert in iZotope, and you've been able to subsample align in Reaper and create a null? Sorry, but I can't recreate here with any subsample positioning in Reaper.
Quote
1
nms
#29
17th July 2013
Old 17th July 2013
  #29
nms
Lives for gear
 
nms's Avatar
 
Joined: Nov 2009
Location: Canada
Posts: 3,765

Quote:
Originally Posted by stinkyfingers View Post
again, the results can be nulled perfectly, you just need to time align them.
i have done all these tests and more so i tell you from experience.
Alas, this is not true at all my friend!

See for yourself.

Take a 96k file and SRC to 44.
Then take the same 96k file and delete the first sample before you SRC to 44.
Line up the waveforms and compare. They look different don't they. As you know, you won't be able to accurately time align due to the subsample shift so go ahead and upsample them both back to 96k.
Now align the files and try to null. It won't be possible. This is a result of the way the interpolation has happened during SRC.

You WILL however be able to null quite well if you are moving between even multiples such as 96-48-96 or 88-44-88.

@Walter - Why are you working at 96k? If you're not a Nebula or heavy Virus TI user work at 88.2khz. It's not a coincidence that 88.2 is twice the rate of 44.1 and that 96 is twice the rate of 48!

Use 96khz if you're working for video and 88.2khz if your end product is 44.1khz.
#30
17th July 2013
Old 17th July 2013
  #30
Lives for gear
 
stinkyfingers's Avatar
 
Joined: Apr 2011
Location: Vermont

Quote:
Originally Posted by nms View Post
Alas, this is not true at all my friend!

See for yourself.
ok, maybe later...

edit: as i said in post #2, the difference from this process will be from LPF. pic attached of difference using iZotope ultra steep linear phase.
this is from a 909 loop made in Logic @ 96 kHz. i (duplicated and) removed the first sample of one file, src both to 44.1 kHz, then src them back to 96 kHz and nudged one (missing 1 sample) one sample forward to null.
i know this is not 'technically' a null, but since gearslutz law dictates that no human can hear a cent past 20 kHz, it is 'effectively' a null.
Attached Thumbnails
Why Isn't Digital SRC Perfectly Repeatable?-difference.jpg  
New Reply Submit Thread to Facebook Facebook  Submit Thread to Twitter Twitter  Submit Thread to LinkedIn LinkedIn  Submit Thread to Google+ Google+ 
 
Topic:
Thread Tools
Search this Thread
Search this Thread:

Advanced Search
Forum Jump
 
Register FAQ Search Today's Posts Mark Forums Read

SEO by vBSEO ©2011, Crawlability, Inc.