There, I edited the typo, now it is correct.
I did a perfunctory compare on a few of the other "last track different checksums" discs. As per EAC WAV compare, the discrepancy errors are all at the very end of the track.
Therefore, since all the drives continue to match accurate rip on popular discs, it seems from the various other posts here and at HA, that this is a known problem.
Unless Spoons has some other suggestions or requests, from my point of view, this is resolved as a known problem.
If I detect any consistent errors NOT at the very end of the track (as has been discussed here and elsewhere) I'll post them.
Thanks to everyone who contributed to my understanding of how this stuff works.
If spoon could write a concise summary of the cause of the problematic checksums related to the end of tracks on these special discs, that would be great.
2 drives which cannot overread (with different offsets), even if the option is on or off, will always produce different CRCs on the last track.
Addendum: in all cases with pristine and non-defective discs, the AccurateRip will continue to match, because the last 5 frames of the last track are never included in AccurateRip calculation.
This discarding of the last 5 frames is done specifically to work around issues such as those above that can never be resolved via software.
A maybe related problem, the Sony mediachanger, identifies as Matshita DVD-RAM SW-9584 B104, offset +102 -- dBpoweramp says it can read into lead out, but:
I ripped all with lead in/out checked, and without. Removing those without AR entry or with all tracks inaccurate (different pressings), I were down to 115 discs.
-> Burst rip, lead i/o UNchecked: 97 discs clean, 18 discs with inaccuracies, of which 6 only in the last track.
-> Ultra-secure, lead i/o ON: These 6 inaccurate last tracks have now increased to 50. That is about half of the discs.
-> Tried these 50 discs with EAC, testing only the last track with lead i/o ON: The vast majority (say, 45 of those 50) were still inaccurate. Only a few were tested with lead i/o UNchecked, all of them accurate. Did not try EAC on the remaining fifty-something to see whether EAC produces inaccurates that dBp does not.
So it seems that on this particular drive, checking lead i/o will produce Inaccurate last track in about half the discs -- regardless of application.
Oh, and there are some noteable discrepancies in the AR numbers. A couple of discs have quite a lot higher Inaccurate confidence on the last track than Accurate on the rest -- I suspect coming from re-rips with different software, setting, or CD-drive -- but also a few discs with lower number on the last track. What is, plausibly, the explanation? Among the latter are
Audioslave - s/t - 13 tracks Accurate (131 to 134), 14th track Inaccurate (38).
Tori Amos - Scarlet's Walk - 17 tracks Accurate (62 to 65), 18th track Inaccurate (15).
I'm having this "missing samples" problem, tested with R13 and R13.1 - both reference versions, I think - I paid anyway ;-)
[edit:Solved my problem now; needed to click the Options button in dbPA CD Ripper (not the little arrow next to it!), choose Read in to Lead In or Lead Out option AND change the "Communication" option from Windows Internal [For Limited Accounts] to any of the other options except SCSI Pass Through Read(D8), which didn't work on my machine.
The screen grab below shows the issue. The windows on the left show a close up of two .wavs extracted using Exact Audio Copy from CD on two different computers. On the right is the same track extracted using dbPowerAmp R13. Top right is extracted from a Daemon virtual drive with an image from EAC mounted (looks fine, identical to EAC extracted data), and the bottom right is extracted using dbPowerAmp from the CD disk itself. Looks like 102 missing samples padded with zeros, even though EAC managed to read in to the lead out to get the actual data.
CD ROM Technical Details:
CD Drive: DVDRRW GSA-H30L
Maximum Speed: 7056 KB/sec (x40)
Current Speed: 7056 KB/sec (x40)
Spin-down After: 32 seconds
Buffer Size: 2 MB
Accurate Stream: Yes
C2 Error Pointers: No
Reads ISRC: Yes
Reads UPC: Yes
OS is Vista Ulitmate x64 (64 bit)
Last edited by sjmac; 08-17-2008 at 05:08 PM. Reason: extra clues obtained
Is the checkbox "Read into Lead-in or Lead-out" checked for that particular drive in the dbpoweramp CD Ripper: Options dialog?
I had looked for that kind of option, but I'd been clicking the arrow next to the options button, not the actual button, so couldn't see most of the useful options.
HOWEVER - setting it made the problem "worse" - I got even more missing samples. Then I tried changing the Communication setting, and choosing "SCSI pass through" instead of "Windows Internal" has fixed my problem (tested in R13.1 beta).
Good to hear. SCSI Pass Through allows for the largest drive capability support and should be used whenever it is avaialble.
Noted, and thanks for your help :-)
If spoon/developers are reading, I suppose it's worth pointing out that EAC was working OK with the "Native Win32 Interface" option, which I guess is the same as dbPowerAmps "Windows Internal".