I have a plextor 40x and a lot of problems with a couple of CD.

I Use EAC to extract the files to WAV.

I have a small glitch at the start or the end of the file but only once saved. If I open it in the internal audio player the problems are not there.

Please Help !

FWIW

I have a Plextor PX-40TW CD-ROM drive connected to an Adaptec 39160 SCSI card (yeah, I know that card was way overkill) that I bought specifically to rip audio CDs using EAC. It has performed perfectly for about 18 months and about 550 CDs.

The only "glitch" I've ever heard was at the beginning of the first track on a CD that was a copy of an original. The equipment and software used to make the copy were unknown. I chalked it up to a bad copy and used the EAC wave editor to silence it - lost about the first tenth of a second.

Hmmm, just had a thought .... I do NOT have the option checked "EAC options / Extraction / Delete leading and trailing silent blocks". Do you (rhetorical question)?

I hope this helps - Cheers

Such glitches can be caused by standalone burners (begenning of the CD), or Track-At-Once burned CDRs. In this case, the glitch is muted when the CD is played regularly, but copied when an extraction to WAV is made.

I do not have the "remove silence" option. But I have solved the problem in a different way: I have increased the sample offset from +676 to +850. This solved the problem for those CD.

Thank you.

Which is the reason because the glitch is muted by CD players and not by the extraction software?

Again: why the internal EAC wav player does not play the glitch and If I save/reload it the glitch is there



Thank you in advance for you answers.

I don't know. The "play CD" command (realtime playback, audio outputs on) may use a different chipset than the "Read CD" one (extract at high speed, audio outputs off), and performing error concealment that the extraction doesn't.



It may also be an offset correction problem. The internal player doesn't use offset correction. Maybe the glitch is cause by the offset correction, and in this case, ripping with offset 0, there would be no glitch.