Thanks to Thomas Vander Stichele I've found out that when ripping an audio CD you get a different file depending on the CD drive you use because they don't all start reading at the same position and that for most drives this is a constant offset. So if you know what offset your drive has, you can compare rips done with a different drive.
I was under the impression that this offset was always a multiple of the sector size, because audio CDs do not have a reliable way to detect the position. But it seems this offset can in the middle of a sector too.
It looks like they agreed on some standard to compare the drive offsets. You can find a list of drives here and here. Cdparanoia has an option you can use to correct for that offset.
But I started wondering where this error comes from. There is no real reason why all CD drives shouldn't be able to return the same thing. There is very little real info about it out there, and I basically get the impression that someone just decided to use something as base value. It isn't really a problem, since this is about very small time.
To fully understand this, I think it's important to understand the basic layout of an audio CD. A sector (frame) of a CD contains 2352 bytes (588 samples) main data and 96 byte of sub-channel data. You have 75 such sectors per second, giving you a total of 44100 samples per second.
A sector is made up of 98 sub-frames. Each such sub-frame has 24 bytes (6 samples) of main data, 4 bytes of C1 error correction and 4 bytes of C2 error correction, and 1 "byte" of sub-channel data.
The first 2 sub-frames are used to mark the beginning of the sector. It contains a special pattern at the location of the sub-channel data. The first sub-frame contains S0 and the second S1. So you are left with 96 byte of sub-channel data. The highest bit of the sub-channel byte is used for the P sub-channel, bit 6 for the Q sub-channel, and so on until the W sub-channel. So the sub-channel has 96 bits (12 byte) per sector and each bit is in a different sub-frame.
If you go look at the offsets, you'll notice there are a lot of drives that have an offset that's a multiple of 6 samples, but there are also a lot that aren't a multiple of 6.
In the P and Q sub-channels you can see at what place you're reading. The P channel is a "pause" flag. At least 2 seconds before the track starts the P flag is turned on and the second sector of the track it's turned off again. All bits of P sub-channel should be the same for the whole sector, it can only change after an S0/S1.
In the Q channel you can have different information depending on what is in the first byte. The most useful one is "mode 1", which contain things like the track number, index in the track, and time indication for both the current track and the whole disc, and a CRC. Mode 1 should be in at least 9 out of 10 sectors. So you known perfectly at which location you are. There is just 1 small problem, the sub-channels do not have any error correction, but does have a CRC. And there are lots of sectors with the information in it.
So I wondered if the drives just didn't look at S0/S1 and that the sub channel data was shifted too. So I changed cdparanoia to log the sub-channel data and dumped it. I've tried this with a total of 6 drives, and also look at what the drive offset is. This are the drives I've used and the offsets they have:
| Drive | offset |
| SONY DVD RW DRU-700A VY03 | +12 |
| PLEXTOR CD-R PX-W4012A 1.00 | +98 |
| PLEXTOR CD-R PX-R412C 1.06 | +355 |
| TSSTcorp CD/DVDW TS-L532A TI5a1 | +116 |
| HL-DT-ST DVD-ROM GDR-H30N 1.00i | +6 |
| ASUS CD-S520/A 1.7L | +1858 |
Some notes:
- They all start exactly at the sector boundary, sub-channel data is not shifted. So they all perfectly know where a sector starts.
- Except for the ASUS, they all start at the correct sector. The ASUS starts 2 sectors too fast, which is probably why it has that 1858 samples offset, which is more than 3 sectors.
- Both plextors add 588 to the offset when reading the main data + the sub-channel data. So they start reading 1 sector earlier if you request the sub-channel data.
- The PLEXTOR CD-R PX-R412C sometimes also has an offset of +354
I can perfectly understand that it might be off by 1 or more sector, like the ASUS. I could also understand that it might be off by 1 or more sub-frames, but then I wouldn't expect to get proper values for the sub-channel data. Having an offset not be a multiple of the sub-frame makes no sense to me. So I can only come to the conclusion that this are all firmware issues.