Last night I went to undertake some testing in EAC.

My goal was to detirmine whether burning with the internal EAC routine and CDRDAO were identical, and to check the results with the original CD.

All ripping and burning was done using my new Plextor PX-W5224A. I have set the read offset in EAC to +30 samples, and the write offset to -30 samples.

I burned two discs, one using EAC internal and one using CDRDAO. I burned from my Monkey's Audio archive - a single image file with cuesheet.

I then used EAC again to rip all three CDs (EAC burned, CDRDAO burned, and original) to WAVE images.

The WAVEs from the two burned discs were identical - but they were different to the WAVE from the original.

I don't have a copy of the report from EAC's "Compare WAVE files", but here's foobar's bitcompare output:

INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\original.wav" (0)
INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\eac.wav" (0)
INFO (foo_bitcompare) : length: 2531.453
INFO (foo_bitcompare) : first different sample found
INFO (foo_bitcompare) : differences found: 20 sample(s), starting at 2531.453 second(s), peak: 3.051758e-005 at 2531.453 second(s), 1ch
INFO (foo_bitcompare) : Finished successfully.

EAC reported something similar - basically an issue right at the end of the file (note the position of the problem in relation to the duration of the file).

I wondered whether this could be a problem with my archive so I reburned from the new WAVE image. I got the same result.

This morning I used Plextools to rip from the original to a WAVE image. This file was exactly the same as the rip from the original in EAC.

INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\original.wav" (0)
INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\plextools.wav" (0)
INFO (foo_bitcompare) : length: 2531.453
INFO (foo_bitcompare) : No differences in decoded data found.
INFO (foo_bitcompare) : Finished successfully.

I'm kinda thinking this proves that the rip is OK - and that it is the burning that is the problem. See below.

I then burned the plextools rip to CD, and ripped it again using Plextools.

INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\plex-copy.wav" (0)
INFO (foo_bitcompare) : location: "file://E:\Testing\Libertines\plextools.wav" (0)
INFO (foo_bitcompare) : length: 2531.467
INFO (foo_bitcompare) : No differences in decoded data found.
ERROR (foo_bitcompare) : Files have different length.

Note the difference in file length with all others (2531.453 > 2531.467).

I just really don't understand what this all means!

1. How is Plextools causing a problem? I'm new to Plextools but I don't see how it can be set up wrong, as there's little to setup
2. Why 20 samples? The offsets are +/- 30 samples in EAC
3. How the Hell is the Plextools copy rip ("plex-copy.wav", original CD > Plextools > WAVE > Plextools > CD > Plextools > WAVE) bit-identical to he Plextools rip ("plextools.wav", original CD > Plextools > WAVE), but different in length!?

I don't understand why I'm not getting bit-identical results here.

Can anyone shed any light, please?

Tonight I burned original.wav (the image file ripped from the original CD) using my LiteOn DVD RW, which is set up with the correct -6 samples offset.

Again, I ripped the CD using EAC - and this one was bit-identical to the original.

So, it seems I do have a problem with the write setting of my PX-W5224A.

Are there any other PX-W5224A owners who can provide any sort of information here?

Plextools reports the read and write offset to be -120 bytes, so I don't see why I should be changing my write offset in EAC (from +30). I have seen various posts stating -30 and +30 as the read and write offsets to use.

Argh!!!! It's so frustrating!

30 samples = 120 bytes

EAC uses sample values, PlexTools byte values. Therefore, both programs have the correct offset (since you said that read offset correction is +30 in EAC and the write offset is -30).

Edit: Oops, with "sectors" I meant "samples". Thanks precisionist!

If the read offset correction is positive, the drive needs to overread into lead out and overwrite into lead out.

EAC can't overwrite with Plextor drives. If the Plextools burn + rip is longer, it means that Plextools generates an additional audio sector in order to write the extra data that EAC leaves out.
It also explains the difference. The extra data must have been read with overreading into lead-out, or with a drive with a read offset correction smaller than +30. So the 30 last samples, left out by EAC and CDRDAO while burning, were not silent.

Thank you so much for the response(s). This is driving me nuts.

I believe the PX-W5224A does overread into lead out and overwrite into lead out. Not sure though.

The test CD is only 42:11 long and has no TRACK 1 INDEX 0 track. With that in mind I wouldn't have thought the lead in and lead out would be an issue. You may have guessed I don't really understand about lead in/out - except that I couldn't previously rip CDs with a TRACK 1 INDEX 0 track with my previous drive so I bought a Plextor so I could. I guess I better read up on lead in/out now...

I understand what you say about Plextools writing an extra sector. I suppose this proves it must be overwriting into lead out, and consequently EAC is failing because it can't.

I guess it looks like I'm:

• Ripping with my Plextor and buring with my LiteOn in EAC
• Ripping with my Plextor in EAC, and burning with my Plextor in Plextools
• Ripping and burning with my Plextor in Plextools

I'm a little dissappointed.

Everyone raves about the Premium - but that has the same offsets! Surely these offsets aren't so cool when using EAC?

I do intend to read up on this, but even looking at it with a fresh eye I think I have a better understanding now. I don't really understand what the TRACK 1 INDEX 0 reading has to do with lead in - but I now assume that, irrespective of the length of the CD (), the lead in is simply the area immediately previous to the audio data, and the lead out is the area immediately following the audio data. So, with a positive read offset of 30 samples this means the drive continues to read 30 samples into the lead out believing itself to still be reading audio data.

So really the best option for EAC is either a drive with no offset, or two complimentary drives (with a read/write lead in/out combo that escapes me now). I suppose I should feel lucky that I appear to have that with my Plextor reading and LiteOn writing...

I'm still disappointed that my Plextor can't do it on its own.

Any other pointers, either to a solution or information regarding this area, would be much appreciated.

No, at no time in these examples any overwiting was performed. Overwriting is a hack seldom encoutered. EAC used to do it with some TEAC drives.

EAC cuts the end of your audio because it performs offset correction. Plextools extends the last track so as not to cut data during offset correction.

If only manufacturers would create a drive with an offset of 0 for reading and 0 for writing...

Where do offsets come from? Hardware or firmware?

There are no specs. Any manufacturer must decide its own offset within a given range.

Sorry, I guess I mean't "I suppose this proves it must want to overwrite into lead out".

I think I'm so confused about this as [a] I thought owning a Plextor was the be all and all of these issues [b] with my previous set up, which I consider(ed) inferior, I could attain bit-identical copies. I guess this was more lucky than I realised.

NB: I assume I was successful writing with the LiteOn as it has an offset of -6. Given there were 30 samples, and 20 were previously reported missing, I assume the LiteOn was successful as its offset was less than or equal to 10...

Samples you mean. EAC uses samples to display offsets. 1 (CD-)sector= 1 (CD-)frame = 1/75 second = 588 samples


As far as I know, no firmware influence has ever been reported. It's a hardware issue. That's why you can't improve overreading/overwriting/offset features with firmware updates.

I don't really understand the problems discribed in this thread and Pio's answers...
Have you given an explanation for the strange difference ? An additional sector would be much larger (588 samples),as I said above...

edit:
@synthetic soul:
Have you read the offset explanations in the coaster tutorial ? The pictures given there are almost self-explanatory and the best offset description I've ever seen.

Yes, briefly. I basically get the concept of offsets... at a simple level. Perhaps I should read the article again. I think I have a better undersanding of lead in/out now... although again there is vast room for improvement.

Edit: I've just skimmed the article and must admit I found it quite amusing that after everything gone through the summary is so:


Talk about dangling a carrot in my face and then whipping it away.


I am basically still confused as to what is happening! Pio2001's first answer is helping me toward an epiphany, but I think I have a way to go.

The basic problem I have is that, using EAC, I can't achieve bit-identical copies using my PX-W5224A with the offsets set up correctly. I appear to be under the misunderstanding that a Plextor drive is the answer to all my prayers...

I am most confused that my drive has the same offsets as the Premium, and I know that is highly regarded.

Edit: grammar

This does tie up with the results from Plextools, and Pio2001's response.

If 1 sector == 1 frame then that is 0.0133` seconds - which is the difference between the original rip (2531.453 seconds ) and the Plextools rip (2531.467 seconds ) - proving Pio2001's statement that Plextools has added one extra sector to allow for for the 30 extra samples.

So I do understand that Plextools has added an extra sector to be able to write the extra data, thanks to Pio2001, and that has helped make some sense of the situation.

I now also understand that those 30 missing samples are infinitesimal (30/44100 seconds).

I guess the hard truth is, due to the positive read offset of the drive I can never get a bit identical copy in EAC (as it cannot overwrite into lead out) - unless the last 30 samples of the audio are silence. Correct?

I am also wondering whether this has all come about because this CD is quite unique in the fact that the last 30 samples are not silence. Correct?

I need to test some others at some point (I'm running low on blank discs now!).

But do they define the offset by aligning some internal parts of the drive or is it just programmed in the firmware?

But are you sure? It may just be that nobody cares to fix the firmware in that aspect.

Yes. More precise: You need to have a lucky combination of overwriting capability and write offset. (The same for overreading and read offset.)

Many CDs from before 1990 have noise (non-null samples) until the very end.

If you really want to know: No, I'm not sure.
Remember that audio players also have offsets but no firmware (?). My audio player's offset isn't constant...
edit: If I recall correctly: I think Spoon mentioned an offset changed by firmware somewhen, you may want to PM him...

Every CD-player, even most old & simple one must have some kind of internal software.

EAC has enabled overwriting into the lead-out for : Teac 56-600, 56-400 and 58. Also keep in mind, that even if you have a drive that can overread/write propperly in EAC, you will only get bit-identical copies, if the cds themselves are offsetted according to Andre´s refference... And since cds are made with varying offsets, then it would require varying offset correction values, to archieve bit-identical results... And that is why i dont use offset correction. It´s not because i dont care about perfection, its just because perfection can not be archieved with just one fixed offset correction value. But offcourse, offset correction is very useful for avoiding generation loss, or for comparing rips done with different drives. -Martin.

I don't know. Maybe Spath knows it, but he doesn't like taking part in discussions. Or maybe if he works as a drive manufacturer, he can't publicly tell the internal details of the products of his society.

I doubt that.
For me, software is defined by something which can be changed - it is saved on a HDD-like data carrier or on a chip (like USB-cards or CMOS) or is saved only temporarily like RAM (needs a voltage source in order to be saved further).
Audio players surely don't have a HDD and I also think they don't have a CMOS- or firmware-chip which can be updated. I've never heard of an audio player being able of updates like CMOS or many satellite receivers. Once you cut the power supply, everything saved is lost like a RAM. It's like the good old early computers in the 80s - do whatever you like, if it doesn't work anymore, turn it off and after that on and everything's fine again.
So the "software" of an audio player totally comes from an unchangeable chip like the old computers or the BIOS.

What do you mean here ? Of course, offset correction doesn't neccessarily catch everything on the CD - it only ensures copying everything like it should be on the CD or should nominally (according to EAC/Andre Wiethoff/Plextor reference) be there (like it's documented in the TOC). You must manually check, if there are non-null samples before the pregap of the first track in the pregap of the audio session or after the last track in the lead-out, if you want to copy everything.

Software is just a program that runs on a computer. So even though you can't change is does not mean it is not software.
Like you can have WORM (Write once read many) or ROM (Read only memory). There can't be software on those. Why can't there be such a thing?

The question isn't what software precisely is, it's "Is one able to change a drive's offset by firmware update ?"

Ugh, software is software (a program), it doesn't matter if it's on rewritable carrier or fixed one - it's still a program, and that's what I claimed - every CD-player has a program which lets it perform its functions.

No, my question was if offset comes from hardware (calibration of internal parts of the drive) or firmware (software/program written in flashable or non-flashable ROM which tells the hardware when and what to do). It's obvious that on CD-players with non-flashable firmwares you can't change anything (unless you exchange the chip), but we're talking about flashable computer drives.

What i´m reffering to, is the fact that cds are made with varying offsets, and therefore one can not get bit-identical results by just using Andre´s reference. And i´m not talking about hidden tracks in the pregap of track 1, but normal cds...
This qoute from pio2001 sums it up perfectly :
"So why do we blind ourselves thinking there should be only one valid offset, while the evidence that 80 % or the official CDs use a different offset is before our eyes ??
We should adapt the read offset differently for each CD we read, since it has been burned with a different offset !!"
Taken from the faq --> Arguments against offset correction :
http://www.digital-inn.de/showthread.php?threadid=4193

-Martin.

> is the fact that cds are made with varying offsets, and therefore one
> can not get bit-identical results by just using Andre´s reference

True, but accuraterip can - it takes into account various offsets for cds, so it is not a total waste having the correct offset set up, once set up you can get byte accurate recordings with a greater confidence than C2 or secure ripping.

I desagree... AccurateRip also just uses one fixed offset correction value for all cds, and therefore the situation is the same(about the use of one fixed offset correction value to archieve bit-identical results) AccurateRip is very good for giving you an indication of a secure rip, but it only tells you that the range you just extracted from a certain cd is secure, and not that the rip is bit-identical to the source... A system like AccurateRip offcourse needs a commen reference for the offset correction, otherwise it wouldn´t be possible to compare rip´s done with different drive´s, but i´m just saying, that even though there are different pressings available in the system, it still dosen´t give an indication of a result that´s bit-identical to the source. Remember that all the different pressings in the system, still is ripped with the same fixed offset correction value... -Martin.

@spoon:
I remember you mentioning a drive offset changed by firmware somewhere, is this correct ? If yes, the drive's offset is obviously determined by software and not by internal calibration.

@Martin: I recommend you to manually check every CD if it's a later pressing than the original one. These later releases often have offset shifts. Then manually adjust offset correction in EAC to catch non-null samples from the lead-out or lead-in. Accuraterip is impractical for this, unless for every offset shift there's already an example in the database.
In many cases, different pressings cause no relevant difference in the extracted audio, because the lost or won parts consist only of null samples.

>I remember you mentioning a drive offset changed by firmware somewhere

I was never 100% on that, someone once emailed that Drive XYZ changed the offset after a firmware update, it might have been a TEAC drive, don't really remember. I think the drive in question changed its reported drive name so it wasn't a problem for the database as it picked it up as a new drive.

Martin: Say for example there was a mix cd, this cd had end to end samples without silence (unlikely), also lets say a later rerun pressing moves the cd offset by 5 sectors - that audio data is gone (it isn't present in lead in or out), no drive offset jiggery will recover data that is no there.

If the second pressing is offsetted 5 sectors, then that cd will begin 5 sectors before/after the first pressing, and end 5 sectors earlier/later than the first pressing. Why would there be missing 5 sectors of music data ? Just like a burners write offset(not correction), the burnt data will be shifted, but all data is written... I´m just saying, that since the cd manufacturers dosent master their cds according to Andre´s reference, but use varying offsets, then just using Andre´s reference will not give you bit-identical copies, since that would require adapting the offset correction differently for every new cd. This is a quote from Andre, from the post i linked to earlier : "Of course to be able to exactly replict a CD you need variing offsets on reading, but then you need of course also variing offsets on writing. This will complicate everything even more."

You seem to think that the original pressing always will match Andre´s reference... But Andre´s reference is not an official reference for the cd manufacturers, it´s just a reference that fits some of the cds, and thats the problem i´m reffering to...
Yes, checking the rips/copies with an accurate wav editor, is the way to go for perfection, since just using the offset correction is no garanty for getting 1:1 results... -Martin.

>second pressing is offsetted 5 sector....Why would there be missing
>5 sectors of music data

Something we quickly found in AccurateRip was offsetted CDs had identical TOCs, so if the offset was lagging 5 sectors you would have 5 sectors of silence and the last 5 sectors of real audio data will be not present on that cd. Only if the CD was longer would those last 5 sectors be there.

No, I don't think that. I know, I know.

Years ago, Andre detected the first offset in the world that has ever been detected. He said that he got five matching results, that means 5 different CDs that had non-null samples until a special position at the end of the CDs, where the audio/noise suddenly drops to silence. He read them all with the same drive and defined the 5 CDs as being written with a write offset 0. Then he caunted the null samples that his drive additionally extracted at the end or the non-null samples that it missed (I don't know which of the two...). That was the world's first offset. Everything other is based on that.
Note that Pio did the same, and the reference detected by him was several samples away from Andre's (3 matching results). I also tried, but it seems that it's too hard for me too find appropriate CDs. So Pio's different result proves your opinion.

Anyway, the issue discribed is only a problem if the CD that's going to be ripped has non-null samples at the end or beginning (Sorry for repeating myself...). Otherwise you wouldn't even know and would not be able to detect if it's written according to Andre's reference or according to whatever and you could not manually set an appropriate offset correction. So to receive a 1:1copy like defined by you, test beginnings and ends.

It's anal enough that we care about it. Even I often forget about this on CD extraction.

Offsets are due to hardware, more precisely to the architecture of the encoder chipset.
And since the red book does not impose any value (and does not even clearly define
what offset 0 is), it's a matter of interpretation by manufacturers. It would be possible
to have some control on offset by software, but I have never seen a drive which allows
that.

More details can be found in this thread : http://club.cdfreaks.com/showthread.php?t=111913

Guys the point is this: Andre's offset correction values are good for 1 thing and 1 thing only, and that is for comparing CRCs between drives. There is no "correct" offset, just the arbitrarily decided-upon value of "0" we use in EAC. CDs aren't mastered to perfectly line up with a "0" offset drive or anything, so your rips aren't going to be more "perfect" with a corrected offset. If you don't care about using accuraterip results, or comparing multiple drives, then don't worry about correcting your offsets!

really, the term "offset correction" is a misnomer because you aren't "correcting" it, just standardizing it. There IS no correct offset.

Thank you for the link, Spath.
In that thread, Reddish explains that on a CD, the subcode channel carrying the track number and the audio data are interleaved realtively to each other.
When you read the track number, that is recorded along the audio, the audio data that comes with it comes from different places in the original track. Which one is the one that must be associated with the track number ? The specifications don't tell it.
From the other point of view, if you read the audio, and look at the track number, it is also interlaced. It means that the audio track is not flagged as being track
2-2-2-2-2-2-2-2-2-2-2-3-3-3-3-3-3-3-3-3-3-3-3,
if we take the example of the transition between track 2 and track 3, but rather as
2-2-2-3-2-2-2-3-2-2-3-2-3-2-3-3-2-3-3-2-3-3-3
So where exactly does track 3 begin ? The specs don't tell it.