Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

[Donuts]

Hi,

I have a Lenovo laptop with Hitachi LG Data Storage DVDRAM GMA-4082N, firmware ED01.

Looking at the AccurateRip database, there are over 400 entries for this drive, all giving an offset of +667. Many other similar Hitachi LG drives have the same offset. I used Exact Audio Copy to test my drive's offset with a CD in the AccurateRip database, giving a result of +667.

However, it seems my drive actually has an offset of (most likely) +655!

Can anyone suggest what I might be doing wrong, or have I come across a bug in EAC and/or AccurateRip?

For testing, I used a "Tomb Raider Collectors' Edition" PlayStation game disc (NTSC U/C, SLUS-00152CE) and ripped all audio tracks using cdparanoia (in Linux), which defaults to an offset of 0. Track 2 WAV files created by EAC using offset 0 and cdparanoia were byte-for-byte identical, i.e. the MD5 checksums matched.

Here's a hex dump of the beginning of the "offset 0" track 2 WAV:

00000000   52 49 46 46  74 1B 11 02  57 41 56 45  66 6D 74 20
00000010   10 00 00 00  01 00 02 00  44 AC 00 00  10 B1 02 00
00000020   04 00 10 00  64 61 74 61  50 1B 11 02  00 00 00 00
00000030   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
 ...
00000A50   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00000A60   00 00 00 00  00 00 00 00  17 00 18 00  1A 00 25 00
00000A70   18 00 2F 00  00 00 20 00  18 00 1A 00  15 00 10 00
00000A80   0D 00 03 00  FE FF 09 00  08 00 0E 00  0C 00 27 00
00000A90   F2 FF 27 00  0D 00 22 00  0C 00 30 00  FF FF 22 00
00000AA0   1D 00 23 00  1D 00 20 00  13 00 16 00  18 00 13 00
 ...

The first non-zero data is at offset 0xA68 in the file. Subtracting 0x2C WAV header length and dividing by 4 gives an offset of 655 samples. (Looking at the other tracks on the disc, the first non-zero sample data is always at offset 0xA68 or later.)

Now, here's the start of the track 2 WAV ripped using EAC offset +667:

00000000   52 49 46 46  74 1B 11 02  57 41 56 45  66 6D 74 20
00000010   10 00 00 00  01 00 02 00  44 AC 00 00  10 B1 02 00
00000020   04 00 10 00  64 61 74 61  50 1B 11 02  0C 00 30 00
00000030   FF FF 22 00  1D 00 23 00  1D 00 20 00  13 00 16 00
 ...

Notice that the first audio sample data in that (0C 00 30 00) is actually the 13th sample in the "offset 0" WAV. The first 12 samples are missing from the offset +667 WAV file.

In other words: if I were to use the EAC/AccurateRip-detected +667 offset, all tracks I rip would be missing the first 12 samples.

-- M

[Spoon]

Re: Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

The EAC drive offset standard is a reference point which other drives and rippers can adhere to, but this value will have offsets on CDs (because there is no standard starting point for all CDs), so with an offset calibrated you might loose some samples, the only way not to loose them is to use an offset of 0 on your drive. Put a different way, even if you had a drive which could overread even a 0 offset might loose samples, you might have to go into where the drive thinks the lead in is.

[Donuts]

Re: Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

Ah, I kind of see what you mean.

So in order to be sure of reading all samples (or at least, as sure as is possible), I'd have to use an offset of 0 (or even a negative offset?) in EAC, plus if my drive allows it check the "Overread into Lead-In and Lead-Out" option?

I tried using the default +667 offset and setting the overread option. EAC didn't seem to automatically detect that there are non-zero samples before the offset, i.e. the WAV file created still has the first 12 samples missing.

Does this "different CDs mastered with different offsets" issue mean that when ripping tracks to WAV files, the start and end points are never guaranteed to be accurate? (That is, there will be samples from the previous track at the start, or from the next track at the end of each track.)

[Spoon]

Re: Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

A certain disc might be produced in its first pressing. The audio starts from sample 1 (unusual as there is normally silence), now the 2nd pressing run might add a -1000 sample offset, so unless you went back a huge amount (way more than drive offsets) you would miss that data.

In reality the data missing is so small and inconsequential.

[Donuts]

Re: Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

Ah, so the "zero position" according to EAC is not an absolute value/position, but just an "average" for various pressed CDs? Or is there actually a canonical start position, but different pressed discs deviate from it one way or the other?

When ripping tracks (in particular tracks which lead directly into the next, with no silence in between), there's no way to know exactly where one track ends and the next begins.

Not that in practice being a few samples out really matters for listening purposes, but in view of that, I'm looking into how to create full-disc images.

In other words, I'd like to find some software which can create an image file of an entire CD, over-reading the lead-in and lead-out, and capturing all audio and subchannel data.

I guess the various programs designed for imaging e.g. copy-protected game CDs could be used for that. But they probably don't have the ripping reliability/secureness of something like Exact Audio Copy.

Ideally, there would be a program which could image the raw data + ECC + subcode info from a CD, then be able to post-process that, checking and correcting any errors.

[Spoon]

Re: Drive offset detected incorrectly by EAC/AccurateRip, +667 vs actual +655???

It was an average at the time. The idea of offset correction is not overly to recover those 600 samples, rather to make each drive give the same results which can be cross-compared.