Ok - it was a long weekend involving travel, etc., so it took me until last night to perform the tests I had earlier indicated I would undertake. First, just for the record, although I'm 6'2", that's my only possible advantage in any physical confrontation - I'm a wuss and would probably just stand there and get pummelled. Anyway, for these tests I used the following software - Audiograbber v1.62, RealJukeBox2 Plus v1.0.2.178 (Beta), and the slimmed down version of Adaptec's CD Creator software that came with my Dell computer. I wanted to verify that I could retrieve (ie, rip) and write identical files. I used three songs off of Hall and Oates Master Hits. First off, I read them to HD twice each using Audiograbber. I compared their 64-bit checksum using Audiograbber and each of the parallel files matched it's partners exactly. Audiograbber also has an option to compare two music files, and each of the parallel files matched exactly. Finally, using Windows Properties, each of the parallel files reported exactly the same number of bytes. Then I used RealJukeBox and read the same three files to disk and compared them in the same ways to the files I read using Audiograbber. Again, the checksums matched identically, the comparison of each to it's parallel matched identically. Interestingly, the Windows Properties showed that the RJB files were a few Kb larger than the Audiograbber files - on the order of 5K out of 50Mb. Then I did the same test using Adaptec's program. This time the checksums wouldn't calculate - according to the Audiograbber software, if a song file doesn't end in silence, a proper checksum can't be calculated and is indicated by an 'X' at the beginning of the checksum. This is what occurred with the Adapted files. The files also did not compare correctly to the original Audiograbber files. Looking at Windows Properties, the Adaptec files were all either 12 or 14 bytes larger than the Audiograbber files, and looking at the dump of "mismatched bytes" in the compare program it appeared that there were two extra bytes early in the Adaptec files, after which everything lined up perfectly. I don't know what the format of .WAV files is, and I don't know what the Audiograbber program is doing precisely when it calculates Checksums and does compares. The fact that I can repeatedly use an extraction program on a CD song "file" and get exactly the same file, even though they differ slightly from a parallel exercise with a different extraction program leads me to believe that there is a variable-length field in a header someplace that each program utilizes slightly differently, and/or a way of handling the last block of data and the end-of-file marker that would explain the slight differences encountered. Just to prove to myself that you'd get much different (and undoubtedly worse) results using the sound cards conversion, I "ripped" the same three songs using the "analog" setting in Audiograbber's config. Sure enough, the files were all different from the original digital copies, and multiple "rips" produced different files for the same songs. So, then I took my original three songs read with Audiograbber and burned them to a CDR. I then took the CDR and read each of the song files to disk using each of the three programs. I compared each of the files created by reading the CDR to the same file created from the original CD for each program. Audiograbber and RJB compared identically in all three cases. Adaptec did not. Again, I think they're doing something with a header someplace that doesn't have anything to do with the music data, but I have no proof of that. However, it is clearly possible to read/write/read/write ad infinitum with the right computer hardware / software combination and get "perfect" copies of CD and CDR data. Note that I'm not extrapolating that a CDR done in this way will absolutely sound the same as the original CD played back on a stereo system. There may be some physical properties of CDRs that are different than CDs that result in typical CD player/transports to be less reliable in reading them. I find that hard to believe, but nothing I have done here refutes it in any way. What I am definitely saying, though, is that it's easy to retrieve every data bit on a CD or CDR with extremely inexpensive hardware. I also know from professional experience that delivering data from point A to point B "perfectly" is a solved problem, so if getting the data bits to the D/A of choice in our current form is problematic, as it has been widely documented, then we should be pressing for a better interconnect technology, because it doesn't have to be that way.
