Typically when I rip a cd with EAC v.9 beta 4 when the cd has finished ripping, it tells me that no errors occured, but quality is 99.9%. This is very concerning for me, as I want to have flawless archival of my cd's. Then sometimes it says quality is 100%. Should I be worrying or what?

Also, how can I be sure that when EAC says it has a 100% flawless copy that there are absolutely no errors?

Thanks!

Hi,

this is explained in http://www.exactaudiocopy.de/ -> FAQ -> Extraction questions

The short answer is: you shouldn't worry, unless there are suspicious positions reported. If you're paranoid like me, you can do a Test+Copy, and see if the CRCs match.

I understand that a track quality of 99.9% indicates that EAC successfully extracted the track after error correction. But, what about the source CD? Is it defective? Even brand new CDs sold here have at least one track with track quality of about 99.9%. Is this a common phenomenon or are the music companies selling us defective CDs? I use an Asus 52x IDE CDROM drive to extract the files. Thanks.

Thanks guys. I do have some more questions, however. First, when I rip a cd straight to mp3, it decides to start encoding while the cd is still ripping! How do I make it wait until the entire cd's extraction is complete for it to begin encoding?

Also, what exactly does "qval=2" mean in LAME? I also set the LAME toolbar in EAC to -alt preset insane, but I notice it still has options available for high low quality, bitrate, etc. If I set it to alt present insane, and then mess with those settings, will they override the preset?

Thanks!

Being a newbie, I'll do the FAQ duty.

1) Patsoe's answer is exactly correct. All that means is that EAC came across a reading that didn't match, and went back and read it more to get a better average of the same data. Test it with the CRC match and, if it comes out the same, you can be 100% sure you got exactly the data off of the CD.

2) The CD is not necessarily defective. There could be dust on it, or perhaps on your CD drive's lens. If you didn't get a sync or read error, and the CRC check came out okay, then you got exactly whatever data was on the CD.

3) I'm not sure how to make it wait until the end to encode. Try checking either EAC Options or Compression Options.

4) (This is wrong, should be "q" not "Qval") Qval refers to VBR quality and can be between 0 and 9, with 0 being the "best." But it's not the best, it mostly slows down encoding speed and often creates more artifacts, because it's not as well tested and developed as q2. Think of q0 and q1 being "experimental." You can search around for more info on this; it has been discussed a lot.

EDIT: Qval has nothing to do with alt-preset insane, which is 320kbps CBR. Qval only affects VBR.

EDIT2: I'm entirely wrong, q is not the same thing as Qval. See three posts below.

I'd like to point out, that there is nothing wrong with ripping and encoding at the same time. If you have Ultra DMA mode enabled for your drive (everyone should do that - check that it is, it's not usually on by default), the extraction process takes very little CPU time. A few percent, depending on your CPU type and speed of course. The simultaneous encoding process will not affect your rip, or couse errors or anything. It speeds things up quite a bit.

Thanks, Secret Cheif

For me, less than 100% quality is more the rule than the exeption. It must be drive-related. It doesn't mean that the CD is defective, but rather that the drive is pushed to the limit in order to extract the fastest possible.

In EAC/EAC options/tools, there is a checkbox for "on extraction, start external comrpessors queued in the background" that you can disable.

This is not correct. Qval is not the VBR quality, it's the general algorithm quality. The VBR quality switch is -V0...9, algorithm quality is -q0...9. The -V switch mainly affects filesize & quality, whereas the -q switch mainly affects speed & quality. -q can be used for CBR, ABR and VBR; -V calls VBR.

-V0 and -V1 are not experimental. -q0 and -q1 could be called experimental; the recommended setting is indeed -q2.

Now that I'm ripping, I remember that most of the 99.9% quality I get are because there is error correction between the tracks. It's a slight bug in EAC. AFAIR, the rereading is required to synch between tracks, but is sometimes improperly displayed as error correction, while it should be hidden, thus the quality is actually 100 %.

It should also probably be pointed out that if you have a brand new CD and EAC reports that the track quality is less than 100%, the "problem" might simply have been a speck of dust or fingerprint on the disc. It's no indication of a faultily manufactured disc.

My experience is that you need a very, very fat fingerprint in order to drop quality below 100%.

Yes, I remember now. Whenever I obtained tracks with 99.99% quality, I observed that the track quality indicator starts lighting up after 99% of the track is ripped. So I think what Pio2001 says is true.

On the re-reading to sync between tracks part, I noticed that after I set the read offset and enabled overread into leadin/out that this didn't occur where it had occured before.

Also my new method for extraction is to test the tracks of a cd in accurate mode and extract with burst mode. Am I correct in thinking that if the crc's match, then this is a quicker way of ripping cd's without any loss in quality of extraction?

If the CRC's match, then you have identical copies.

Maybe I've missed something, but why test the tracks in exact mode, and rip in burst? Why not just rip them in exact mode to begin with?

I own an Asus 52x CDROM drive. I obtained the read offsets from SatCP's site. However, despite entering the offset value in EAC, I continued to obtain rips with quality 99.9%. The track quality indicator starts lighting up at the end-when 99% of the track is extracted-just like before. So, in a nutshell, this did not help me.

JensRex: The reason I started experimenting with this was that I was extracting in secure mode and getting pops in some songs ( even on new cd's), i'd play the songs in windows built in cd player and there would be no pops. So i extracted in burst mode, with the result of having the same crc for the track but no pops.

Rohanc: It only stopped doing this after enabling the overread check box

Sounds like your drive caches audio data and you don't have the option "Drive caches audio data" enabled, _io_.

The drive doesn't cache audio data.

I have noticeed though that not all the pops that i get are related to the extraction. Is it possible for the sound card to introduce pops into audio playback?

Yes; check if they are random. That happens especially with Creative cards(/me being an old victim of this).

Some drives are consistently reported not to cache by EAC, while Feurio detects a little audio cache in them.

Thanks for that info Pio2001.
It's worth to check with Feurio the drives, then.

Could it be because the drive tries to read the lead-out without success?

If I set offset to 0 and uncheck "Read into Lead-in/Lead-out" this mysterious 99.9% quality thing disappears. And the final 99% section of the track no longer causes error correction indicators to lit.

Feurio reports no cache for audio data also i don't have a creative sound card, however I do have a via motherboard and i use the onboard sound. Could this be the problem?

Yes, it can be.

Try this:
Decode MP3 to wav using winamp.
Burn audio CD.
Play the CD in a normal CD player.
See if you can still hear the pops.

Thanks, but I don't hear pops. It was _io_.

I wanted to see if this was true. I bought a brand new pressed CD. It had absolutely no dust, visible scratches or finger prints on it-in a nutshell, it was almost straight out of the oven. I inserted the disc in my computer. Ripped all the tracks with EAC 0.9b4 with the following options:
Secure mode, check mark next to "Accurate stream", check mark next to "Drive caches audio data", no check mark next to "Drive supports C2 error correction".
I did a "Test & Copy". All the CRCs matched. However the first two songs had 99.99% "Track Quality". The "Track Quality" indicator starts lighting up after 99.99% of the track is ripped in both cases. The remaining tracks had 100% "Track Quality".
I then did a "Test & Copy" of the first track only. The result - 99.99% "Track Quality".
I then did a "Test & Copy" of the second track only. The result - 99.99% "Track Quality".
Conclusion: In my case, the statement quoted above does not hold good. So what could be wrong? Is it the ASPI layer? Is my brand new CD defective? How long will it live? I use an Asus 52x CDROM drive. Somebody please help.

Maybe the drive only understands the read command per track, and offset correction has to read through the next track, therefor performing a synchro.
Maybe there is a problem with tracks markers. I once got a strange bug in CD Architect : the tracks burned that were multiple of 4 (track 4, 8, 12 ...) could not be seeked from a Yamaha hifi Player, while the computer recognized them without problem. I don't know how track markers works. IIRC, I sometimes have error correction at track change even reading by range.