I recently tested the C2 error correction on my CD/DVD-ROM unit (NEC 3540A) and got a "Yes, this drive supports C2...."

Previously when I ripped my CD's I left this field unchecked and at best got a speed of 10x. Something I was perfectly happy with (a smal price to pay for accurate copy's of my albums)
Now the extraction speed reaches 30x. Is it still as accurate as before?
I've got apx. 700 albums (+singels). I may want to rip them all and this is something I do not want to do more than once

Also, being new with EAC (V0.95 prebeta 5 from 8. March 2004) and all the various settings , I'd like to know if I made any mistakes

In general, with NEC drives, using C2 with EAC is not reliable.

If you don't have AccurateRip installed, or your disc isn't in the AccurateRip database, the best way to verify that you had a successful (that is to say precise, but not necessarily accurate) rip is to use Test and Copy (F6).

Matching Test and Read CRCs can usually ensure that having C2 checked did not cause a problem but with some drives (usually generic ones) you can get matching checksums for rips that are in obvious error.

If speed is what you are after, use Burst mode and then rerip any tracks that don't give matching checksums in Secure mode without C2 when using your NEC.

Also, gap detection set to anything but Secure can give incorrect resluts. But, IMO gap detection isn't important (at least not as important as ripping without errors ).

Confirmed: EAC's C2 function is not reliable with NEC drives. I have to say that you can get falsely matching CRCs with any drive (what is a "generic drive"?) in certain cases, especially in Secure Mode. Burst Mode with Test & Copy is the way to go.

DVDRW IDE1004

Agreed. And for an extra level of confidence use Accuraterip.

why is that? I am using EAC quite a while now and was thinking that "secure mode" with c2 unchecked and the other two options checked was the way to go.

I am more confident that a pair of matching CRCs delivers an accurate rip using Burst mode than I am using Secure mode.

Check this post:
Trouble ripping Lateralus, Errors at end of CD.

I can get matching CRCs for rips with errors in Secure mode with this particular disc and a few others repeatably. I have never been able to do this in Burst mode.

I can't help but notice that you are specifically calling out options under Secure mode. You do realize that checking "Drive caches audio data" provides no benefit when used with a drive that doesn't cache audio data, right? And if we're talking about these settings as if to take the safest approach (assuming that EAC isn't capable of detecting anything correctly) then unchecking "Drive has 'Accurate Stream' feature" would be the way to go. Now please understand that I'm not recommending that this be done. I'm just trying to make the point that these settings are drive-specific. If they weren't then they wouldn't be there for us to tweak and we'd all be using an older version of EAC with something very similar to the current paranoid mode (which works very poorly and gives horrible errors with matching CRCs with one of my drives, btw).

>then unchecking "Drive has 'Accurate Stream' feature" would be the way to go

I would guess that all cd drives made today are accurate stream, if not spend $20 and get one that is...

Thanks for the answers

I've disabled the C2 option and the settings now look like this:

The relatively slow rip doesn't bother me.
When I was using Audiograbber I usually ripped at 8-16x and never more than half the top speed of the drive.

About Test & Copy.
Is it as simple as ripping the track/disc once and then check that the Read CRC and Test CRC values match / or that I have an "OK" in the "CRC" column?

If you used Test & Copy with Secure mode and no C2 then the disc was read no fewer than four times, assuming that the "Drive caches audio data" is set correctly for your drive. In Burst mode the disc will have been read twice.
To answer the other aspect of your question, yes it is as simple as looking for an OK in the CRC column which shows that the Test and Read CRCs match.

>>then unchecking "Drive has 'Accurate Stream' feature" would be the way to go

>I would guess that all cd drives made today are accurate stream, if not spend $20 and get one that is...

To be sure. Making no assumptions about neomoe, there are many out there that incorrectly believe that "Drive caches audio data" should always be checked. Consider the Accurate Stream comment as my response to the ones who justify always checking audio caching as being fail-safe.

I have to say this is the only place that people would be worried about their CDs ripping fast...

It all depends if you want the best quality or to just get it done quick good enough. My settings are very slow ~2x but it rips copy protected discs that make the faster drives in my house barf sync errors and stop.

Used drive : TSSTcorpDVD-ROM TS-H352A Adapter: 0 ID: 0
Read mode : Secure with NO C2, accurate stream, disable cache
Read offset correction : 12
Overread into Lead-In and Lead-Out : No

I thought by checking that drive caches box, you were having EAC disable/not use that function while ripping. That's what my log seems to indicate and most recommendations suggest that's a good thing.

The wording in the log is misleading. It doesn't accurately describe what is going on.

Caching is a function of the drive over which EAC has no control other than to flush by reading more data.

Many drives don't cache audio data and checking this setting provides no benefit; it only makes rips take longer.

If anyone can explain exactly how EAC clears a drive's cache using this setting I'd appreciate reading it.

I'd also appreciate knowing specifically how EAC knows that an error occured when I rip using a drive that caches audio data with the setting unchecked. The over-simplified explanation of audio caching suggests that EAC would never see an error and I know this simply isn't true using a drive that caches just over 100kB of audio data and one that caches just over 1MB of audio data.

It overreads 2MB, thus filling the cache with other data, then goes back and re-reads the sectors.

One down, one to go. Thanks for the response Firon.

If simple logic cannot help you figure out the answer to #2, I'm sure you will find it at CDRInfo.

Instead of giving me a smug answer, perhaps you can explain this to me.

I've decided to go for Burst Mode with Test & Copy + AcuRip.
And if I get errors I'll rerip in Secure Mode (nothing checked) with (again) Test & Copy + AcuRip.

Now all I have to do is to learn all those MP3/OGG compression command codes %N %T...

That would be my recommendation.

For Secure mode:

1. It's safe to use Accurate Stream if it's detected, I was exaggerating about this earlier.
2. Go with the whatever EAC says about audio caching.
   Try checking the setting if you are having trouble getting T&C CRCs to match. This may make a difference if your drive caches audio data and EAC says it doesn't, but I'm pretty sure that this isn't a problem with NEC drives.
3. C2 is best left unchecked with NEC drives.

My current external compression command line in EAC (using Lame 3.96.1):

• %l--alt-preset cbr 192 -h%l%h--alt-preset standard -h%h %s %d
• add id3 tag is checked
• using v1.1 instead of v1.0
• using v2 tags
• v2.4 tags unchecked.

I don't worry about any of the rest; it's pretty bare-bones.
I hope this helps.

It's a good start, thanks
Gonna have a look in the info files that came with Lame3.97b2.
Want to test how low I can encode Stand Up CDs (kbps, kHz, mono/stereo) and still get a decent sounding usable file

I am aware of that, yes. but it would not make things worse, when "drive caches" checked, right? the rip will propably be slower but nothing else..

Besides being slower, does caching checked when it doesn't need to be make things worse?

I can think of a couple things.

Reading more data than necessary adds additional wear and tear on the drive.

Reading more data than necessary can cause a disc to heat up more which is known to make ripping more difficult.

For tracks that are larger than the size of the audio cache, matching T&C checksums makes the issue moot; even in the situation where caching isn't checked even though it should be.

And, yes, if you want to check audio caching even when it is not required go right ahead.

When it comes to identifying an accurate rip, let AccurateRip be your guide first with T&C checksums using burst mode second and T&C checksums in secure mode with no C2 third.

If you insist upon checking caching regardless of the drive, why not insist upon unchecking the accurate stream feature? Besides being slower, will unchecking this setting ever compromise the quality of your rip?

I just meant, it will not cause you any BIG trouble.. certenly it will be best to let EAC determine what should be checked for your specific drive.

neomoe:
>I just meant, it will not cause you any BIG trouble.. certenly it will be best to let
>EAC determine what should be checked for your specific drive.

I don't believe it will cause andy BIG trouble and I don't believe it's going to increase your chances of getting a bad rip with matching CRCs.

Sorry for giving you a hard time earlier. I'm just trying to do what I can to kill the perpetuating myth that this setting must always be checked.

greynol wrote:
>Reading more data than necessary adds additional wear and tear on the drive.

Correct. That's why a drive should never be used for reading data.

>Reading more data than necessary can cause a disc to heat up more which is
>known to make ripping more difficult

Known to who? Absolute nonsense.

>For tracks that are larger than the size of the audio cache, matching T&C
>checksums makes the issue moot

False, EAC doesn't read a track all at once. If you are not familiar with EAC basics like that and Accurate Stream, why not do some research before attempting to dispense advice? spath's posts (here and on CDFreaks), Martin H.'s posts and digital-inn.de are a good source of info... Oh, I forget: you don't need all that crap when there is CDRinfo.

>I'm just trying to do what I can to kill the perpetuating myth

Haha, yes! Coming from someone who claims that spyware and viruses cause ripping errors through increasing CPU/RAM load, this is just too funny.

Never_Again, quit before you get any farther behind.

>Coming from someone who claims that spyware and viruses cause
>ripping errors through increasing CPU/RAM load, this is just too funny.

I never made such a claim and you cannot demonstrate that I have. This is known as libel.

My statement, "For tracks that are larger than the size of the audio cache, matching T&C checksums makes the issue moot." is very much true.

EAC doesn't rip a track all at once. Yes, sherlock, of course it doesn't. But how does that do anything but help to support my statement?

If you are not familiar with EAC basics like audio caching and CRC generation, why not do some research before attempting to argue with someone who is. I am familiar with AccurateRip as well.

And about discs heating up and causing errors, do you disagree with this concept or do you feel that having EAC overread to clear the cache doesn't contribute to extra disc heating? If you disagree with the first part, I would suggest you take to the initiative to better educate yourself on the concept of thermal expansion.

If you keep following me around and throwing punches in the dark like this, you're going to end up looking and feeling pretty stupid. Again, heed my warning: quit before you get any farther behind.

Eh ? 3 days ago in this same thread you asked how EAC handles cache and
now you claim to be familiar with it ? From all you posted so far it is quite clear
that you have no precise idea of what you're talking about, so you might want
to follow your own advice about "looking and feeling stupid".

What a pleasure it is to get a response from the biggest ego I've seen in this forum (or any).

Perhpas you can shoot down my argument:
For tracks that are larger than the size of the audio cache, matching T&C checksums makes the issue (incorrect audio cache setting in EAC) moot; even in the situation where caching isn't checked even though it should be.

I don't think you can. Consider it as a challenge. I eagerly await your response.

The cache setting won't matter at all in T&C burst mode as long as the track is at least twice as large as the cache, I believe.

Well I just tried T&C Burst Mode and it was several times faster.

Was it as accurate as Secure mode?



EAC T&C CRCs all match.

Used drive : TSSTcorpDVD-ROM TS-H352A Adapter: 0 ID: 0
Read mode : Burst
Read offset correction : 12
Overread into Lead-In and Lead-Out : No

You're cute There's a trivial answer to this but unfortunately my oversized ego
did not like your bad manners, so it compels me to ignore you from now on

of course it doesn't
I'd be heartbroken if you weren't replaceable.

...somehow I don't feel immune to future receivings of your arrogant abuse.

Looking at your accuraterip log, yes.