Home |
Search |
Today's Posts |
#1
|
|||
|
|||
bit for bit file comparing utility
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 |
#2
|
|||
|
|||
bit for bit file comparing utility
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." |
#3
|
|||
|
|||
bit for bit file comparing utility
"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. |
#4
|
|||
|
|||
bit for bit file comparing utility
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 |
#5
|
|||
|
|||
bit for bit file comparing utility
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 |
#6
|
|||
|
|||
bit for bit file comparing utility
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 |
#7
|
|||
|
|||
bit for bit file comparing utility
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 |
#8
|
|||
|
|||
bit for bit file comparing utility
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 |
#9
|
|||
|
|||
bit for bit file comparing utility
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. |
#10
|
|||
|
|||
bit for bit file comparing utility
"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? |
#11
|
|||
|
|||
bit for bit file comparing utility
"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. |
Reply |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
AUDIO FILE EDIT: HELP PLS! | General | |||
What Software for Editing Sound on PC | General | |||
What Software for Editing Sound on PC | Audio Opinions | |||
unknown audio file format | General | |||
Q: SoundForge copying markers from one file to another? | Pro Audio |