*always* the last track is "inaccurate"

[Aaron Mackey]

Every single CD, no matter the quality, the last track ripped (burst mode) is marked "inaccurate" (sometimes, rarely, randomly, some other track is *also* marked inaccurate).

Then I click "Re-rip inaccurate", "overwrite", and then all is fine on the second go, always (even if there are a couple tracks to re-rip).

Searching the forum seems to indicate others have reported this, but was attributed to scratched CDs, bad reader, settings, etc. That's not it, this is a consistent issue with whatever happens during a full-CD rip on the last track, vs. a individual-track(s) rip.

No, I don't have "Read into Lead-in or Lead-out" option checked, it is *not* checked.

Given how long this seems to have been reported (back to 2009), it'd seem there'd be a FAQ somewhere?

thanks for any solutions!

[garym]

Re: *always* the last track is "inaccurate"

Sounds like a bad optical drive. I would try a different drive.

[Aaron Mackey]

Re: *always* the last track is "inaccurate"

Sounds like a bad optical drive. I would try a different drive.

Hmm, when I re-rip the last track, it's always fine; why would the optical drive's performance differ when the previous tracks had been ripped or not?

[garym]

Re: *always* the last track is "inaccurate"

Hmm, when I re-rip the last track, it's always fine; why would the optical drive's performance differ when the previous tracks had been ripped or not?

no clue, just trying to think of what might be going wrong, given that this is not a widespread issue. It is worth experimenting. The CD data for last track is in a particular location on disk and maybe your drive struggles with reading from that location.

[awrc]

Re: *always* the last track is "inaccurate"

Not sure how relevant this will be. I'm in the process of backing up my CD collection to M-DISC, and I've been using XLD on my Mac, which has its own built-in Secure Ripper, the option to use CDParanoia (10.2), as well as the option to check AccurateRip, to test the CD before ripping, or test it *and* use AccurateRip, for extra masochism.

All of the rips that I am doing are to single FLAC files with Cue sheets.

When using the built-in ripper, with AccurateRip turned off, it's yet to tell me a disc had a major problem although it frequently (but not always) shows the last track (and only ever the last track) as having a number of Read Sector Retries. If I rip using the built-in ripper, with AccurateRip turned on, that last track is always listed as being NG due to a CRC32 mismatch. If I rip the disc using CDParanoia with AccurateRip turned on, the disc passes all checks with flying colors.

So - XLD built-in ripper, no AccurateRip, disc is considered good although last track has read sector retries, XLD built-in ripper, AccurateRip on, last track always fails with mismatched CRC, CDParanoia with AccurateRip, (so far) always passes.

I realize I'm using a different ripper, but the "last track" thing drew my attention. Although I've not been doing this for long enough to have a decent technical knowledge of how the ripping process works, I'm already becoming somewhat suspicious of the way the two different rippers handle pregap. I believe XLD appends it to the end of the disc data, while CDParanoia...well, to be honest, I've no idea what it does, let's just say I'm suspecting that the pregap append is what's screwing up the checksum on the last track at least.

I initially suspected it was something to do with the drive alignment on the final track, but the fact that CDParanoia gets the right AccurateRip verification (both versions) for the tracks makes me suspect that it's something more esoteric.

Drive, in case this is of any relevance, is an LG Blu-Ray which, since I've been backing up some Blu-Rays too, is flashed to use the appropriate MakeMKV LibreDrive firmware. This shouldn't cause problems - it gets the offset correct, even though the drive shows up as "(null) (null) (revision (null))" in the log files.