Drive offset and its affect on last sector during CD rip Options

[kudabird]

Hello. As per the title I have a few questions regarding drive offset and its affect with ‘last sector’ handling during CD ripping.

Some years back I ripped my CD collection using EAC to single image (album) FLAC with cuesheet. Not sure why but a week or so back I decide to have a look at CueRipper and grabbed a random CD (Pink Floyd – The Final Cut). I actually hit an issue with CueRipper with it raising an exception during gap detection (as per another thread) but that’s not the reason for the post.

What I discovered was that the MD5 within the FLAC was different to my earlier ripped master. My initial reaction was along the lines of what the...

As it happens I have 2 notebooks and 2 PC. The PC that was used for the ripping was retired but I managed to resurrect it and repeat the rip and it got the same MD5 as what was in the original (so the same system got the same MD5).

I then tried all others systems and found a relationship between the offset. Somewhat by chance, two systems have an identical offset of +102 and two have an identical offset of +667. Each system with the same offset results in the same MD5. In all cases, AccurateRip results (both AR1 and AR2) following ripping are fine.

Next step was to compare WAV files so I decoded each of the FLAC and compared within EAC. Both files are bit identical right up to what I would call last sector with the variation occurring in last 0.013’ of the WAV file (so last 1/75).

Upon reflection I expect this is probably quite normal and I note that AccurateRip does not use last 5 sectors (2940 samples) for its calculation. I presume this is intentional due to drive variation and the like.

I guess the question is should I be concerned about this or is this a case of OCD getting the better? Is there any ripping means that overcomes the variation of offset and drive capability that will result in bit identical WAV? Keep in mind I’m asking about the very last samples; I expect everything up to then to be bit identical which is the purpose of the offset value used with ripping.

It does seem to me that consistency will only be achieved where the drive has an absolute offset of less than or equal to 588. Any offset larger than that will result in a variation subject to EAC settings, offset value and drive capability when ripping the last samples.

Just out of curiosity, the FLAC MD5 for the album as above comes out as per below. I’d be interested in the value that others have for comparison as it will confirm my thinking to the cause and maybe as to which is the ‘better’ image copy. Thoughts?

Offset +102 FLAC MD5 9f9bbafb2937a6466c6ca54ab472b598
Offset +667 FLAC MD5 1111c22a05506dc693b57dc83cca727e

[spoon]

There is nothing wrong with using the Term LBA and CD ripping - CD ripping is addressed (through SCSI commands) using either MSF (minute seconds frames) or LBA (logical block address), EAC AFAIK uses MSF internally, dBpoweramp uses LBA addressing.

For reference to CDDA and LBA have a look at any of the SCSI Multimedia command documents (mmc-2, mmc-3, etc)

MSF was designed so the reading location of an audio CD can go straight to the display of a cheapo audio player, but any CD computer drive must be able to translate internally between LBA + MSF for all relevant SCSI commands (TOC read, read raw, etc)...and there are drives which even fail this simple task (a TOC read in MSF returns different times than TOC read in LBA, dBpoweramp reads both in the debug log, so we spot this time to time).

LBA is actually the better way of addressing, as the chance of bugs is greatly reduced, for example subtracting 135 frames from a LBA address of 12345 is a simple minus, where as subtracting 135 from a 20/3/45 address, is not to easy.

This post has been edited by spoon: Dec 12 2012, 12:37