THE TRUTH ABOUT OFFSETS
Offsets seem to confuse a lot of people. In this article I'll try to explain
what offsets are and what you can do to correct the offsets. Almost every drive
cannot position its reading head exact at the wanted sector. For data CDs
that isn't much of a problem since every sector has location information so the
drive can easily find the correct sector. Contrary to data CDs, audio CDs
contain no sector location information. In other words it's very difficult too
locate a certain sector on an audio disc. That means that drives will have an
offset when reading audio CDs. For most modern drives this offset is constant so
you can correct it once you know it.
We'll use a Plextor PlexWriter 8/20 (PX-W820T)
CD recorder as example.
This writer has a read offset of -355 samples and a write offset of -30 samples.
A negative offset means that the drive starts reading or writing too early and a
positive offset that it starts too late.
Let's have a closer look at this. Assume a perfect writer with a write offset
of 0 samples.
As you can see and probably expected, the perfect recorder writes all 3
tracks to the CD without any offset or missing samples. However, no writer I
know of has a write offset
of 0 samples which matches the above example. A more realistic situation is the
PlexWriter with -30 samples write offset. If we want to burn
the 3 tracks from the above example to CD we get following situation:
What happened? The burning software commands the writer to start writing at
position 0 (Addressed position) but due to the write offset
the Plextor starts burning the audio data 30 samples too early (Write
position). In other words, the whole CD is shifted 30 samples to the left!
The effect of this is when you play the burnt CD in a CD player you'll miss the
first 30 samples. These samples are written to the CD, but for the CD player in
the pregap which is not played. Because of the shift of the audio data the first
30 samples of Track 2 are added to the end of Track 1. The same for Track 3 and
Track 2. Since the writer started burning to early it will also stop burning 30
samples too early. That means that the CD player will read the 30 last samples
of the CD in the Lead-Out which is silence. The conclusion is thus: no audio
data is lost on write, but the first 30 samples are not playable. For the rest
there's a 30 samples negative shift over the whole CD what means that the track
indices no longer are at the correct positions. It's obviously that a positive write offset
would give similar results but with the data shifted in the opposite direction.
Now you know what the write offset is, it's time to take a
closer look at the read offset. The read offset
is identical to the write offset except that it only occurs
during reading (sounds logical, not?). Below is the extraction of a perfect
drive with 0 samples read offset.
As expected the drive extracts all 3 tracks from the CD perfectly. No missing
samples or shifted data. The extracted tracks are identical to the tracks on the CD.
Of course, a drive with read offset 0 is an utopian dream
thus below you can find a more real life situation of a Plextor PlexWriter with
-355 samples read offset. Before you start e-mailing me that
the Plextor has read offset offset of +355 samples in Exact
Audio Copy you should know that EAC is somewhat inconsistent with the signs of
the offsets. While the write offset in EAC is the real write offset,
the read offset is actually the read offset
correction, thus the opposite of the read offset.
Since EAC 0.9 prebeta 8 the read offset in EAC has the more
correct read samples offset correction value name.
Anyway, back to our situation with a -355 samples read offset.
The negative read offset means
that the Plextor starts reading 355 samples too early.
Thus while the software addresses the Plextor (Addressed position) to
start reading at Absolute position 0, it will
actually start reading 355 prior to that point (Read position). This has as effect that the
extracted Track 1 has 355 samples silence from the 2 seconds pregap (PG) at its beginning. This because the
Plextor starts reading 355 samples in the pregap where no audio data is (though
the Plextor "thinks" it started reading at 0). The last 355
samples of Track 1 are missing. Track 2 has the missing 355 samples of track 1 at its
beginning. Similar for Track 3 which has 355 samples of Track 2 at its beginning
and is missing the last 355 samples because the Plextor stops reading 355
samples too early. Unlike with the write offset, the read offset
introduces irretrievable data loss! The last 355 samples of the CD are lost. on
extraction. For a drive with a positive read offset a similar
In the example of the PlexWriter with write offset -30 we
burnt 3 perfect extracted tracks. But we just saw that there's also an offset
introduced during extraction, thus what would happen if we want to burn the
extracted tracks from the above example to CD. This is the situation that
applies to most of us who want to copy a CD but don't know about the offset
issue. The extracted tracks all have the 355 samples shift and the last track is
355 samples too short. When burning this with write offset
-30 the tracks will be written 30 samples too early.
Because the tracks already have a 355 samples offset this results in a total
offset of 325 samples, the so-called combined read/write offset:
combined read/write offset = read offset - write offset = -325
In English that means that the copy of the CD has a 325 samples offset shift
to the original. On writing no data was lost, but since the last 355 samples
were already missing the copy is not perfect. Due to the offset the track
indices are also positioned wrong and every track starts 325 samples too late.
Thus Track 1 starts with 325 samples of the original CD's pregap (silence) and
misses its last 325 samples. Track 2 has Track 1's 325 missing samples at it's
beginning. Track 3 is missing its last 355 samples due to the read offset
but during play 30 samples of the Lead-Out (silence) are added.
Now before you start to panic you should know that 30, 325 and 355 samples are
very short times. To get an idea about the real length in time of a sample use following
time = samples / 44,100
Thus 355 samples is 0.00805 seconds, or 8.05 milliseconds, 325 samples is
0.00737 seconds or 7.37 milliseconds and 30 samples is
0.00068 seconds or 0.68 milliseconds. The offset is a time shift of the
data and thus it does not affect the audio quality in any way! Since all tracks on a CD end with silence or fade in each other
there's no way you can hear the offset. Therefore the whole offset issue may be
ignored if you don't care about that...
Anyway, for us perfectionists there must be a way to correct this issue. How
would that be done? The answer is very simply: you just have to fool the drive!
In the above example we saw a total offset of -325 samples over the whole CD.
Thus what if we would apply a combined read/write offset
correction of +325 samples?
combined read/write offset correction = - combined read/write offset
= - (-325) = 325
The software tells the drive to start reading at +325 (Addressed position)
but physically it is of course reading at position -30 (-355+325 = Read position).
That means that the Plextor starts reading 30 samples too early. Thus the first
30 samples of the extracted Track 1 will be silence from the pregap. To get the
last 355 samples of Track 1 the drive will read 325 samples into Track 2.
However, that means that still 30 samples are missing at the end of Track 1.
These 30 samples are extracted at the beginning of Track 2. It's obvious that
you will always lose the 30 last samples of the CD. There's no way to avoid that
when using the combined read/write offset!
This introduces a new problem, though. For the last 325 samples of Track 3
(the last 30 are missed anyway),
the Plextor would have to read into the next track, but there is no next track. Thus it
must read into the Lead-Out. The Plextor is able to overread into the Lead-Out
and can retrieve the last 325 samples of Track 3. However, many drives can't
overread into the Lead-Out and will lose the last 355 samples of a CD. Thus a
drive which supports overreading into the Lead-Out will miss only 30 samples
while a drive which cannot overread into the Lead-Out will miss 355 samples (325
samples silence due to the overreading + 30 samples missing due to the offset)! Note that this only happens to the last track!
As we already lost 30 samples on extraction no matter whether we have a drive
capable of overreading, it should be obvious that a 100% perfect copy is no
longer possible. On the other hand, 30 samples is such a short time that you may
ignore it, especially since it's at the end of the CD and almost every CD ends
with silence anyway.
A similar story applies to a positive read offset where the CD-ROM must be able to
overread into the pregap (in EAC the term Lead-In is used, but it actually is the
Even if we ignore the missing samples there is still a 30 samples offset in
the extracted audio tracks. But thanks to the combined read/write
offset correction this is corrected on writing as you can see in the example
Since the write offset is already included in the combined read/write
offset, the CD is written with write offset 0. The data
of the extracted audio tracks is shifted 30 samples to the right and because the
Plextor starts writing 30 samples to early the resulting total offset is 0. In
other words, the offset is corrected. Except for the 30 samples silence in the
Lead-Out at the end, the copy is identical to the original!
When a drive was used which is not able to overread into the Lead-Out a
similar result is achieved with the difference that the last 355 samples are
silent (325 samples silence due to the overreading + 30 samples silence in the
So, is a perfect copy (without missing samples) impossible then? No, but it's
more complicated and Exact Audio Copy is the only software at this moment
capable of making such a perfect copy without missing samples. In the above
example we used the combined read/write offset correction to
correct the offset caused by the read offset and write
offset. Because the real read offset is -355 and we used
-325 to extract the last 30 samples were missing.
Now this can be avoided when we would use the separate read
offset on extraction and write offset on writing. While
this sounds logical (and is), it is very difficult to determine the separate
offsets and many people will not be able to use this method. Anyway, the read
offset and write offset of the Plextor 8/20 are well
known thus we can proceed in an attempt to make a perfect duplicate of a CD
without missing samples.
As you can see on the image below the CD is now extracted with a read
offset correction of +355 samples making the total offset 0.
The software tells the drive to start reading at sample +355 (Addressed position)
but physically it is reading at position 0 (Read position = Absolute position).
To get the last 355 samples of Track1 the Plextor reads 355 samples into Track 2.
As seen with the combined read/write offset this introduces a
problem, though. For the last 355 samples of Track 3, the Plextor would have to read into the next
track which does not exist. Thus it must read into the Lead-Out. The Plextor is able to overread into the Lead-Out and can retrieve the last 355 samples of Track 3. However,
like said earlier many drives cannot overread into the Lead-Out and will lose the last 355 samples of a CD. Thus a perfect
copy is impossible with a drive which cannot overread into the Lead-Out.
Remember that this only happens to the last track! And once again, this is such a short time that you will not hear it.
Since 99% of all CDs end with silence no music signal will be lost!
When writing these extracted tracks to CD we have to use the -30 samples write offset
of the PlexWriter. We'll burn the tracks extracted with a drive supporting
overreading into the Lead-Out. In the case of a drive which does not overread
into the Lead-Out you just have to keep in mind that the last 355 samples of
Track 3 are silence.
Normally the writer would start writing 30 samples too early but the +30
samples write offset correction compensates that resulting in
a total offset of 0. The offset is corrected! Thus the software tells the writer
to start recording at sample +30 (Addressed position)
but physically it is writing at position 0 (Write position = Absolute position).
To write the last 30 samples of Track 1 the drive overwrites into Track 2. A new
problem raises however. To write the last 30 samples of the last track the drive
would have to overwrite into the next track which does not exist. Thus the drive
must be able to overwrite into the Lead-Out. If that is the case you can see
that the copied CD is a 100% copy of the original with absolutely no missing
Sadly enough, only few burners can overwrite into the Lead-Out and the
Plextor PlexWriter 8/20 isn't one of them. That means 30 samples will be missing at the end of
of the last track. Thus a perfect copy is impossible with this setup...
Special thanks to Erik Deppe, Andre Wiethoff
and Mark Powell for the additional information.