kudabird, your MD5 hashs tell us nothing, if you don't also tell us the exact FLAC settings you used. Only then will others be able to compare MD5 with yours.
Is there any ripping means that overcomes the variation of offset and drive capability that will result in bit identical WAV?
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.
Quote from: kudabird on 06 December, 2012, 10:41:25 PMIs there any ripping means that overcomes the variation of offset and drive capability that will result in bit identical WAV?Yes, it is referred to as the ability to overread into the lead-out.Quote from: kudabird on 06 December, 2012, 10:41:25 PMIt 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.I don't see why this would seem to you since it is a false notion. That you assume there is some theoretical basis for it is a bit perplexing.
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.
Beyond that you're further exposed to settings, drive capability and the like which will be numerous.
And I have tested by reading into the lead-out but then you start getting AR failure for want of a better description with the last track.
Presumably no one (or at least very few) read into the lead-out during ripping or drives/ripping tools are not setup/capable which has ultimately influenced the AR database confidence values.
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.
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
I find your comment ‘"Regardless, have fun with your experiments"’ to be quite out of order.
or you may well have be speculating about EAC but it is news to me and I expect others as well.
How would they know if they have their configuration setup correctly including for AR submission?
The topic is DAE and the terms sector and LBA are commonplace in that context and you would know that.
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.
So can you find other people commonly considered authorities on the subject using LBA besides spoon?
Sector, yes; LBA? No; not at all.
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.