A "bit perfect" audio capture means that Every. Single. Bit. in the capture is the same as what's stored on the digital medium (in this case, the digital track on an LD).

Some older sound cards did digital post-processing (programmed in the driver) on the TOSLINK input (e.g., band-pass filtering) without notifying the user and without giving the user a way to disable it. Hell, some even did it in the hardware.

I know this sounds absurd since all the sound card needs to do is dump the PCM bytes it receives over the TOSLINK input onto the HDD, but this wasn't (and isn't) always the case. This is why some sound cards advertise "bit perfect" audio capturing.

It's not a gimmick. It's a response to the stupidly-written overzealous drivers of yesteryear.

zeropc said:

thanks antcufaalb :)

is there a way to test this?

http://www.head-fi.org/t/463089/is-your-s-pdif-bit-perfect-heres-a-test

Also, here's another great explanation of "bit perfect": https://code.google.com/p/cmediadrivers/wiki/Bitperfect

AntcuFaalb said:

http://www.head-fi.org/t/463089/is-your-s-pdif-bit-perfect-heres-a-test

Does bit-perfect output prove anything about the input path?
I won't leap to that conlcusion.

zeropc said:

is there a way to test this?

Record something twice, thrice, or (n+1) times.
Compare them.
Do they match?

If they've been resampled, then they almost certainly won't match.
Zillion-to-one probability

Simpler? That's easy for you to say!
My M-Audio card don't have input level controls.

zeropc said:

2. multiple capture of the same file - 3 to be precise and they all looked the same. there was no change in the waveforms hight or what not...

Looked the same?!?
Your eyes can deceive you-- don't trust them.

Let the computer compare the data byte-for-byte.
Computers are good at that sort of thing.

Windows ships with FC.EXE (File Compare) while UN*X derivatives have their cmp (CoMPare).
OSX should have cmp command, yes?

Exact Audio Copy (EAC) offers a graphical interface to compare 16/44.1 WAVs sample-for-sample.

Cross-platform shntool is my personal favorite
.

Might be a false alarm.

When you made those recordings, did you press Record button before pressing Play?
If so, then you'd have some digital silence at the start of each WAV, and likely not the same amount each time.
That can easliy confuse shntool.
Shntool takes the first sample from the first file and compares it against the first sample from the second file.
They match-- both samples have a value of Zero (digital silence).
Likewise the 2nd samples from each file match each other,
and the respective 3rd samples match, etc. . . . because they're all Zeroes.
shntool would mistakenly conclude that the two WAVs are aligned, when they're probably not.
Later when it reaches 18% one file might contain Non-Zero data
while the other file is still silent zeroes. Hence the error.

Try trimming the digital silence from the start of each file first.

Actually shntool will presume the two files are already aligned, unless you tell it otherwise by using the "-s" option.
Then shntool would try to detect how much time-shift between files.
Not sure if xACT will pass that option to the underlying shntool, or not.

You could run shntool yourself from a command prompt, such as
shntool cmp -s Take1.wav Take2.wav
In that case the files needn't be perfectly aligned, but within three seconds (default setting).
Still might need to trim leading zeroes though to avoid a false positive as above.

If using xACT (presumably without the -s option?) then you'd have to align the files yourself before calling shntool.

^Yeah, that's weird.

Maybe it's time for sanity checks.
Let's begin with a raw recording, and no leading silence.
Press Play, wait until the music starts before pressing Record.
I'll call it Take3.wav

Should match itself (we hope!)
shntool cmp Take3.wav Take3.wav


Next we'll test if "-s" is working correctly.

echo 0:02 | shntool split Take3.wav
That should produce two output files:
split-track01.wav (should be exactly 2 seconds long, or 88.200 samples)
split-track02.wav (the rest of it)

shntool cmp Take3.wav split-track01.wav
shntool cmp -s Take3.wav split-track02.wav
shntool cmp -s split-track02.wav Take3.wav

Are the results as expected?

...