I've just started using EAC to rip music from my CD collection to my hard drive.

What I do is first of all "Test Selected Tracks" and then "Copy Selected Tracks > Uncompressed" to my HDD as WAV. Can I do anything else to ensure I get the best rip as possible?

http://wiki.hydrogenaudio.org/index.php?ti...e_Configuration

Though instead of using secure mode, use burst mode. Then use Test & Copy (it's a combined option) on the tracks and make sure the CRCs match. If they don't, rerip the tracks that don't match in secure mode.

Just read the guides and choose the options that suit you best.

I prefer secure mode: no C2 accurate stream and cache checked.

And I run them all in test & copy.

I'm paranoid about accuracy though.
JXL

Thanks for your replies :-)

What's the difference then between using Secure Mode and Burst Mode? I'm also paranoid about accuracy.

Burst mode will give you accuracy if the disc is in good condition. Test and Copy rips each track twice. A checksum is generated for each rip and if it is the same for both you have reasonable assurance that the rip was accurate.

Secure mode compares 2 reads of 27 secors of data at a time. It is my understanding that this is a bit for bit comparison rather than a checksum comparison. If the two reads differ, EAC will re-read the data and if at least half of the re-reads give the same result it will move on to the next 27 sectors otherwise it will perform another set or re-reads. The maximum number of sets is 1, 3 or 5 depending on how you have it configured before EAC gives up and tells you there was an error.

Depending on how much data needs to be re-read, EAC assigns a quality value. 100% means that no re-reads were needed. It isn't all that uncommon to rip a track more than once in Secure mode without a reported error and yet not get the same result every time. Therefore, it is still important to use Test and Copy whenever the quality is less than 100% to make sure that the rip was precise.

My personal experience has shown that it is still possible to have matching Test and Copy CRCs and yet still have an error and that this is more likely to happen when using Secure mode than when using Burst mode. In the case where this might orrcur, however, the chances are very slim that Burst mode will be able to give you a rip without errors, though Secure mode still might (even if you can't rely on the CRCs to tell you that it did). This coupled with the fact that a CRC is an inexact characterization of a track, matching CRCs cannot prove a rip was precise, let alone accurate. Provided that Secure mode does do a bit for bit comparison, a rip without an error does demonstrate a high level of precision even if this doesn't mean the rip was accurate.

Now if Secure mode isn't configured correctly, the precision goes out the window, especially when C2 is being used since C2 is based on accuracy, not precision. Unfortunately EAC is not able to get accurate C2 data from most drives.

The information above is why many people around here suggest that you rip with burst mode with test and copy first and then re-rip any tracks without matching CRCs using Secure mode without C2 (again using test and copy). If you have a drive that can report C2 with a high degree of accuracy (like one made by Plextor) it is ok to check C2 (and still use test and copy!).

The best assurance of accuracy barring perfect C2 reporting without the need to re-read any data is to use AccurateRip.

Do you mean CRC Collision

I'm not sure what you mean by "CRC Collision."

If you mean that more than one file can give you the same CRC, yes, this can happen. This is why I said that matching checksums are not proof that a rip was precise. There are as many different versions of the same track that give the same CRC as there are pairs of samples in that track. How likely this can happen is debatable.

I'm now using EAC with Accurate Rip, I've just tried it out on "The Very Best Of Starship". The track I ripped to test was "Nothing's Gonna Stop Us Now". EAC reported no errors, but then AccurateRip said



Track Ripping Status [Disc ID: 002d0794-ee110611]

3 ** Rip not accurate ** (confidence 2) [68018cb5] [a894e52b]

_______________________

Track(s) Accurately Ripped: 0
**** Track(s) Not Ripped Accurately: 1 ****
Track(s) Not in Database: 0



What is this telling me?

Try ripping all tracks, if they are all inaccurate then accuraterip suggests that it is a different pressing.

Are you using Burst mode or Secure mode?
If you're using Secure mode, what was the quality percentage and is it properly configured?
Are you using Test and Copy?
What does AccurateRip say about the rest of the tracks?

EAC cannot be trusted when it says that there are no errors.

Also, AccurateRip doesn't contain every pressing of every CD under the sun, so this rip could easily be accurate.

More information is needed in order to make educated sense of this AccurateRip log.

I've just ripped all 17 tracks from the album. EAC reported no errors (track quality 100% on every track), the CRCs all match. The results from AccurateRip are below. So should I trust EAC or AccurateRip?

Track 3 does have a few clicks in it, but I've confirmed these are in the original recording by listening to a track which I copied from a radio station's music library. The clicks on the radio station's copy are in the same place as on mine.

Track Ripping Status [Disc ID: 002d0794-ee110611]

1 Track not present in database. [4dfc60bf]
2 Track not present in database. [ad0410a3]
3 ** Rip not accurate ** (confidence 2) [68018cb5] [a894e52b]
4 Track not present in database. [f0e0b30a]
5 Track not present in database. [db1beb7b]
6 Track not present in database. [d8b9cdb1]
7 Track not present in database. [39f81780]
8 Track not present in database. [ec037c3f]
9 Track not present in database. [7efd3fb9]
10 Track not present in database. [1a5750b6]
11 Track not present in database. [152aecb9]
12 Track not present in database. [173c1bf5]
13 Track not present in database. [7450b7f9]
14 Track not present in database. [65de640b]
15 Track not present in database. [8ff54132]
16 Track not present in database. [b028c857]
17 Track not present in database. [d677167a]

_______________________

Your CD disc is possibly a different pressing to the one(s) stored in AccurateRip.

The AccurateRip log provides you with no reason to believe or disbelieve what EAC told you.

Based on what you said about EAC, I'd say that the rip was accurate.

If AccurateRip had identified only some of the tracks as being accurate then I'd suggest that you try Burst T&C, and then try with a drive that has a different chipset and see if it gave you the same CRC. It would still be possible that you have a different pressing from what is in the database. As the number of tracks it says weren't ripped accurately decreases, so do the chances that the disc is from a different pressing. But it is still possible that the disc is from a different pressing with all but one track being reported as accurate, but highly unlikely.

I'm using Secure Mode configured as per "The Coaster Factory" tutorial, I did not use Test & Copy on this rip just Copy Tracks > Uncompressed. EAC reported 100% quality on every track after the rip. It's bizzare that AccurateRip ignores all other tracks apart from track 3.

I don't think this is all that bizarre. Like I said earlier, the AccurateRip database is not complete. Considering that some people only rip the tracks they want from a disc it seems plausible that the database might only have partial entries for some albums.

You said earlier that CRCs matched. How do you have a second CRC to match with if you didn't also Test the tracks?

The Coaster Factory is a good tutorial, and hopefully you are following the caveat about C2.

What they say about "Secure Mode *must* be enabled" is a load of fascist BS. Burst is absolutely fine so long as you use Test and Copy, which you should be using anyway, or at least with tracks where the quality is less than 100%, uneless AccurateRip says the track was ok. Aw shucks, nevermind my use of the word "should." Some people don't care if there were errors, especially when they can't be heard.

...but you did say that you were paranoid about accuracy

I've changed my ripping method now. I now use Burst Mode with Test & Copy. I was a bit unsure about using Burst Mode before, it's been suggested enough times on here for it to be safe enough as long as I use it with T&C.

I've uploaded a picture of my settings here http://www.damien-tyson.co.uk/EAC.JPG - I think I'm using the correct ones

Be careful that 'greynol' talks a lot but he has no technical knowledge
about DAE and is only stating opinions based on his limited experience
(and understanding). Technical facts are quite different.

The chances of CRC collisions (which is the proper term of course) have
been calculated long time ago and they are well known, but in practice they
are much smaller than the chances of getting two times the same bad values
from the disc. The impact of using secure mode instead of burst mode depends
on this last probability, which itself depends on the defects on your disc.

Generally speaking, for a disc with only small/light scratches (normal
"good condition"), secure mode is your best choice. If the disc is heavily
damaged, burst mode is better.

Whatever spath.

If you said it then it must be true.

There is no point in arguing with someone who behaves as if he knows everything already.

I see you're reading what I write even though you said you were going to ignore me.

No offence to you at all Greynol, and I really do appreciate your help with my questions, but I think I'm going to stick with Secure Mode.

This is the last thing I want to ask I promise I'm using a Sony DVD-ROM DDU1615, in Secure Mode which boxes should I tick in EAC Drive Options? Also, can anyone recommend a better drive that I could use and get even better results?

None taken.

If you are really as paranoid about accuracy as you say you are, I still recommend using Test & Copy even with Secure mode especially when more than one bar of "error correction" lights up. However, be aware that matching CRCs and/or EAC saying a rip was OK are still no guarantee that a rip doesn't have errors.

This isn't anything someone else won't also tell you and this is really all I have to say about it. I'll leave the probabilities and their dependencies to the *experts* since my experience is so "limited" (as if spath can actually prove his specious claim).

BTW, your secure mode settings don't look like they're going to give you any trouble, especially if they were configured based on the features EAC detected. I hope the ripping doesn't go too slowly for you.

EAC detected that my drive supports C2 error information, but I'm not too sure because the tutorial I read says some drives wrongly report that they support C2. Am I right to leave it un-ticked if I'm not 100% sure?

Does anyone have any suggestions as to what drive I can buy to replace my current Sony DVD-ROM DDU1615? Ideally I'd like a Plextor because they work well with EAC from what I've read here, but which one sould I use to get best DAE results?

Thanks
Damien

The idea that many drives reported bad C2 pointers was based on tests
done with Wiethof´s tool, which was buggy, see http://www.digital-inn.de/exact-audio-copy...y-question.html
However EAC does not really use C2 error information anyway
(contrary, for instance, to Plextools), so you would not gain much
by selecting this option. Better leave it unchecked.

I find this entry (#8) as being quite apropos.

Thanks Spath.

What about "Drive Caches Audio Data"?

You need to find out if your drive caches audio before you know whether or not to enable the cache-overriding radio button. First do the EAC drive feature test, and if EAC shows your drive caches audio, then enable the cache-overriding radio button. If EAC shows that your drive dosen't caches audio, then you need to download feurio and do a drive feature test with that app. If feurio also dosen't show your drive to be caching audio, then you can trust that your drive dosen't caches audio, and safely leave the cache-overriding radio button disabled. The reason why you need to do the extra drive feature test with feurio if it says that your drive dosen't caches audio, is because EAC's detection routines for audio caching is known to be buggy and can sometimes show that a drive dosen't cache audio but even though still use the drives cache during extraction.

Martin H sez:
>then enable the cache-overriding radio button

Actually, that particular control is a check box, so saying "tick the check box" would be more accurate. The others, labeled "Secure mode with...", "Paranoid mode" etc. are indeed radio buttons.

HTH!

*LOL* I must be some kind of moron for confusing those two things

Thank you for the correction Never_Again

CU - Martin.

Actually I have seen several cases where Feurio also incorrectly reports that a drive does not
cache when it does, for instance http://www.hydrogenaudio.org/forums/index....showtopic=44050
That's why I've written a small tool to detect cache faster and hopefully more accurately than
Feurio, I will release it probably next week. In any case, you will not decrease the quality of
your rip by keeping EAC's "Drive caches" option ticked.

hey, guys!..

I've been reading this wonderful discussion with great enthusiasm and find some advice given here to be of tremendous use...
anyway, there are some particular points of my concern related to the EAC in "Test&Copy" mode...

it is alright for me (and for most of us, as well, i guess) as far as i use it to rip tracks but what do you do when it comes to making images with cue-files?..

The method I have elaborated is as follows:
1. first read data and rip with external encoder, and see what CRC you get...
2. then read data into wav-file only and check whether two CRC's match...

it can be vice versa, so never mind...

Synthetic Soul once said that Andre was thinking of implementing the function "Test&Copy" into images...
But so far we don't have it and I would appreciate your ideas about soluting this small issue...

ps. by the way, i use secure mode with no C2 and "drive caches audio" since my Lite-On 451 indeed caches data...

Thank's for the correction

Yes, there really is a need for a tool that accurately can detect audio caching. On top of that, then all the other drive specific things that your tool also can detect, really makes this a very nice tool indeed, and i'm sure other people will appreciate this tool very much also

Thank you very much spath

CU, Martin.


Yes, untill Andre releases a new EAC version, then you are stuck at first ripping to image + cuesheet, and then afterwards ripping by range, and then compare CRCs manually. If ripping in secure mode without C2 and cache overriding enabled if needed, and getting 100% track quality, then the rip has the same secureness as if using burst mode with test & copy with matching CRCs. If the track quality is lower than 100% while still EAC reporting "No errors occured", then the secureness is lower. I use secure mode with C2 on my Plextor PX-755A, which on a rip with 100% track quality has the secureness that matches the used drives C2 pointer accuracy eg. if the drive has 99.5% C2 pointer accuracy, then the rip is 99.5% secure. If the track quality is under 100%, then the secureness percentage gets much lower, since EAC sadly only uses C2 pointers during the initial reads, but not on the extra rereads.

CU, Martin.

Martin,

Can you briefly explain *your* definition of secureness?

Ripping in Secure mode with and without C2 checked are two very different things.

Ripping without C2 and 100% quality with cache flushing applied if needed shows that the same thing was extracted twice but is no assurance that there was accuracy.

Perfect C2/CU reporting with 100% quality, OTOH is an assurance of accuracy.

Hi greynol


The degree of wich to trust that the extraction was accurately ripped ie. without any errors slipping through.

Of course it is Where have i said otherwise ?

Of course I said that it was comparabel in secureness level as to using burst mode with test & copy with matching CRCs. I didn't say that it was an indication of 100% accuracy.

Absolutely

CU, Martin.

Nowhere that I could see.

So would you say that a rip done in EAC using Secure mode without C2 isn't secure?

With 100% track quality, then the degree of secureness is pretty good, just like with burst mode + test & copy with matching CRCs. This is because that there haven't been any inconsistent errors at all in the rip, and hence, then chance of consistent errors is very little. If getting under 100% track quality + "No errors occured", then there is still a pretty good chance of having an accurate rip, but the chance is smaller compared to the above scenario, as there have been detected inconsistent errors, and hence, there is a chance of consistent errors somewhere in the rip.

How does the chance of consistent errors being small follow from there being no inconsistent errors?

This does not make sense to me.

Guys, thanx for explaining...
But now I am even more confused than i was before...

so, let me put it this wasy - could you tell me what setting do you personally use if you want to rip an image?..

The two most important questions:

1. do you use a burst mode or secure?..
2. if secure, then with or without C2?..

earlier i used to enable C2 while ripping with my Lite-On 451 but then I was told it is better to check it off...bow it seems i should enable it again...
So, where is the truth?..
Is a Lite-On drive trustworthy enough to enable C2?..

1) Secure since it would be a big waste of time to rip in Burst to discover there was an error and have to rip the damn thing over again.

2) Depends on your drive. With a Lite-On, I'd say to leave C2 unchecked. If I had one, I could tell you for certain.

When ripping an image, if you don't get 100% quality and a re-read had ocurred somewhere besides at the *very* end, you can rip it a second time to see if the checksums match.

As was mentioned earlier, barring a drive with perfect C2 reporting you can't be assured an accurate rip. Since you're talking about an image, AccurateRip (the program) doesn't apply. Matching checksums is the best you can do in this instance.

1. If the disc is in good condition or only lightly scratched, secure mode will help.
2. Without. EAC does not really use C2 information anyway, so even if C2 pointers
are accurate on your drive you would gain almost nothing.

When we can see from the track quality that EAC haven't detected any inconsistent errors(100% in no-C2 mode), then it's logically to assume that the chance of consistent errors is slim ie. the probability to have consistent errors but no inconsistent errors present. On the other hand, if EAC allready has detected inconsistent errors, then the chance of consistent errors automatically rises, since it's quite possible that there besides the inconsistent errors also are consistent errors, which as you know, EAC can't detect in no-C2 mode(and can detect in C2 mode, but will falsely think has been corrected if doing extra rereads ie. under 100% track quality).

But you're just telling me that it's logical. I was hoping you could actually explain the logic.

How is it that the existence consistent errors implies an extremely high likelihood of inconsistent errors?

This certianly seems to support my contention that you are less likely to get consistent errors in Burst mode than you are in Secure mode which spath said was "nonsense".

Honestly, I'm torn here since it appears that spath knows what he's talking about and seems to run counter to what it is that you are saying.

When you have a scratch on a CD, then there ussually will not be a single errorred byte, but many errored bytes. When EAC then shows "No errors occured" and you have a track quality of under 100%, then you know that a) there have been detected inconsistent bytes which have been corrected by the drive by rereading, and b) the disc is damaged ie. scratched or something. Now as the disc is known to be damaged, then some of the damage can very vell by of a consistent nature ie. bytes totally unreadable and interpolated ie. consistent errors. On the other hand, if the disc dosen't have inconsistent errors like if getting 100% track quality or burst mode with test & copy with matching CRCs, then there still is a small chance of consistently errored bytes somewhere, but as scratches will normally turn very many bytes wrong, some of them inconsistent and some consistent, then the chance is pretty slim, although not impossible...

If having under 100% track quality in secure mode + getting "No errors occured", then i would say that the chance of consistent errors is bigger than if the rip was done in burst mode with test & copy with matching CRCs. I don't know what exactly you and spath was discussing, so i won't comment on that. One thing is for sure though, and that is that spath knows his stuff right, so if i have said anything wrong here, then i would certaintly appreciate if spath would correct and enlighten me on these issues

Here it is warts and all:
http://www.hydrogenaudio.org/forums/index....67&#entry400967

I want to believe what you are saying is true since it gives me more confidence in EAC being able to attain accuracy besides simply being able to deliver precision.

Here's the tool I was talking about : http://download.cdfreaks.com/download/155
Questions and comments can be posted here : http://club.cdfreaks.com/showthread.php?t=184487

What method does it use to find the cache?

I have tested several methods to determine the cache size but the one
which seemed to work best was to detect when the first sectors of a
burst are cached out by new reads. Some modern drives have optimized
cache reloading strategies, which make it difficult to precisely measure
the cache size, but this method allows to avoid this problem.

Here's an example :

>cachex -i -d -c -n 3 d:

CacheExplorer 0.7 - spath@cdfreaks.com

Drive on D is PLEXTOR CD-R PX-W2410A1.04

[+] Buffer size: 4096 kB, read cache is enabled
[+] Supported read commands: BEh D8h
[+] Testing cache line size:
info: using command BEh
info: 3 test(s), c/nc ratio : 4, bursts of 1 sector(s)
1169 kB / 509 sectors (138.74 .. 1.28 -> 34.42)
1169 kB / 509 sectors (138.87 .. 1.26 -> 34.44)
1169 kB / 509 sectors (138.92 .. 1.34 -> 34.43)

Initial read (where cache is filled) takes about 138 ms,
subsequent reads of the same sector take about 1.3 ms
since they come from the cache. In the meanwhile we
keep reading sectors further and further, until we force
a cache reloading. Then, reading the initial sector takes
about 34 ms.