bit for bit file comparing utility

[mr c deckard]

anyone know of a simple win9x/xp based utility that will do bit for
bit comparison of two files and display the result as percentage
error? seems like an easy brute force way to check digital
interconnects and cd-burns. . .

how do you perform this test?

best,
chris deckard

[Scott Dorsey]

mr c deckard > wrote:
>anyone know of a simple win9x/xp based utility that will do bit for
>bit comparison of two files and display the result as percentage
>error? seems like an easy brute force way to check digital
>interconnects and cd-burns. . .
>
>how do you perform this test?

You can do it with diff on Unix, and I know the Cygnus kit will give you
diff on a PC machine.

But, it doesn't tell you anything useful, because all of the error correction
has been done long before that file is created. So you are never going to
see errors unless they are just so bad they are unusable.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Arny Krueger]

"mr c deckard" > wrote in message
om
> anyone know of a simple win9x/xp based utility that will do bit for
> bit comparison of two files and display the result as percentage
> error? seems like an easy brute force way to check digital
> interconnects and cd-burns. . .
>
> how do you perform this test?

You can find such a utility in both CDEX and EAC, which are audio CD ripping
programs. They both automatically synchronize and if necessary resynchronize
the two files, to minimize the size of the error report. You can find the
home pages for either of these programs with google.

If you don't find the procedure for doing this test self-explanatory once
you have one of these utilities on hand, post again.

BTW, one good test of a ripping programs drive is to rip a CD twice.
Preferably, you should to this with a CD that is a bit bruised and beaten,
but for which no errors are reported during ripping.

Then compare the two files that you get. They should be bit-identical.

Most of the errors that occur during ripping tend to produce random
results. So, if you get the same files twice, you've probably got a 100.00%
reliable rip.

This is also a good thing to do to confirm the correct installation of a CD
burner. You might want to try it every time you change media.

[Michael R. Kesti]

mr c deckard wrote:

>anyone know of a simple win9x/xp based utility that will do bit for
>bit comparison of two files and display the result as percentage
>error? seems like an easy brute force way to check digital
>interconnects and cd-burns. . .

Various versions of Un*x/Linux include the "cmp" utility that does binary
file comparison. One can often find Windows equivalents of such. The
MKS Toolkit from Mortice Kern Systems is one such example, but would be
overkill for just this one function. A search on the terms "binary file
compare" on http://www.shareware.com turned up a few possibilities. None
of these are likely to return your "percentage error", but may provide
enough information to suit.

>how do you perform this test?

If I was coding this I'd open() the files and stat() them to determine
whether they are the same size, then read() them into memory buffers
and index through those buffers comparing as I went while keeping count
of bits/bytes/whatevers that are and aren't equal.

--
================================================== ======================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
| - The Who, Bargain

[RB]

Windows XP has the fc (file compare) command built-in. Run from the cmd
console. First, take a look at the many command line switches thusly:

fc /?

RB

"Michael R. Kesti" > wrote in message
...
> mr c deckard wrote:
>
> >anyone know of a simple win9x/xp based utility that will do bit for
> >bit comparison of two files and display the result as percentage
> >error? seems like an easy brute force way to check digital
> >interconnects and cd-burns. . .
>
> Various versions of Un*x/Linux include the "cmp" utility that does binary
> file comparison. One can often find Windows equivalents of such. The
> MKS Toolkit from Mortice Kern Systems is one such example, but would be
> overkill for just this one function. A search on the terms "binary file
> compare" on http://www.shareware.com turned up a few possibilities. None
> of these are likely to return your "percentage error", but may provide
> enough information to suit.
>
> >how do you perform this test?
>
> If I was coding this I'd open() the files and stat() them to determine
> whether they are the same size, then read() them into memory buffers
> and index through those buffers comparing as I went while keeping count
> of bits/bytes/whatevers that are and aren't equal.
>
> --
> ================================================== ======================
> Michael Kesti | "And like, one and one don't make
> | two, one and one make one."
> | - The Who, Bargain

[mr c deckard]

hey thanks for the info, all, (esp. the fc util on winXX). my linux
box is currently a real-time efx box, so isn't networked to the other
computers . . .

>
> You can do it with diff on Unix, and I know the Cygnus kit will give you
> diff on a PC machine.
>

what i was wanting to test specifically are some s/pdif interconnects.
i figured if i transfered the file via ftp, then s/pdif, i could then
cmp (or fs) them to see how accurate the transfer was.

is there something i'm missing? if every byte correlated bit for bit,
there could be no possible error, no?

cheers,
chris



> But, it doesn't tell you anything useful, because all of the error correction
> has been done long before that file is created. So you are never going to
> see errors unless they are just so bad they are unusable.
> --scott

[David Satz]

mr c deckard wrote:

> hey thanks for the info, all, (esp. the fc util on winXX).

With files that are supposed to be identical, you'd need to use fc /b
since without the /b switch, the file comparison will end as soon as
a Ctrl+D character is encountered (treated as an end of file marker).


> what i was wanting to test specifically are some s/pdif interconnects.
> i figured if i transfered the file via ftp, then s/pdif, i could then
> cmp (or fs) them to see how accurate the transfer was.
>
> is there something i'm missing? if every byte correlated bit for bit,
> there could be no possible error, no?

Two problems that I see:

[1] If you're comparing an existing wave audio file to a file you've made
by recording a data stream, the file comparison utilities will work only
if you start and stop recording the data stream at EXACTLY the right
moments. The receiver circuit and the drivers on your S/P-DIF input
device will generate idle data before and after, so you really need a
way to synchronize two files that don't have the same beginning and
ending times, and just compare what they have in common.

Similarly, the software that stores the incoming stream as a wave audio
file may put different header information into the file than what is in
your existing wave audio file, so the two might not compare exactly even
if their audio content is identical.

[2] As Scott Dorsey pointed out, you may not be measuring what you expect,
because of error detection/concealment/correction circuitry in the sending
device. But in some applications you'd be testing exactly what you do
want to test, so as long as you're aware of the issue ...

--best regards

[Justin Ulysses Morse]

David Satz > wrote:

> [1] If you're comparing an existing wave audio file to a file you've made
> by recording a data stream, the file comparison utilities will work only
> if you start and stop recording the data stream at EXACTLY the right
> moments. The receiver circuit and the drivers on your S/P-DIF input
> device will generate idle data before and after, so you really need a
> way to synchronize two files that don't have the same beginning and
> ending times, and just compare what they have in common.

The solution is to edit the files before comparing them. Crop off any
"pre-roll" and "post roll" so both files begin with a specific waveform
"landmark" that you can easily find in your editor. Since you'll be
doing this on "test" files to confirm the integrity of your system, the
files are arbitrary anyway and you can edit them as you like.

> [2] As Scott Dorsey pointed out, you may not be measuring what you expect,
> because of error detection/concealment/correction circuitry in the sending
> device. But in some applications you'd be testing exactly what you do
> want to test, so as long as you're aware of the issue ...

I think it's a useful approach when you'd like to compare DSP processes
as well. Checking for bit integrity through an application, etc. If
you process with a compressor plug-in with the threshold all the way
up, or an EQ with all the controls set flat, do you get out what you
put in?

ulysses

[Justin Ulysses Morse]

Michael R. Kesti > wrote:

I think it's more useful to perform this comparison with an audio
program wo that the end result is a new sound file that shows you
exactly where any differences are. This is much more useful in
determining exactly what kind of problem you have. You can do it
"manually" by inverting polarity of one file and then summing them, but
I wish more programs had "compare" built in, like SoundDesigner II did.
Anyway, once you generate the difference file, you can simply search
for the peak in the file, and if there was no difference between the
two original files then all samples will be zero and there will be no
peak.

ulysses


> mr c deckard wrote:
>
> >anyone know of a simple win9x/xp based utility that will do bit for
> >bit comparison of two files and display the result as percentage
> >error? seems like an easy brute force way to check digital
> >interconnects and cd-burns. . .
>
> Various versions of Un*x/Linux include the "cmp" utility that does binary
> file comparison. One can often find Windows equivalents of such. The
> MKS Toolkit from Mortice Kern Systems is one such example, but would be
> overkill for just this one function. A search on the terms "binary file
> compare" on http://www.shareware.com turned up a few possibilities. None
> of these are likely to return your "percentage error", but may provide
> enough information to suit.
>
> >how do you perform this test?
>
> If I was coding this I'd open() the files and stat() them to determine
> whether they are the same size, then read() them into memory buffers
> and index through those buffers comparing as I went while keeping count
> of bits/bytes/whatevers that are and aren't equal.

[Arny Krueger]

"Justin Ulysses Morse" > wrote in message
m...
> David Satz > wrote:
>
> > [1] If you're comparing an existing wave audio file to a file you've
made
> > by recording a data stream, the file comparison utilities will work only
> > if you start and stop recording the data stream at EXACTLY the right
> > moments. The receiver circuit and the drivers on your S/P-DIF input
> > device will generate idle data before and after, so you really need a
> > way to synchronize two files that don't have the same beginning and
> > ending times, and just compare what they have in common.
>
> The solution is to edit the files before comparing them. Crop off any
> "pre-roll" and "post roll" so both files begin with a specific waveform
> "landmark" that you can easily find in your editor. Since you'll be
> doing this on "test" files to confirm the integrity of your system, the
> files are arbitrary anyway and you can edit them as you like.

This gets us back to the freeware utilities I mentioned about three days ago
that automatically synchronize the files before and during the comparison
process, right?

[L David Matheny]

"mr c deckard" > wrote in message om...
> anyone know of a simple win9x/xp based utility that will do
> bit for bit comparison of two files and display the result as
> percentage error? seems like an easy brute force way to
> check digital interconnects and cd-burns. . .
>
> how do you perform this test?
>
There's a utility called WinDiff on the Win98 CD that can do
file or directory comparisons. It can show graphically where
the two files differ, but I don't think it can give a percentage.
The following is copied from an earlier post to another NG:

On your Win98 CD look in Tools / Reskit / File for WinDiff.
It's there on my SE CD, anyway. It allows comparing of the
actual file contents in two directories, not just directory info.
I think you're supposed to install this stuff as a kit, but I got it
to work by just copying windiff.exe, windiff.hlp and gutils.dll
to drive c: in Program Files / Accessories. I then created a
shortcut to windiff.exe in the Start Menu under Accessories.
(Rename the shortcut to just "WinDiff".) It's been very handy.