Last Track Inaccurate

[pjc2]

Re: Last Track Inaccurate

AccurateRip CRC is designed to be last/first track consistent across drives.
...
If you enable log writing it will be written to the log.

Thanks!

So why are the first and last track different than the interior tracks? If the drive offset is known, and the interior tracks' boundaries are being found precisely (and thus all their CRCs match without any AR magic), why aren't the first and last tracks' boundaries being found precisely?

If the problem is that some of the samples in those tracks extend into the lead-in or lead-out, why doesn't reading into lead-in and lead-out (when supported) solve this?

[Spoon]

Re: Last Track Inaccurate

Say your drive had an offset of +104, now to get the very last data your drive has to be able to overread, and there are so few drives which can overread, some drives pretend to overread and return 0000's always, so it is a mess (for those drives which cannot overread or return 0000's each disc would have a different CRC for the last track on different drives), that is why we remove a small amount of data from the check.

[pjc2]

Re: Last Track Inaccurate

Say your drive had an offset of +104, now to get the very last data your drive has to be able to overread, and there are so few drives which can overread, some drives pretend to overread and return 0000's always, so it is a mess (for those drives which cannot overread or return 0000's each disc would have a different CRC for the last track on different drives), that is why we remove a small amount of data from the check.

Aha! That was the piece I didn't understand. So, if the offset is +104, then you'd need to tell the drive to overread 104 samples past the end (in the lead-out) in order to get the actual last 104 samples of the last track. Similarly, if the offset were -50, you'd have to tell it to overread 50 samples at the beginning (in the lead-in) to get the first 50 samples of the first track. None of this would be necessary if the drive seeking was sample-accurate (offset 0).

So is there any list of which drives truly support lead-in/lead-out? I think I read that the PX-230A doesn't, and the PX-708A does. What about the DW-224SL-R?

[Spoon]

Re: Last Track Inaccurate

The old skool plextors do (px-708, px-716, etc).

[pjc2]

Re: Last Track Inaccurate

Aha! That was the piece I didn't understand. So, if the offset is +104, then you'd need to tell the drive to overread 104 samples past the end (in the lead-out) in order to get the actual last 104 samples of the last track. ... None of this would be necessary if the drive seeking was sample-accurate (offset 0).

This explains why the CRCs would be different between drives with different offsets (assuming they don't read into the lead-out):

No matter how many samples the drive can read at the end of the CD, dbPoweramp always writes the total number of samples that the track is supposed to contain -- it just writes the unreadable samples as zero. For CDs with a lot of pure-zero silence at the end, the CRC of the last track will be identical across drives (since the unreadable samples were actually zero to begin with). But when there's non-zero data near the end of the CD (where "near" is less than the drive's offset), you'll start to see discrepancies in the (non-AR) CRC.

AR accounts for this by entirely ignoring the last N frames in its CRC. Because N is chosen to be larger than any drive's offset, and because dbPoweramp always writes the total number of samples the track is supposed to contain, the AR CRC isn't affected by drives' offsets and lead-out capability.

However, this didn't explain why I was getting different CRCs on a drive that doesn't support read-into-lead-out depending on whether or not the "Read into lead-out" setting was checked.

So I did a little investigation, and I think I found a (small) bug in R13.3:

If a drive doesn't support lead-out, but lead-out is selected, the last 588 samples (that it can read) are incorrectly zeroed out. For example, in a rip of 7636944 samples, on 2 drives that do not support lead-out:

• TEAC DW-224SL-R (offset 102 samples): samples are all zero starting at 7636842 (last 102 samples) with lead-out turned off, but 7636254 with lead-out turned on
• Plextor PX-230a (offset 738 samples): samples are all zero starting at 7636206 (last 738 samples) with lead-out turned off, but 7635618 with lead-out turned on

In contrast, on a PX-708a (offset 30 samples, does support lead-out): samples are all zero starting at 7636914 (last 30 samples) with lead-out turned off, and 7636932 (last 12 samples) with lead-out turned on, as expected.

[Spoon]

Re: Last Track Inaccurate

Ok thanks.

[pjc2]

Re: Last Track Inaccurate

...there are so few drives which can overread, ...that is why we remove a small amount of data from the check.

Is there any way to tell whether discs are likely to have data truncated due to drive offset (either positive or negative)? (I realize you can't tell conclusively whether data is being truncated unless you can overread, and very few drives can do that.)

For example, can the CD Ripper check the first/last N samples of the first/last track to see if they're zero? The idea is that if they aren't zero, there's likely to be leading/trailing data that requires reading into the lead-in/out. And if they are zero, there's probably not leading/trailing audio.

I have a disc with data up until the last 12 samples, so AR would let me silently truncate that data on nearly every drive. Even a PX-708A (+30 offset) has to read into the lead-out to catch all the data...

[Spoon]

Re: Last Track Inaccurate

In an audio editor look for samples that are not silence right to the end

[pjc2]

Re: Last Track Inaccurate

As for the last track usually having a lower AccurateRip score than the others, I agree that this seems to be a trend.

To resurrect the thread and return it to its roots:

Out of 171 CDs, I have 4 whose last track (and only the last track) doesn't match the AR database. Stranger still, this isn't drive-specific. I've tried it on a Pioneer DVR-116 (DupliQ), Plextor PX-708A, PX-230A, and Teac DW-224SL-R.

All four drives agree, and none of them report C2 errors on that track. (C2 has been tested and verified to work on damaged discs.) The PX-708A can also overread, but that doesn't affect these particular discs either way. In none of the 171 CDs did I find a similar problem for anything other than a last track. (I'm ignoring conf:1 discs, since mismatching those wouldn't be surprising.)

It really looks like these discs have a variant last track. What else could cause this? (These discs didn't get recognized as an alternate pressing in the R14 alpha.)

Details:
All tracks except the last are conf:4; the last is conf:3 and inaccurate:
011-00114e23-009a6038-930b110b-11, AccurateRip CRC: 3457FB3D

All tracks except the last are conf:3; the last is conf:2 and inaccurate:
031-003cd175-051fc2d0-c80d851f-31, AccurateRip CRC: 9D91C387

All tracks (including the last) are conf:2:
013-001ba8b0-01184fed-a20dd60d-13, AccurateRip CRC: 6A755EAA

Most tracks (including the last) are conf:2; a few are conf:0:
021-0039c548-036dd7ce-0a112c15-21, AccurateRip CRC: F03CF6E7

[Spoon]

Re: Last Track Inaccurate

It is difficult to say, with conf 3 it suggests that it could not be from a single source, if the AR CRC is constant across different drives, then your rip is correct (that is not to say the other rip was not correct also).

[pjc2]

Re: Last Track Inaccurate

It is difficult to say, with conf 3 it suggests that it could not be from a single source, if the AR CRC is constant across different drives, then your rip is correct (that is not to say the other rip was not correct also).

That's what I thought, but I wasn't sure if I was missing something. It looks like we're both correct and that we simply have different CRCs for the last track.

What would AR do in this case? Let's say conf:4 for all the other tracks, conf:3 for the last track. What if the 4th submission for the last track was the same CRC I'm getting? After I submit my results, would it be conf:5 for all the other tracks, conf:3 for the last track, and dropping our two agreeing CRCs? Or would it split the submissions into two "pressings," so that the one pressing would be conf:3 across all tracks, and another would be conf:2 (even though all but the last track could be considered conf:5)? Or something else?

[Spoon]

Re: Last Track Inaccurate

If your result is verified by someone else then the last track would store both results.