Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Problems at the start or the end of a wave file (Read 3078 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Problems at the start or the end of a wave file

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 !

Problems at the start or the end of a wave file

Reply #1 –
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

Problems at the start or the end of a wave file

Reply #2 –
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.

Problems at the start or the end of a wave file

Reply #3 –
Quote
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



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.

Problems at the start or the end of a wave file

Reply #4 –
Quote
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.


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.
 

Problems at the start or the end of a wave file

Reply #5 –
Quote
Which is the reason because the glitch is muted by CD players and not by the extraction software?


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.

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


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.