IPB

Welcome Guest ( Log In | Register )

Drive offset and its affect on last sector during CD rip
kudabird
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
Replies
kudabird
post Dec 11 2012, 23:21
Post #2





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



Hello. I actually started a reply but deleted my draft for reasons that are somewhat obvious, then though why not. As is often the case, finding the right keywords for search is critical and I have now found an answer to my question. It’s from the dbPA forum some 4 years ago and answered by Spoon as it happens.

http://forum.dbpoweramp.com/showthread.php...ull=1#post76372

I actually had a genuine question; a desire to find out why the FLAC checksum with my rip was different across systems. Is that not a worthy goal? To do that I did have to test. Given this is HA which expects testing and evidence and not anecdote I find your comment ‘"Regardless, have fun with your experiments"’ to be quite out of order.

As you pointed out, it does seem that EAC resulting WAV file can and does differ depending on the drive offset and drive capability. I can replicate its behavior including to the point of AR failure even though the rip is valid. That might be common knowledge for you or you may well have be speculating about EAC but it is news to me and I expect others as well.

Regarding your comment "‘I'd wager to guess that most people simply configure their drives correctly and move on"’. Are you sure? I say the contrary is equally likely. Given the EAC behavior, that it has a large install base and that large offset drives are somewhat commonplace, the fact that it does not appear to be a discussed topic tells me people are unaware and are not testing their rips. How would they know if they have their configuration setup correctly including for AR submission?

Finally your comment "‘I'm fairly certain the Red Book specification does not call for the use of logical block addressing, nor does it use the term sectors, for that matter"’. Agreed, but we are not discussing playback. The topic is DAE and the terms sector and LBA are commonplace in that context and you would know that.

I actually think I had a legitimate question and I tried to present it as accurately as I could; I’ll let other's judge what I had posted. I participate in forum here in Australia and I must say it’s unusual to see a question so sidetracked for semantics so early on. Is that what I can expect from HA in the future? In part I registered as I saw a recent post regarding command line manipulation of FLAC metadata and as it happens I have some VBScript that I wrote for that purpose, as well as transcoding with retention of metadata. They can be used as-is but easy enough for the average Joe to customize though now I’'m not sure I can be bothered.

This post has been edited by kudabird: Dec 11 2012, 23:36
Go to the top of the page
+Quote Post
greynol
post Dec 12 2012, 02:08
Post #3





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (kudabird @ Dec 11 2012, 14:21) *
I find your comment ‘"Regardless, have fun with your experiments"’ to be quite out of order.

I was being quite sincere. I did not in any way want to discourage you from experimenting in order to gain further understanding as to what is going on.

From my point of view, the reason why your flac md5sums of the raw audio data were different depending on the drive is quite trivial; the data is different and the obvious explanation is that one drive can read farther to the end of EAC's calibrated range than the other and the samples in that area were non-null. This is hardly new territory (random link). While it may not have been covered much recently, it has been discussed with a fair amount of regularity for over a decade now. You're right in that you need to use the right search terms and those that are hyphenated "lead-out" might not show up easily, but I made sure to use them in my responses to you in hopes that you would conduct the research on your own. FWIW, of the over 8000 posts I have logged here, a sizable chunk is dedicated to DAE in general and ticky-tack things like overreading and AR in particular.

QUOTE (kudabird @ Dec 11 2012, 14:21) *
or you may well have be speculating about EAC but it is news to me and I expect others as well.

It is usually very obvious when I speculate; I either use qualifiers or I will come right out and say it. smile.gif

QUOTE (kudabird @ Dec 11 2012, 14:21) *
How would they know if they have their configuration setup correctly including for AR submission?

People around here either know the settings or follow our wiki or other online guides. EAC has an internal test for overreading and those who don't bother typically leave it disabled (which is the default, BTW). For those who dare to change it, there is no problem until a disc is read that has non-null samples in the area deemed by the drive as the lead-out, resulting in an error. I don't think it unreasonable to assume the next course of action is to investigate the problem online where a half-way thoughtful search will give plenty of good responses telling the user to disable the overreading setting, with a large portion of the results coming from this forum or from digital-inn.de, the official EAC support forum. Those interested in investigating further are generally most successful when they run tools to spot differences (EAC and foobar2000 come to mind) and/or load tracks into a wave editor.

QUOTE (kudabird @ Dec 11 2012, 14:21) *
The topic is DAE and the terms sector and LBA are commonplace in that context and you would know that.

Sector, yes; LBA? No; not at all.

Using the term LBA with CDDA basically raises a red flag indicating a fundamental misunderstanding of CDDA. I suspect it is this very misunderstanding that is the reason why you're having difficulty.

Through experimentation you will hopefully discover this, since you appear unwilling to listen to what I have to say. smile.gif FWIW, I strongly urge you to use a wave editor as one of your primary tools!

QUOTE (kudabird @ Dec 11 2012, 14:21) *
I participate in forum here in Australia and I must say it’s unusual to see a question so sidetracked for semantics so early on.

I wouldn't be so quick to dismiss being told that LBA has no place in CDDA as semantics.

PS: Reading spoon's reply I guess we can add another term being misapplied to DAE. They include, but are not limited to: jitter, sectors, AccurateRip "CRC" and now LBA. Joy! emot-toot.gif

Let this discussion serve as an example about how attempting to take a term like LBA literally can be confusing:
QUOTE (kudabird @ Dec 9 2012, 16:27) *
A sector size is 2352 bytes or 588 samples. If a drive does not have to extend into the lead-out, in other words the required samples can be read within the last sector then yes, I would expect a level of consistency with the resultant WAV.


This post has been edited by greynol: Dec 12 2012, 03:44


--------------------
I should publish a list of forum idiots.
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: 16th September 2014 - 17:28