EAC almost killed my drive

vbimport

#1

Okay, under Drive properties for my Liteon 40125S, I decided to create an EAC Test Offset CD. I click Write CD, then clicked the following prompt and it began writing the CD (with buffer under run support). Anyways it got to 100% and wouldn't stop. So the orange light on my drive keeps flashing and i waited 3 minutes. Then I clicked cancel on the EAC write CD dialog, but the darn thing didn't cancel. Then I shut down EAC by using clt-alt-esc in WinXP and closed the program. The light was still flashing. I then decided to reboot the system. Luckily the drive seems operational, but I'm not sure if it is 'damaged.'

I'm gonna do some tests but what do u guys think? anyone been through something similar. IMO EAC should stick to reading CDs and not write CDs, or at least properly test their write CD code.


#2

I know that EAC 0.9 beta 3 has problems writing. But did you try beta 2? Beta 2 doesn’t have the writing bug.

(Note: EAC is still a prerelease (v0.9) and it is beta… I think we should be happy that such an excellent piece of software like EAC exists and even better: it is freeware!)

If I can find the time this weekend I will give this off-set cd a try myself. (I have a ltr-40125s myself.) (BTW did you know that according to the Redbook specifications drives are allowed to have an off-set of + or - 1 second, that is 75 sectors of 98 frames, there is no drive outthere that is that bad and second thing: not even the author of EAC uses off-sets while writing!)


#3

I don’t use offset correction on writing, too.
Because my PlexWriter has the offset value of -30, it starts too early on writing, so at the end it must overwrite into the lead-out. Not really, of course but it “thinks” so. But this isn’t supported by this drive :-[. If the CD ends with silence (0.0006802721… s) it doesn’t matter. Almost any CD ends like this! But true is that the last 30 Samples will always be zero if I correct the offset on writing.

So I don’t do that! I use a combined offset on reading the copy again (if that is necessary), and get a PERFECT duplicate.


#4

I have the same problem with my 32123S. EAC will just continue burning… And I waited five minutes…

Let’s hope beta 4 comes out soon… :slight_smile:


#5

thanks for the replies, I don’t really understand offsets yet, but my goal is to extract the same wave that I burned. So a little tinkering almost killed the cat, you can say. :slight_smile:

Airhead, what did you do with your Liteon after you couldn’t get EAC to stop? I mean the lights were blinking forever. Was the drive ‘damaged’ or ‘not 100%’ afterwards??


#6

I have the litey 32x burner and have had the same problem. It wouldn’t shut off at the end of the burn. I had to reboot the machine to get it to stop. Didn’t seem to hurt anything.


#7

@swift
a great site: http://www.ping.be/satcp/eacoffsets00.htm
There you can learn ALL about offsets and EAC.


#8

I do not think that this damages your drive. I once had great trouble with my IDE drivers, and this caused Nero to freeze while burning, leaving the drive dead and locked, the burn light on the front on, tray would not open.

This happened a lot of times, but the drive always worked fine after a reboot. It is now retired, not because it broke down, but because it was a 2X burner. :slight_smile:

If I should do a little guessing, I would think that this is the drive`s response if it gets some messed up data through the IDE cable. :confused:


#9

@little-endian
Thanks for the satcp site, I’ve been there and read it. though still a little baffled but i get most of the offset theory.

@Trondos & Tremo
Thanks for the reassurances, I ask my friend and he says don’t worry about it =) Plus I burnt some more cds and they seem fine…altough for the next couple burns i’m gonna monitor the quality of it…just to make sure!

You know, instead of the write offset cd function, EAC should post a zipped up image of the offset cd, IF it’s a small cd (when zipped).


#10

Originally posted by Upp3rd0G
If I can find the time this weekend I will give this off-set cd a try myself. (I have a ltr-40125s myself.)

I burnt an audio cd with my ltr-40125s with EAC and it also freezes when writing the leadout… Apparently EAC doesn’t properly support this new 40sp writer from LiteOn. I guess we have wait for the next version…


#11

@Upp3rd0G, little-endian
So you guys don’t correct the writer offsets during writing? Is it difficult or just not worth the trouble?

I find it easy to correct the offsets. Assuming the cdrom/cdrw’s combined read/write offset is correct…

  1. In EAC use the combined read/write sample offset. If you want MCN/ISRC or CD-TEXT choose the appropriate options in EAC. Goto tools->extract cd image with cue sheet. (This will extract the image with the offset shifted to match the burner’s write offset.) Also make sure the gap detection issues are correct!

  2. Load up the wav/cue file into nero or cdrwin and burn. Because the image has been shifted (due to combined offset) to match the writer’s write offset, the writer will write this image with zero offset!

I’ve tested this, I’m sure its not a new disocvery but I was very happy to see this works. To test, I extracted a bin/cue image from the original and copied audio cd WITH cdrwin (not EAC!). The images were identical!

Perhaps it’s a hardware issue, like with the Plextor. Or maybe I got it all wrong =) I know I would perfer a corrected cd VS using the combined read/write mode to extract songs.


#12

It is not worth the trouble… At first I thought it was something important for the best audio copies possible, after I went through all the theory I figured out the offsetts for my Plextor PX40ts and Plextor PX-W4220t. But after reading several posts on this subject in the EAC forum I lost my interest for offsets. Even Andre Wiethoff (the author of EAC) states that he doesn’t use offsets. According to Olli the redbook audio-cd specifications says that an offset of 1 second is allowed, that is: 75*98=7350 frames offset… There is no drive outthere that is that bad! So why worry over an offset of 330 samples…

:slight_smile:


#13

@swift
Read the article “The Truth About Offsets” carefully. If you use the combined read/write offset correction you’ll loose at least the amount of samples which are equivalent to the write offset of your burner!
If you want to make PERFECT copies you’ll have to correct the offsets on reading and writing SEPERATELY!

But if your burner has for example a negative offset on writing (e.g. -30), the burner starts writing too early. So you have to overburn into the Lead-Out to record actually the last 30 samples.
If the drive isn’t capable to do this, the last samples will be missing. On reading the drive fills up the uncomplete sector with zeros (my own theory, I don’t know if this is true!!!) so the last 30 samples are ALWAYS zero (tested with my PlexWriter). If your music wave contains absolutely digital silence, then it doesn’t matter because the samples would be zero in both cases…

OK now my burner has a read offset of -30 samples (PX-W1210S) and DOESN’T support overwriting into lead-out.
Anyway I don’t want a generation loss.
So I correct the read offset, of course.
On writing, I don’t correct the offset, because no data is destoyed (in opposite to the read-offset). I correct the written offset on reading using the combined offset if I have want to copy the copy again.
The copy on CD itself is NOT perfect, of course. But I can get the “TRUE” data at all times. So I have at least no generation loss. I personally don’t like the thought, that my data is getting “worse” on copying. That’s why I correct the offsets!

I have the same opinion like Upp3rd0G, that offsets are so small that you don’t need to care about. But are we not all perfectionists? (At least on this forum ;-))
We want to perfectly copy SD2, SecuROM and all other CDs, so why not copy an audio CD perfectly???


#14

yeah well i like to correct the offset before writing. I value a correct CD as the most important. That’s because you can give the cd out and you know it’s correct…the people receiving your cd can just use thier own read offsets, no need to worry about combined offsets between their reader and YOUR writer.

Aern’t the first 300 and the last 300 samples usually silence anyways? In the end the actual music data is still there, so we are just nick picking on the position of the silence right? :slight_smile:

Can someone try something for me? In EAC, set the read offset to +588. Extract a track. Tell me if you get any missing samples. Now set it to +589, extract a track, does it have missing samples?


#15

@swift

I made a little test with EAC v0.9b11.
I read the first and the last track of an audio-CD.
I used my UltraPlex 40max with burst-mode (secure gives the same results) because it’s much faster.

And really!!

If you use an offset correction of +588 samples, you’ll have missing samples. With the values +587 and +589 I have no problems, at all. This is really strange! First I thought that this issue is only cosmetic, but I compared the two (three) waves and the one ripped @ +588 is definately shorter!

Maybe you have found a bug …


#16

yes this is indeed strange. the author of EAC is checking into this, I posted this problem at the EAC forums.

It might have something to do with 588 samples = 2352 bytes = 1 sector. However just by bad luck, the liteon 163 (+594 read offset) if used with the liteon burners (-6 write offset) have a combined offset of +588. So it means can’t get 100% offset correct extractions for the liteon 163 (using the liteon burner).


#17

@swift

maybe you can correct the read- and write-offset seperately ?