Topic: bit-transparency testing help

[Brian Skalinder]

Alright, so I'm starting to test the MT's bit-transparency at 24-bit.  I've identified two for-sure ways to test for bit-transparency, and am wondering if a third option is valid (at least temporarily).  My problem:  I don't currently have a functioning bit-transparent 24-bit soundcard.  (Eventually, I'd like to fix the sc problem, but let's not go there at the moment.)  The first two methods, currently unavailable to me:

<1> Scenario 1
Playback:  known bit-transparent soundcard
Record 1:  MT
Record 2:  n/a
Verify:  compare source file v. MT file

<2> Scenario 2
Playback:  V3
Record 1:  MT
Record 2:  known bit-transparent soundcard
Verify:  compare MT file v. soundcard-recorded file

So I'm wondering if the third scenario is a valid bit-transparency test:

<3> Scenario 3
Playback:  V3
Record 1:  MT₁
Record 2:  MT₂
Verify:  compare MT₁ file v. MT₂ file

The real question, I guess:  if the MT resamples its digital input, would one expect two different recorders to still output identical results when fed the same source?  In other words, is verifying MT₁ output = MT₂ output a valid bit-transparency test?  I'm guessing not, but...I thought maybe there's a chance that if they resample, no resample is precisely the same across different physical machines.

Anyone?

[Roving Sign]

I thought maybe there's a chance that if they resample, no resample is precisely the same across different physical machines.

Agree - I would not expect the resampled signals to match...similar, but not mathematically the same...

Does resample mean D>A>D? (thats my assumption)  - and isnt there something called "reclocking"? Is that different? (tangential...)

[Brian Skalinder]

Does resample mean D>A>D? (thats my assumption)

By "resample", I mean sample rate conversion (SRC), a changing of the digital data stream.  In the MT's case, this would mean resampling from one SR to the same SR since the digital input does not provide a way for users to change the sample rate when feeding the MT a digital source.  Re-clocking, as I understand, is a method of reducing jitter, but doesn't actually change the data points themselves.

[Brian]

I'm not so sure about scenario 3 unless you see different results.  If you get different results for scenario 3.....we have big problems......

[Brian Skalinder]

I'm not so sure about scenario 3 unless you see different results.  If you get different results for scenario 3.....we have big problems......

In one short test so far - more planned - I've gotten identical results from both MTs when feeding digi-in from my V3.  I just don't want spend more time in that scenario if it's not a valid method for testing bit-transparency.

[Brian]

i agree.  if you got the same results it doesn't tell you much. 

[L Ron Hoover]

Is this just a peace of mind thing, or are you hearing something that makes you wonder if the MT is bit accurate or not?

I am extremely pleased with MG300>V3>MT(24bit) now that I'm finally figuring everything out. (and getting with the times)

[Brian Skalinder]

Is this just a peace of mind thing, or are you hearing something that makes you wonder if the MT is bit accurate or not?

Peace of mind.  I've heard no audible artifacts running V3 > MT, and am thrilled with the combo.  Just curious, really.

[MattD]

I'm not so sure about scenario 3 unless you see different results.  If you get different results for scenario 3.....we have big problems......

In one short test so far - more planned - I've gotten identical results from both MTs when feeding digi-in from my V3.  I just don't want spend more time in that scenario if it's not a valid method for testing bit-transparency.

I agree with the above in that it's not a true test, since for all you know they really change the input in a systematic fashion. I might have an hour or two on Sunday or next weekend if you want to bring it by. I have two known bit-perfect sound cards that can do up to 24/96.

[Sebastian]

I don't think scenario 3 is a valid test. I expect that both MTs use the same A/D conversion routines (algorithms). So, when fed the exactly same signal via S/PDIF and the units in fact re-sample digital input, I would expect them both to resample the said signal identically - resulting in two identical files.

[Brian Skalinder]

Yeah, that's kinda what I figured.  Thanks for the feedback, everyone.  I just wasn't sure if traditional resampling methodologies perform their functions pseudo-randomly, or not.

MattD - I'll drop you a line off-board, hopefully we can do a proper test Sun or next weekend.

[live2496]

Hi Brian,
A simple way to check for resampling is to use rectangular waves.

Resampled waves will not look rectangular. They will look more like Batman's profile (so to speak).

To test with rectangular waves, use software to generate a one minute file. Then playback the file using a soundcard with an SP/DIF digital output. A true digital copy will look exactly like the original.

I use rectangular waves for all of my testing. It makes it very easy to spot any buffering problems in, say, a 24/96 2gb file visually. Also, using software you can cut the file in half, place half of the recording on adjacent track, align it and invert the phase. The mixed files will be a flat line.

With music recordings it takes two copies of the file to do a comparison. With square waves where the signal is repeating, you can just cut the file in half.

*** Warning: for everyones benefit who might read this. Turn the levels way down on your playback system, or turn your playback system off if you have a separate amp. Turn levels way down on your headphones. ***


Gordon

[Brian Skalinder]

Thanks, Gordon - good idea.  I'll have to try that with MattD, since my soundcard is futzing up at the moment.