Welcome Guest ( Log In | Register )

Drive offset and its affect on last sector during CD rip
post Dec 7 2012, 04:41
Post #1

Group: Members
Posts: 20
Joined: 7-December 12
Member No.: 105016

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
Go to the top of the page
+Quote Post
Start new topic
post Dec 10 2012, 11:17
Post #2

Group: Members
Posts: 20
Joined: 7-December 12
Member No.: 105016

It with some trepidation that I post again but what Iím attempting to understand is causes for the variation in ripping result. I believe it is correct to say that where the offset of the drive is less than or equal to 588 then reading of lead-out is irrelevant; the drive should be perfectly capable of reading the last 2352 bytes or 588 samples.

When I enable reading into the lead-out (EAC), the ending portion of the WAV file is different again. Whether the drive actually went into the lead-out or failed and returned garbage or silence is academic; the content of the WAV ending is different. In my case, it is different enough that the last track did not validate as accurate with AR. So in my case, setting for reading into the lead-out is not a solution if you then canít use the results with AR.

It is on that basis that I made the comment about AR database accuracy. Reading back perhaps I wasnít clear. What I meant was that if everyone suddenly started reading into the lead-out or made other settings changes that affected the final portion of the WAV, there would never be a consistent AR value (for last track) to compare with. This I expect is the very reason AR does not use last 5 sectors for it AR calculation.

Your reply suggests that EAC is buggy or at least poorly handles reading of the ending of the last track's sector and lead-out. If EAC is so bad with last track Iím surprised itís not a more widely discussed topic. How does one know they have the most accurate extraction possible if no one has taken the time to question and/or compare the WAV CRC or FLAC generated MD5, as AR alone does not vouch for the full WAV? In your experience, is dbPowerAmp any better with its extraction? I see it has a trial option so no harm to take a look and compare itís behavior across the systems. Iíve also got some tools tucked away that will RAW read the CD including TOC so should be able to check if the drive(s) can read the lead-out and compare the extracted sectors to the LBA within the TOC.

Finally, let me put a different slant on it; what if those last samples contained music? What if an error occurred reading those samples but it was outside of the range that AR uses for it confidence value? This is why when I rip I compare CRC and/or MD5. Of course, a consistent checksum only confirms I read the CD accurately twice or more; it doesnít compare against anyone else. I could still have bad and/or different samples not tested by AR. I had never given this thought until a different system gave a different MD5 and yet still passed AR.

Anyway, I think Iíve probably laboured enough; time to test some alternatives. Thanks for the reply as it has helped.

This post has been edited by kudabird: Dec 10 2012, 11:18
Go to the top of the page
+Quote Post

Posts in this topic
- kudabird   Drive offset and its affect on last sector during CD rip   Dec 7 2012, 04:41
- - Cynic   I think this has to do with overreading, since bot...   Dec 7 2012, 15:49
- - psycho   kudabird, your MD5 hashs tell us nothing, if you d...   Dec 7 2012, 17:31
|- - kudabird   QUOTE (psycho @ Dec 8 2012, 02:31) kudabi...   Dec 8 2012, 22:55
- - greynol   QUOTE (kudabird @ Dec 6 2012, 19:41) Is t...   Dec 9 2012, 16:35
|- - kudabird   QUOTE (greynol @ Dec 10 2012, 01:35) QUOT...   Dec 10 2012, 01:27
|- - greynol   QUOTE (kudabird @ Dec 9 2012, 16:27) A se...   Dec 10 2012, 05:38
- - kudabird   It with some trepidation that I post again but wha...   Dec 10 2012, 11:17
|- - greynol   While I can lead you to water... QUOTE (kudabird ...   Dec 10 2012, 16:31
- - kudabird   Hello. I actually started a reply but deleted my d...   Dec 11 2012, 23:21
|- - greynol   QUOTE (kudabird @ Dec 11 2012, 14:21) I f...   Dec 12 2012, 02:08
- - spoon   Actually I would have to expand on what I said 4 y...   Dec 12 2012, 01:24
|- - kudabird   Thanks Spoon. And I used dBPA and compared to EAC ...   Dec 12 2012, 02:12
|- - kudabird   I was all set to concede the use of LBA was mispla...   Dec 12 2012, 02:49
- - greynol   Again, there is no LBA in Red Book. To use the te...   Dec 12 2012, 02:56
|- - kudabird   QUOTE (greynol @ Dec 12 2012, 11:56) So c...   Dec 12 2012, 04:01
- - greynol   LOL. Well I do have egg on my face and humbly adm...   Dec 12 2012, 04:10
|- - kudabird   All good. And I've got to say I too had a bit ...   Dec 12 2012, 04:23
- - spoon   There is nothing wrong with using the Term LBA and...   Dec 12 2012, 12:08
- - greynol   Again(!) Red Book makes no mention of LBA. CD...   Dec 12 2012, 17:15
|- - hyman   Elaborating from Spoon to make it more clear for o...   Dec 12 2012, 17:36
|- - greynol   QUOTE (hyman @ Dec 12 2012, 08:36) it see...   Dec 12 2012, 21:53
- - spoon   I thought this thread was about cd ripping...not a...   Dec 12 2012, 21:42

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 20th April 2014 - 04:17