Hydrogenaudio Forums > EAC ripping problem -- extremely slow

Keynes

Jul 7 2006, 06:04

Hello,

This could be a problem and it could be nothing at all, I'm not sure. I just ripped my first CD with EAC using Secure mode (Accurate Stream enabled, caching and retreiving C2 info disabled); the average speed for the album was 1.9x. Is this normal? It seems a bit slow to me, since I've got a fairly new CD drive (from last year) and a clean CD (all tracks were 100%). The FLAC encoder, on the other hand, ran in just a few seconds--it almost seemed too fast...

Also, as I'm typing this I'm listening to the files, and I've noticed a glitch at the beginning of one of the tracks. Are there any common reasons this would occur?

If I knew the applicable specs I'd post them. I'm using EAC .95, beta 4; FLAC 1.1.2; Matshita (aka Panasonic) UJ-840S. Playing files in VLC 0.8.5. EAC settings mostly as per The Coaster Factory and the EAC and Flac article at the HAK.

Thanks.

greynol

Jul 7 2006, 11:30

Does EAC say the drive caches audio data? If it doesn't then you'll save time by not having EAC perform its flushing routine.

The Coaster Factory, IIRC suggests to always use secure mode which is a load of BS.

Test and Copy using Burst mode is just as good (if not better) than Secure mode if you get matching checksums and in your case will be MUCH faster. Save Secure mode usage for when you can't get matching CRCs, though if a track is in really bad shape, you'll probably want to go back to Burst mode in order to get the damn thing finished.

Discs in good condition don't need Secure mode. The extra time and wear on your drive isn't necessary.

Klyith

Jul 7 2006, 11:50

You should to check that your drive isn't set to PIO mode. (instructions) If it's in DMA, then your problem is just that your settings in EAC are the slowest possible. Secure mode on a drive that caches audio and doesn't support C2 can be really slow... 2x is pretty bad though.

It would be faster to set EAC to burst mode with testing... Or get a new drive. NECs don't cache and have C2.

greynol

Jul 7 2006, 12:00

QUOTE(Klyith @ Jul 7 2006, 10:50)

It would be faster to set EAC to burst mode with testing... Or get a new drive. NECs don't cache and have C2.

I've seen many examples that show using C2 with NEC drives is a bad idea. Blame EAC for this if you like, it does not give secure results.

Klyith

Jul 7 2006, 12:40

QUOTE(greynol @ Jul 7 2006, 14:00)

I've seen many examples that show using C2 with NEC drives is a bad idea. Blame EAC for this if you like, it does not give secure results.

*searches* Huh. I wasn't around last month when that was discovered. In general that doesn't bother me, since I use CDex normally and only switch to EAC if there are audible problems. But I may go back and re-rip my flac backups of cds that have scratch problems.

greynol

Jul 7 2006, 12:59

QUOTE(Klyith @ Jul 7 2006, 11:40)

*searches* Huh. I wasn't around last month when that was discovered. In general that doesn't bother me, since I use CDex normally and only switch to EAC if there are audible problems. But I may go back and re-rip my flac backups of cds that have scratch problems.

Last month, that's a real riot...

Take some lightly scratched CDs and use Test & Copy. You'll find out soon enough!

CODE

EAC extraction logfile from 26. December 2005, 10:09 for CD
Used drive  : _NEC    DVD_RW ND-3500AG   Adapter: 3  ID: 0
Read mode   : Secure with C2, accurate stream, disable cache

Track  3
     Track quality 100.0 %
     Test CRC EEFB40E6
     Copy CRC D33F9264
     Copy OK

Track  5
     Track quality 100.0 %
     Test CRC 033F9487
     Copy CRC BE77B240
     Copy OK

Track  6
     Track quality 100.0 %
     Test CRC 200E0993
     Copy CRC 8CE54BA0
     Copy OK

sumone

Jul 7 2006, 13:51

Why does it say 'copy ok' if the CRCs don't match? Is that what you're trying to point out?

Keynes

Jul 7 2006, 17:01

Thanks for the input, everyone, it's much appreciated. Of course, now I've got a couple more questions...

QUOTE(greynol @ Jul 7 2006, 13:30)

Does EAC say the drive caches audio data? If it doesn't then you'll save time by not having EAC perform its flushing routine.

I was remiss in not giving the drive info. Here it is:
Matshita UJ-840S
-Supports 'Accurate Stream' feature
-Does not cahce
-Is capable of retreiving C2 error information

When I encoded the files I had the 'Accurate Stream' feature enabled and both caching C2 error retreival disabled. Coaster Factory said that I should test C2 with a scratched CD to see if it was really up to snuff, and I didn't have any with me that were too scratched. Should I go ahead and enable C2 anyway, without testing it myself?

QUOTE(greynol @ Jul 7 2006, 13:30)

The Coaster Factory, IIRC suggests to always use secure mode which is a load of BS.

Test and Copy using Burst mode is just as good (if not better) than Secure mode if you get matching checksums and in your case will be MUCH faster. Save Secure mode usage for when you can't get matching CRCs, though if a track is in really bad shape, you'll probably want to go back to Burst mode in order to get the damn thing finished.

Discs in good condition don't need Secure mode. The extra time and wear on your drive isn't necessary.

That's... frustrating. All three guides I consulted (the EAC drive config entry at HAK, Coaster Factory, and this forum post) say that Secure Mode is recommend. It's a bit of a shock to hear otherwise.

Also, I understand the concept of CRCs (I've used md5), but is there a link or guide explaining how to enable them in EAC?

Edit: The CRCs work with the WAV files, if I understand correctly. So does that mean that I'll have to rip all tracks to WAV and convert to FLAC later?

QUOTE(Klyith @ Jul 7 2006, 13:50)

You should to check that your drive isn't set to PIO mode. (instructions) If it's in DMA, then your problem is just that your settings in EAC are the slowest possible. Secure mode on a drive that caches audio and doesn't support C2 can be really slow... 2x is pretty bad though.

It would be faster to set EAC to burst mode with testing... Or get a new drive. NECs don't cache and have C2.

I'll go check on the PIO mode now.

QUOTE(greynol @ Jul 7 2006, 14:00)

QUOTE(Klyith @ Jul 7 2006, 10:50)

It would be faster to set EAC to burst mode with testing... Or get a new drive. NECs don't cache and have C2.

I've seen many examples that show using C2 with NEC drives is a bad idea. Blame EAC for this if you like, it does not give secure results.

So if I don't have an NEC drive, can I enable C2 with a fair amount of confidence?

Martin H

Jul 7 2006, 19:19

I would recommend enabling C2 atleast for the newer NECs...

C2 accuracy measured by cdrinfo.com by using Andre Wiethoff's C2Extract.exe and two different ABEX test discs :

NEC ND-3500A = Between 98.6% and 96.3%
NEC ND-4551A = Between 99.8% and 100%
NEC ND-4571A = Between 99.9% and 100%

(Also i would recommend enabling C2 on LG GSA-4167B as it got between 99.8% and 100%)

QUOTE(Keynes @ Jul 8 2006, 01:01)

So if I don't have an NEC drive, can I enable C2 with a fair amount of confidence?

Check if your drive has been measured for C2 accuracy on cdrinfo.com first, and if it hasen't, then you can make the C2Extract test yourself, you just need to download Andre's DAEQuality archive on the EAC site and follow the included instructions. Also you can make some manuel tests with C2 on and off on lightly scratched CDs and compare CRCs.

Cosmo

Jul 7 2006, 19:21

QUOTE(Keynes @ Jul 7 2006, 19:01)

Also, I understand the concept of CRCs (I've used md5), but is there a link or guide explaining how to enable them in EAC?

Edit: The CRCs work with the WAV files, if I understand correctly. So does that mean that I'll have to rip all tracks to WAV and convert to FLAC later?

Every time a track is read for test or copying, CRCs are automatically generated and displayed in the GUI and log file. You don't need to enable.

You don't need to wait to convert to FLAC.

QUOTE(Keynes @ Jul 7 2006, 19:01)

So if I don't have an NEC drive, can I enable C2 with a fair amount of confidence?

Not based solely on EAC's recommendation. EAC just tests whether a drive returns C2 info; it does not mean it does so accurately.

greynol

Jul 7 2006, 20:55

QUOTE(sumone @ Jul 7 2006, 12:51)

Why does it say 'copy ok' if the CRCs don't match? Is that what you're trying to point out?

No. I was pointing out that NEC drives will tell EAC everything's fine although it really isn't when C2 is checked. Martin pointed out that the particular NEC drive that I cited doesn't appear to perform as good as some of the newer ones when it comes to providing accurate C2 error information. Though I have to ask, is this the same program that spath was saying gave results that were untrustworthy?

The mismatching CRCs show for certainty that either the test or copy pass (if not both) was (were) in error. The fact that the quality level was 100% says that EAC was satisfied that the data was accurate based on its interpretation of the information given by the drive. Since the flushing routine was enabled we can rule audio caching as a possibility. What I didn't show was another log that gave matching CRCs and an accuraterip log showing that they were accurate but only after C2 was unchecked.

"Copy ok" only means that no suspicous positions were encountered. It does in no way mean that the rip was accurate; precise maybe (if C2 was disabled), but not accurate. With perfect C2 reporting, 100% quality would mean a track was accurate but clearly the NEC ND-3500AG does not deliver on this.

Martin H

Jul 7 2006, 22:38

QUOTE(greynol @ Jul 8 2006, 04:55)

Though I have to ask, is this the same program that spath was saying gave results that were untrustworthy?

Years ago, Pio2001 found two bugs in Analyzer.exe which he submitted to Andre which then got fixed. One of the bugs was that sync errors where mistaken for missed C2 pointers.

CU, Martin.

Keynes

Jul 8 2006, 13:00

QUOTE(Klyith @ Jul 7 2006, 13:50)

You should to check that your drive isn't set to PIO mode. (instructions)

I checked, and both devices were set to Ultra DMA, so I can only assume it used DMA rather than PIO.

QUOTE(Martin H @ Jul 7 2006, 21:19)

Check if your drive has been measured for C2 accuracy on cdrinfo.com first, and if it hasen't, then you can make the C2Extract test yourself, you just need to download Andre's DAEQuality archive on the EAC site and follow the included instructions. Also you can make some manuel tests with C2 on and off on lightly scratched CDs and compare CRCs.

I checked cdrinfo, but my drive manufacturer (Matshita / Panasonic) was not listed. The arts and crafts project might have to wait until later this week, since I've got a paper to write this weekend.

QUOTE(Cosmo @ Jul 7 2006, 21:21)

Every time a track is read for test or copying, CRCs are automatically generated and displayed in the GUI and log file. You don't need to enable.

You don't need to wait to convert to FLAC.

Awesome, thanks for the info. I noticed that EAC listed Read CRCs from when I had ripped the audio, so I went to Action --> Test Selected Tracks and generated Test CRCs. All of them matched. (Something went right!) So I guess from now on when I rip audio I just use Test & Copy Selected Tracks?

greynol

Jul 8 2006, 14:24

QUOTE(Keynes @ Jul 8 2006, 12:00)

So I guess from now on when I rip audio I just use Test & Copy Selected Tracks?

Usually a good idea*, IMO.

F5 = Copy
F8 = Test
F6 = Test & Copy
(shift + F5 or F6 will use whatever compression is configured)

The way I use EAC to save time and wear on the drive is detailed here.

My advice to anyone has been not to allow EAC to use C2 information unless you've verified that it works first. If you do use C2, unless your disc is in the accuraterip database, use Test & Copy. However, there are drives that will burn you if you use C2 even with Test & Copy so beware! If you see that EAC reported a suspicious position in an area where re-reads did not occur ("Error Correction" does not illuminate) it may be that C2 is not working properly.

*If you're using Secure mode without C2 when ripping and are getting 100% quality or 99.9% with re-reads occurring only at the very end of a track, testing the track will not yield a different CRC in the overwhelmingly vast majority of cases and can be considered a waste of time. If re-reads occur elswhere in the track, especially if more than one row lights up, I would recommend also testing the track.

Edit: I didn't see anyone explicitly tell you that it's alright to uncheck drive caches audio data since EAC says your drive does not cache. This will probably double your ripping speed in Secure mode. Those who are paranoid will tell you to check it anyway because EAC's test is supposedly not accurate, though the drives that have gotten people all up in arms over this cache less data than what EAC reads at a time. Anyhow use Feurio! or spath's new program if you are in doubt. If either says your drive caches less than 64kB or not at all, it's safe to uncheck the setting.

spoon

Jul 8 2006, 15:20

Are you sure EAC reads ~26 frames on the re-reads or the single frames?

greynol

Jul 8 2006, 16:02

QUOTE(spoon @ Jul 8 2006, 14:20)

Are you sure EAC reads ~26 frames on the re-reads or the single frames?

I'm not as sure as someone who can determine this by monitoring the commands going to a drive and the data coming back from it, but thanks to Martin H, I do have this link.

Keynes

Jul 8 2006, 16:19

QUOTE(greynol @ Jul 8 2006, 16:24)

QUOTE(Keynes @ Jul 8 2006, 12:00)

So I guess from now on when I rip audio I just use Test & Copy Selected Tracks?

Usually a good idea*, IMO.

F5 = Copy
F8 = Test
F6 = Test & Copy
(shift + F5 or F6 will use whatever compression is configured)

The way I use EAC to save time and wear on the drive is detailed here.

My advice to anyone has been not to allow EAC to use C2 information unless you've verified that it works first. If you do use C2, unless your disc is in the accuraterip database, use Test & Copy. However, there are drives that will burn you if you use C2 even with Test & Copy so beware! If you see that EAC reported a suspicious position in an area where re-reads did not occur ("Error Correction" does not illuminate) it may be that C2 is not working properly.

Thanks for the info! Good to know. By the way, my drive is listed in this accuraterip database, but it's only about offsets; maybe there's another one that I'm missing?

Also, in the post you linked to you said that, if the checksum wasn't in the accuraterip database, you would rip it again and compare checksums. Why not just use the Test feature to verify checksums rather than rip it all over again?

QUOTE(spoon @ Jul 8 2006, 17:20)

Are you sure EAC reads ~26 frames on the re-reads or the single frames?

I hope you're asking greynol and not me, because I'm afraid I can't answer your question. Sorry. Maybe the logs below will help?

So, I decided to run a few tests. I ran EAC in burst mode with CRC checking, then in secure mode, then in secure mode with C2 enabled. I made a mental note of the speed and such when I ran the test, but I thought it would be saved to the logs. Alas, it was not, so here's what I remember:

The burst mode completed in a little over 16 minutes, with all CRCs matching.

The secure mode with NO C2, accurate stream, NO disable cache took a couple minutes longer than the burst mode, which makes sense because it had to read twice but wasn't checking CRCs. Oddly enough, although this was the same ripping method that I ran before, I got a ripping speed that was a little under 4.0x (rather than the 1.9x that started this thread).

The secure mode with C2, accurate stream, NO disable cache was a bit faster than the other secure mode, of course, but I honestly can't recall any numbers for this one.

Here are the logs:

EDIT: Any way to enable the scrollbar on the code boxes so that they're smaller?

Burst mode with Test & Copy

CODE

EAC extraction logfile from 8. July 2006, 16:58 for CD
Radiohead / OK Computer

Used drive  : MATSHITADVD-RAM UJ-840S   Adapter: 0  ID: 0
Read mode   : Burst
Read offset correction : 102
Overread into Lead-In and Lead-Out : Yes

Used output format : C:\Program Files\FLAC\flac.exe   (User Defined Encoder)
					 128 kBit/s
					 Additional command line options : -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" -8 %s

Other options	  : 
	Fill up missing offset samples with silence : Yes
	Delete leading and trailing silent blocks : No
	Native Win32 interface for Win NT & 2000


Track  1
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(01) Airbag.wav

	 Peak level 98.5 %
	 Test CRC F9537CC4
	 Copy CRC F9537CC4
	 Copy OK

Track  2
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(02) Paranoid Android.wav

	 Peak level 98.7 %
	 Test CRC 2807C46F
	 Copy CRC 2807C46F
	 Copy OK

Track  3
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(03) Subterranean Homesick Alien.wav

	 Peak level 98.6 %
	 Test CRC 889CEC18
	 Copy CRC 889CEC18
	 Copy OK

Track  4
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(04) Exit Music (For A Film).wav

	 Peak level 98.4 %
	 Test CRC D3F8B115
	 Copy CRC D3F8B115
	 Copy OK

Track  5
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(05) Let Down.wav

	 Peak level 98.6 %
	 Test CRC 96379566
	 Copy CRC 96379566
	 Copy OK

Track  6
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(06) Karma Police.wav

	 Peak level 99.2 %
	 Test CRC F544E7F4
	 Copy CRC F544E7F4
	 Copy OK

Track  7
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(07) Fitter Happier.wav

	 Peak level 98.0 %
	 Test CRC 66772E6F
	 Copy CRC 66772E6F
	 Copy OK

Track  8
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(08) Electioneering.wav

	 Peak level 98.5 %
	 Test CRC 48BE730D
	 Copy CRC 48BE730D
	 Copy OK

Track  9
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(09) Climbing Up The Walls.wav

	 Peak level 98.5 %
	 Test CRC B7E538D0
	 Copy CRC B7E538D0
	 Copy OK

Track 10
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(10) No Surprises.wav

	 Peak level 98.7 %
	 Test CRC 67DC09B9
	 Copy CRC 67DC09B9
	 Copy OK

Track 11
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(11) Lucky.wav

	 Peak level 98.9 %
	 Test CRC 9F03412F
	 Copy CRC 9F03412F
	 Copy OK

Track 12
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(12) The Tourist.wav

	 Suspicious position 0:05:24

	 Peak level 98.8 %
	 Test CRC D132BA5A
	 Copy CRC D132BA5A
	 Copy finished

No errors occured

End of status report

Secure mode with NO C2, accurate stream, NO disable cache

CODE

EAC extraction logfile from 8. July 2006, 17:25 for CD
Radiohead / OK Computer

Used drive  : MATSHITADVD-RAM UJ-840S   Adapter: 0  ID: 0
Read mode   : Secure with NO C2, accurate stream, NO disable cache
Read offset correction : 102
Overread into Lead-In and Lead-Out : Yes

Used output format : C:\Program Files\FLAC\flac.exe   (User Defined Encoder)
					 128 kBit/s
					 Additional command line options : -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" -5 %s

Other options	  : 
	Fill up missing offset samples with silence : Yes
	Delete leading and trailing silent blocks : No
	Native Win32 interface for Win NT & 2000


Track  1
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(01) Airbag.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC F9537CC4
	 Copy OK

Track  2
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(02) Paranoid Android.wav

	 Peak level 98.7 %
	 Track quality 100.0 %
	 Copy CRC 2807C46F
	 Copy OK

Track  3
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(03) Subterranean Homesick Alien.wav

	 Peak level 98.6 %
	 Track quality 100.0 %
	 Copy CRC 889CEC18
	 Copy OK

Track  4
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(04) Exit Music (For A Film).wav

	 Peak level 98.4 %
	 Track quality 100.0 %
	 Copy CRC D3F8B115
	 Copy OK

Track  5
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(05) Let Down.wav

	 Peak level 98.6 %
	 Track quality 100.0 %
	 Copy CRC 96379566
	 Copy OK

Track  6
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(06) Karma Police.wav

	 Peak level 99.2 %
	 Track quality 99.9 %
	 Copy CRC F544E7F4
	 Copy OK

Track  7
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(07) Fitter Happier.wav

	 Peak level 98.0 %
	 Track quality 100.0 %
	 Copy CRC 66772E6F
	 Copy OK

Track  8
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(08) Electioneering.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC 48BE730D
	 Copy OK

Track  9
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(09) Climbing Up The Walls.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC B7E538D0
	 Copy OK

Track 10
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(10) No Surprises.wav

	 Peak level 98.7 %
	 Track quality 100.0 %
	 Copy CRC 67DC09B9
	 Copy OK

Track 11
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(11) Lucky.wav

	 Peak level 98.9 %
	 Track quality 99.9 %
	 Copy CRC 9F03412F
	 Copy OK

Track 12
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(12) The Tourist.wav

	 Peak level 98.8 %
	 Track quality 100.0 %
	 Copy CRC D132BA5A
	 Copy OK

No errors occured

End of status report

Secure mode with C2, accurate stream, NO disable cache

CODE

EAC extraction logfile from 8. July 2006, 17:40 for CD
Radiohead / OK Computer

Used drive  : MATSHITADVD-RAM UJ-840S   Adapter: 0  ID: 0
Read mode   : Secure with C2, accurate stream, NO disable cache
Read offset correction : 102
Overread into Lead-In and Lead-Out : Yes

Used output format : C:\Program Files\FLAC\flac.exe   (User Defined Encoder)
					 128 kBit/s
					 Additional command line options : -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" -5 %s

Other options	  : 
	Fill up missing offset samples with silence : Yes
	Delete leading and trailing silent blocks : No
	Native Win32 interface for Win NT & 2000


Track  1
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(01) Airbag.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC F9537CC4
	 Copy OK

Track  2
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(02) Paranoid Android.wav

	 Peak level 98.7 %
	 Track quality 100.0 %
	 Copy CRC 2807C46F
	 Copy OK

Track  3
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(03) Subterranean Homesick Alien.wav

	 Peak level 98.6 %
	 Track quality 100.0 %
	 Copy CRC 889CEC18
	 Copy OK

Track  4
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(04) Exit Music (For A Film).wav

	 Peak level 98.4 %
	 Track quality 100.0 %
	 Copy CRC D3F8B115
	 Copy OK

Track  5
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(05) Let Down.wav

	 Peak level 98.6 %
	 Track quality 99.9 %
	 Copy CRC 96379566
	 Copy OK

Track  6
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(06) Karma Police.wav

	 Peak level 99.2 %
	 Track quality 100.0 %
	 Copy CRC F544E7F4
	 Copy OK

Track  7
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(07) Fitter Happier.wav

	 Peak level 98.0 %
	 Track quality 100.0 %
	 Copy CRC 66772E6F
	 Copy OK

Track  8
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(08) Electioneering.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC 48BE730D
	 Copy OK

Track  9
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(09) Climbing Up The Walls.wav

	 Peak level 98.5 %
	 Track quality 100.0 %
	 Copy CRC B7E538D0
	 Copy OK

Track 10
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(10) No Surprises.wav

	 Peak level 98.7 %
	 Track quality 100.0 %
	 Copy CRC 67DC09B9
	 Copy OK

Track 11
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(11) Lucky.wav

	 Peak level 98.9 %
	 Track quality 100.0 %
	 Copy CRC 9F03412F
	 Copy OK

Track 12
	 Filename C:\Documents and Settings\Evan\My Documents\FLAC\Radiohead\OK Computer\(12) The Tourist.wav

	 Peak level 98.8 %
	 Track quality 100.0 %
	 Copy CRC D132BA5A
	 Copy OK

No errors occured

End of status report

greynol

Jul 8 2006, 16:55

QUOTE(Keynes @ Jul 8 2006, 15:19)

By the way, my drive is listed in this accuraterip database, but it's only about offsets; maybe there's another one that I'm missing?

The AccurateRip offset database is a good place to determine your offset without using the program but it doesn't tell you anything about drive features. There are some good links though I checked your drive and did not see it in any of them. Here are some that I use:
http://www.daefeatures.co.uk/search.php
http://users.pandora.be/satcp/eacoffsets01.htm
http://www.hydrogenaudio.org/forums/index....showtopic=32151

QUOTE(Keynes @ Jul 8 2006, 15:19)

Also, in the post you linked to you said that, if the checksum wasn't in the accuraterip database, you would rip it again and compare checksums. Why not just use the Test feature to verify checksums rather than rip it all over again?

The test feature (F8) is what I meant. I considered mentioning this at the time but thought it might get too tedious.

QUOTE(Keynes @ Jul 8 2006, 15:19)

The secure mode with NO C2, accurate stream, NO disable cache took a couple minutes longer than the burst mode, which makes sense because it had to read twice but wasn't checking CRCs. Oddly enough, although this was the same ripping method that I ran before, I got a ripping speed that was a little under 4.0x (rather than the 1.9x that started this thread).

This is because you disabled EAC's flushing routine by unchecking "Drive caches audio data". This setting slows down the process because it requests extra data that is only used to clear out what may get cached.

QUOTE(Keynes @ Jul 8 2006, 15:19)

The secure mode with C2, accurate stream, NO disable cache was a bit faster than the other secure mode, of course, but I honestly can't recall any numbers for this one.

Probably comparable to the numbers you got with Burst mode.

QUOTE(Keynes @ Jul 8 2006, 15:19)

Any way to enable the scrollbar on the code boxes so that they're smaller?

Instead of "code" between the brackets, use "codebox".

Keynes

Jul 8 2006, 18:06

QUOTE(greynol @ Jul 8 2006, 18:55)

The AccurateRip offset database is a good place to determine your offset without using the program but it doesn't tell you anything about drive features. There are some good links though I checked your drive and did not see it in any of them. Here are some that I use:
http://www.daefeatures.co.uk/search.php
http://users.pandora.be/satcp/eacoffsets01.htm
http://www.hydrogenaudio.org/forums/index....showtopic=32151

Yeah, I checked the first two databases and didn't find my drive. I did manage to find some info about it here.

QUOTE(greynol @ Jul 8 2006, 18:55)

QUOTE(Keynes @ Jul 8 2006, 15:19)

The secure mode with NO C2, accurate stream, NO disable cache took a couple minutes longer than the burst mode, which makes sense because it had to read twice but wasn't checking CRCs. Oddly enough, although this was the same ripping method that I ran before, I got a ripping speed that was a little under 4.0x (rather than the 1.9x that started this thread).

This is because you disabled EAC's flushing routine by unchecking "Drive caches audio data". This setting slows down the process because it requests extra data that is only used to clear out what may get cached.

Well, actually, I had the flushing routine disabled the first time, as well...

QUOTE(greynol @ Jul 8 2006, 18:55)

Instead of "code" between the brackets, use "codebox".

You're a life-saver.

Keynes

Jul 8 2006, 19:11

Bad news.

I was ripping a Beatles CD using Burst mode and all went well (~60 confims with AccurateRip) except for track 6. So I did a test & copy rip using secure mode on track 6 -- but, unfortunately, not only do my own checksums not match, AccurateRip is reporting a failure as well (with a confidence of 16).

Ideas?

Martin H

Jul 8 2006, 20:43

QUOTE(spoon @ Jul 8 2006, 23:20)

Are you sure EAC reads ~26 frames on the re-reads or the single frames?

There are also some detailed info from Andre here :

http://www.digital-inn.de/exact-audio-copy...rtin+sync+error

liekloo

Jul 14 2006, 09:57

QUOTE(greynol @ Jul 8 2006, 21:24)

there are drives that will burn you if you use C2 even with Test & Copy so beware!

Could you provide more information about this - an example, a link, anything that could help to valide/understand your observation?

This observation could be very relevant.
I've always assumed that the failure you describe cannot happen more than occasionally (i.e. in the case of a 'consistent' error). Hence I've presented C2 + test & copy as a safe ripping method in the Essential Ripping Guide... (including my motivation)

dbAmp

Jul 14 2006, 11:03

QUOTE(Keynes @ Jul 7 2006, 08:04)

I just ripped my first CD with EAC using Secure mode (Accurate Stream enabled, caching and retreiving C2 info disabled); the average speed for the album was 1.9x. Is this normal?

What chipset does your motherboard use and which IDE drivers do you use?

I have an nForce2 mobo... I got about 2x when I used the nvidia IDE drivers (that even in the most recent version were said to cause problems)... and about 10x when I switched back to the microsoft default.

greynol

Jul 14 2006, 11:44

QUOTE(liekloo @ Jul 14 2006, 08:57)

QUOTE(greynol @ Jul 8 2006, 21:24)

there are drives that will burn you if you use C2 even with Test & Copy so beware!

Could you provide more information about this - an example, a link, anything that could help to valide/understand your observation?

This observation could be very relevant.
I've always assumed that the failure you describe cannot happen more than occasionally (i.e. in the case of a 'consistent' error). Hence I've presented C2 + test & copy as a safe ripping method in the Essential Ripping Guide... (including my motivation)

The drive came up in EAC as "DVDRW IDE1004". The error manifested itself as the same sample repeated many times and was audible.

This happened with two tracks from the same disc, luckily the log indicated a suspicious position with one of them (but not the other). It wasn't my rip but I worked closely with the person and was able to resolve the problem (by unchecking C2!).

I once thought that T&C w/C2 was safe until I saw this.

CODE

Used drive  : DVDRW   IDE1004   Adapter: 1  ID: 1
Read mode   : Secure with C2, accurate stream, NO disable cache

Track  3
     Suspicious position 0:00:13

     Peak level 100.0 %
     Track quality 99.5 %
     Test CRC 5644A28A
     Copy CRC 5644A28A
     Copy finished

Track  4
     Peak level 100.0 %
     Track quality 99.6 %
     Test CRC 66C2B591
     Copy CRC 66C2B591
     Copy OK

There were errors
------------------------------------------------------------
Used drive  : DVDRW   IDE1004   Adapter: 1  ID: 1
Read mode   : Secure with NO C2, accurate stream, NO disable cache

Track  3
     Peak level 100.0 %
     Track quality 100.0 %
     Test CRC 7DB07FD6
     Copy CRC 7DB07FD6
     Copy OK

Track  4
     Peak level 100.0 %
     Track quality 99.9 %
     Test CRC 775453B2
     Copy CRC 775453B2
     Copy OK

No errors occured

liekloo

Jul 14 2006, 14:40

Thanks greynol!

QUOTE

I once thought that T&C w/C2 was safe until I saw this.

Same thing here (until that post of yours, above). Still I hope there is an alternative explanation that fits within our understanding of DAE (the understanding that says that C2 + T&C should be safe).

2 misread tracks on the same CD is indeed concerning. The chance that this is a coincidence is very small indeed.

(unless the drive didn't just badly support C2 but didn't support it AT ALL; should that be the case then the matching CRCs may be explained in terms of consistent errors in both tracks)

There is one thing I don't understand though (and which you might be able to shed light on): The suspicious positions I've encountered so far all came from either read or sync errors, which are incompatible with a "copy OK" line in the logfile. So basically I don't know what to think of track 3 (suspicious position yet "copy OK")
(I ask this question because it could be relevant for figuring out whether or not C2 + T&C should indeed be considered unsafe).

P.S. Any chance it was a copy-protected CD?

greynol

Jul 14 2006, 14:47

QUOTE(liekloo @ Jul 14 2006, 13:40)

Any chance it was a copy-protected CD?

It was an MFSL SACD Ultradisc UHR from 2005.

The rest of the tracks gave EAC no troubles (re-reads weren't necessary).

greynol

Jul 14 2006, 17:02

I saw you added more information to the post that I answered so I thought I'd address more of it here.

QUOTE

(unless the drive didn't just badly support C2 but didn't support it AT ALL; should that be the case then the matching CRCs may be explained in terms of consistent errors in both tracks)

Again this wasn't my rip and I do not own this drive but I think it's fair to assume that EAC detected C2 for the drive. When I check C2 with drives that don't support it I immediately get an error, though this doesn't mean that it will hold true for all drives that don't report C2.

QUOTE

There is one thing I don't understand though (and which you might be able to shed light on):
...
I don't know what to think of track 3 (suspicious position yet "copy OK")

This is what tipped me off that something peculiar was going on. It is also why I suggested to pay attention to a suspicious position where no re-reads occur though I am not sure that re-reads didn't actually occur where the suspicious position was. I should ammend my statement to a suspicious position coupled with "Copy OK"

QUOTE

(I ask this question because it could be relevant for figuring out whether or not C2 + T&C should indeed be considered unsafe).

This could simply be the case of a very poor implementation of C2 (at least as far as using it with EAC is concerned). I do not believe that this was the case of a consistent error, rather I believe the drive repeated a sample in place of those it could not read as a pathetic means of error correction. The rest of the data (before and after the repeated sample) was fine. I no longer have the files though I wish I had kept them.

I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read. The drive does not do this in the regular Secure mode with or without C2.

Whatever is going on, I don't consider C2 + T&C as safe for all drives. This experience has shown me otherwise. However, I still use C2 + T&C with my Plextor and Sony drives.

liekloo

Jul 15 2006, 13:54

QUOTE(greynol @ Jul 15 2006, 00:02)

I saw you added more information to the post that I answered so I thought I'd address more of it here.

I hadn't noticed your reply at all, and hence felt so free to edit. My apologies.

QUOTE(greynol)

QUOTE(liekloo)

There is one thing I don't understand though (and which you might be able to shed light on) [...] I don't know what to think of track 3 (suspicious position yet "copy OK")

This is what tipped me off that something peculiar was going on. It is also why I suggested to pay attention to a suspicious position where no re-reads occur though I am not sure that re-reads didn't actually occur where the suspicious position was. I should ammend my statement to a suspicious position coupled with "Copy OK"

My problem is that I don't know how "suspicious position" and "Copy OK" can occur together. Any idea what triggers EAC to write "suspicious position" (EDIT: in secure, not burst, mode), except for read/sync errors?

QUOTE(greynol)

QUOTE(liekloo)

(I ask this question because it could be relevant for figuring out whether or not C2 + T&C should indeed be considered unsafe).

This could simply be the case of a very poor implementation of C2 (at least as far as using it with EAC is concerned). I do not believe that this was the case of a consistent error, rather I believe the drive repeated a sample in place of those it could not read as a pathetic means of error correction. The rest of the data (before and after the repeated sample) was fine. I no longer have the files though I wish I had kept them.

Np, it sounds credible. However when I said "consistent error" I was in fact referring to the drive's output (i.e. after its built-in error correction), which may contain errors that are consistent across multiple reads (and it seems credible that may be what has happened with track 3).

QUOTE(greynol)

I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read. The drive does not do this in the regular Secure mode with or without C2.

BTW - this reminds me of one of my ex-drives: it couldn't overread, and when overreading was forced thru EAC the extracted audio would miss its few last samples and had 2 extra seconds of silence appended.

QUOTE(greynol)

QUOTE(liekloo)

(unless the drive didn't just badly support C2 but didn't support it AT ALL; should that be the case then the matching CRCs may be explained in terms of consistent errors in both tracks)

Again this wasn't my rip and I do not own this drive but I think it's fair to assume that EAC detected C2 for the drive. When I check C2 with drives that don't support it I immediately get an error, though this doesn't mean that it will hold true for all drives that don't report C2.

(I assumed the opposite, but it's pure speculation as well.)

Good news: according to Feurio's database, the drive in question does not support C2. Seems like my wishful thinking has come true.

This means that consistent errors may account for the matching CRCs (it's not uncommon that several tracks on the same CD suffer from consistent errors) and C2 + T&C might be ok after all (though it's a bit early to conclude, as long as I don't understand the "suspicous position" thing).

greynol

Jul 15 2006, 14:49

QUOTE(liekloo)

Good news: according to Feurio's database, the drive in question does not support C2. Seems like my wishful thinking has come true.

This means that consistent errors may account for the matching CRCs (it's not uncommon that several tracks on the same CD suffer from consistent errors). The thesis that C2 + T&C would be unsafe, would mean there is something seriously wrong with our understanding of DAE (insufficient proof in this case imho, though we should keep our eyes wide open).

Not so fast!

Remember, EAC was used to extract the data, not Feurio. Is it possible that EAC said the drive was capable of providing C2 error information? Also, the thesis here is that C2 + T&C is not safe for all drives when using EAC. I still don't believe it is.

We already know that C2 without T&C is not safe for all drives. Now the question is whether a drive is capable of spitting out a consistent error without re-reads being performed based on EAC's interpretation of the C2 information provided by the drive and whether the same consistent error would have been made had EAC been given the opportunity to read the data at least twice.

QUOTE(liekloo)

My problem is that I don't know how "suspicious position" and "Copy OK" can occur together. Any idea what triggers EAC to write "suspicious position" (EDIT: in secure, not burst, mode), except for read/sync errors?

I haven't a clue.

QUOTE(liekloo)

However when I said "consistent error" I was in fact referring to the drive's output (i.e. after its built-in error correction), which may contain errors that are consistent across multiple reads (and it seems credible that may be what has happened with track 3).

Gotcha!

QUOTE(greynol)

I've seen a similar result using EAC's Paranoid mode with my Sony 52X drive: repeated samples in place of data it seemingly could not read. The drive does not do this in the regular Secure mode with or without C2.

QUOTE(liekloo)

That reminds me of one of my ex-drives: it couldn't overread, and when overreading was forced thru EAC the extracted audio would miss its few last samples and had 2 extra seconds of silence appended.

This was in the middle of a track where EAC had the drive perform re-reads using Paranoid mode. I have never seen this drive repeat a sample when giving erroneous data in any other mode.