I believe this has something to do with the "sample offset" of your drive.
To quote "Dick's CDR Page:"

"The sample offset is the measure of your CD-ROM's inaccuracy in reading the
proper location on the disc.  For example if [a program] wants the drive to
read sector 10000, the drive would actually read 10500.  While 500 sectors
seems like a lot it is only a tiny fraction of a second.  The offset in no
way affects the sound quality - you can produce fine discs without setting
it, but they won't be true, exact clones of the original."

If you use cdparanoia(1) to "rip" an audio disc, there is a -O <sample
offset> option which should theoretically allow you to produce bit-true
WAVs.  I'm not sure how you determine what the sample offset for your drive
is, though.  I played around with this for a while one night, but eventually
gave up.  This is ridiculously easy to do on Windows if you use a program
called EAC (Exact Audio Copy).  There is a Wizard that will help you
determine what the sample offset is for your drive.  Once you determine this
value and set it in the software, you can do WAV > CDDA > WAV and the
checksums of the original and ripped WAVs will match.  I would sure love to
get that working in Linux.  I never thought to try extracting WAVs using dd.
I'm going to try that tonight....

~Jeff

On Tuesday, November 26, 2002 2:17 PM, ShieldX wrote:

> I don't know if it matters to anyone but "readcd" does not 
> produce MD5sum
> verfiable output, i.e., they Don't match.
> Also, with each iteration of cdda2wav > cdrecord, (read 
> audio, burn audio,...)
> the MD5sums change as well.
> 
> Perhaps someone would shed some light on this.
> 
> ShieldX