QUOTE (hyman @ Dec 12 2012, 08:36) <{POST_SNAPBACK}>
it seems to be a flaw in EAC's method of always reading (requesting) blocks of sectors upto 64kB per drive read command. When the rip nears the end of a CD EAC's method of reading can overshoot (past) the last drive readable sector of the CD which will result in an error and then all prior sectors which were readable in that block is dropped by the drive or returned as zeroes.
Thanks for the additional insight on what I thought was already accepted by the OP.
I hope this wasn't an attempt to reaffirm the portion of the discussion that drew my involvement:
QUOTE (kudabird @ Dec 6 2012, 19:41) <{POST_SNAPBACK}>
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.
Thanks to spoon as well; I appreciate his expertise. I was clearly not considering the big picture, though I still don't believe I really needed to when addressing the incorrect notion that I quoted above, except to say that my overly-general statement was grossly ill-advised and it should certainly call into question my expertise on the subject.
Regarding the relevancy of hacks, is it still relevant to that drives attribute different data to the frames being returned if they have different offsets?
...or does this issue simply disappear?
Context is everything.