EAC: 1 track cannot be verified as accurate Options

[NoiseAround]

Hi everybody,
I'm ripping my music collection lately, and I've come across a problem with one of my CDs.

I ripped the CD once, and every track was accurate except for track 11:

CODE

Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 25. September 2011, 10:55

The Dillinger Escape Plan / Ire Works

Used drive : TSSTcorpCDDVDW SH-S223C Adapter: 0 ID: 1

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 697
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 320 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files (x86)\Exact Audio Copy\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "PERFORMER=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 2:41.53 | 0 | 12127
2 | 2:41.53 | 2:03.19 | 12128 | 21371
3 | 4:44.72 | 4:04.17 | 21372 | 39688
4 | 8:49.14 | 2:10.06 | 39689 | 49444
5 | 10:59.20 | 1:23.02 | 49445 | 55671
6 | 12:22.22 | 1:16.10 | 55672 | 61381
7 | 13:38.32 | 1:33.24 | 61382 | 68380
8 | 15:11.56 | 1:56.44 | 68381 | 77124
9 | 17:08.25 | 3:55.20 | 77125 | 94769
10 | 21:03.45 | 1:56.70 | 94770 | 103539
11 | 23:00.40 | 5:29.01 | 103540 | 128215
12 | 28:29.41 | 3:11.06 | 128216 | 142546
13 | 31:40.47 | 6:49.62 | 142547 | 173283


Track 1

Filename H:\[2007] Ire Works\01 - Fix Your Face.wav

Pre-gap length 0:00:02.00

Peak level 98.9 %
Extraction speed 1.9 X
Track quality 100.0 %
Test CRC 2E991AAD
Copy CRC 2E991AAD
Accurately ripped (confidence 2) [7E1376A1] (AR v2)
Copy OK

Track 2

Filename H:\[2007] Ire Works\02 - Lurch.wav

Peak level 98.9 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC 4B368AA1
Copy CRC 4B368AA1
Accurately ripped (confidence 2) [D5E6EA6B] (AR v2)
Copy OK

Track 3

Filename H:\[2007] Ire Works\03 - Black Bubblegum.wav

Peak level 100.0 %
Extraction speed 2.1 X
Track quality 100.0 %
Test CRC 772AB5D2
Copy CRC 772AB5D2
Accurately ripped (confidence 2) [D817709B] (AR v2)
Copy OK

Track 4

Filename H:\[2007] Ire Works\04 - Sick on Sunday.wav

Peak level 98.9 %
Extraction speed 1.9 X
Track quality 100.0 %
Test CRC 9F973542
Copy CRC 9F973542
Accurately ripped (confidence 2) [DF88A5C6] (AR v2)
Copy OK

Track 5

Filename H:\[2007] Ire Works\05 - When Acting as a Particle.wav

Peak level 98.9 %
Extraction speed 1.6 X
Track quality 100.0 %
Test CRC B535A160
Copy CRC B535A160
Accurately ripped (confidence 2) [D164B0FE] (AR v2)
Copy OK

Track 6

Filename H:\[2007] Ire Works\06 - Nong Eye Gong.wav

Peak level 100.0 %
Extraction speed 1.6 X
Track quality 100.0 %
Test CRC 2E0EEE88
Copy CRC 2E0EEE88
Accurately ripped (confidence 2) [BB7FDF3E] (AR v2)
Copy OK

Track 7

Filename H:\[2007] Ire Works\07 - When Acting as a Wave.wav

Peak level 99.2 %
Extraction speed 1.3 X
Track quality 99.8 %
Test CRC 559ABBEB
Copy CRC 559ABBEB
Accurately ripped (confidence 2) [FF0E245B] (AR v2)
Copy OK

Track 8

Filename H:\[2007] Ire Works\08 - 82588.wav

Peak level 100.0 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC F91403FD
Copy CRC F91403FD
Accurately ripped (confidence 2) [F0DA64D4] (AR v2)
Copy OK

Track 9

Filename H:\[2007] Ire Works\09 - Milk Lizard.wav

Peak level 98.9 %
Extraction speed 2.1 X
Track quality 100.0 %
Test CRC 411584F4
Copy CRC 411584F4
Accurately ripped (confidence 2) [8041BB1A] (AR v2)
Copy OK

Track 10

Filename H:\[2007] Ire Works\10 - Party Smasher.wav

Peak level 99.0 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC C60F0A60
Copy CRC C60F0A60
Accurately ripped (confidence 2) [3A465214] (AR v2)
Copy OK

Track 11

Filename H:\[2007] Ire Works\11 - Dead as History.wav

Peak level 100.0 %
Extraction speed 1.8 X
Track quality 99.9 %
Test CRC 2ABD425D
Copy CRC 2ABD425D
Cannot be verified as accurate (confidence 67) [D6483112], AccurateRip returned [74077051] (AR v2)
Copy OK

Track 12

Filename H:\[2007] Ire Works\12 - Horse Hunter.wav

Peak level 99.0 %
Extraction speed 2.0 X
Track quality 100.0 %
Test CRC A07AE18B
Copy CRC A07AE18B
Accurately ripped (confidence 2) [531F95E1] (AR v2)
Copy OK

Track 13

Filename H:\[2007] Ire Works\13 - Mouth of Ghosts.wav

Peak level 100.0 %
Extraction speed 2.2 X
Track quality 100.0 %
Test CRC 7B7AA959
Copy CRC 7B7AA959
Accurately ripped (confidence 2) [DBA25474] (AR v2)
Copy OK


12 track(s) accurately ripped
1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

No errors occurred

End of status report

==== Log checksum 586D2C69220CA61BFB3D3DE17AF375C615F77B763BE6390EB7F40F802F006746 ====[/quote]

I ripped the CD again, and track 11 came back with different CRC values:

[code]Track 11

Filename H:\[2007] Ire Works\11 - Dead as History.wav

Peak level 100.0 %
Extraction speed 2.0 X
Track quality 99.9 %
Test CRC C59D15B5
Copy CRC C59D15B5
Cannot be verified as accurate (confidence 67) [9FD6E2DC], AccurateRip returned [74077051] (AR v2)
Copy OK

I tried a THIRD time (ripping only track 11 this time), and this time track 11 had two different CRC values.

Then on the forth time, I got the same CRC value (for test and copy) as the first rip for track 11.

I did happen to to rip this cd a couple of years ago, and I think the CRC values for track 11 were the accurate ones (I've compared online). So this is the correct pressing, and it worked at some point. I have formatted since, using a new version of EAC, and a different PC (new hardware including dvd-drive).

Now, my CDs are kept in good condition I would think. There are no scratches, and no fingerprints. I only ever really use the CD to rip... do cds ever just, turn bad? I don't have a second drive I can try ripping on. Anything else I can try?

This post has been edited by db1989: Sep 25 2011, 11:18

Reason for edit: Please paste large items within [codebox] tags, not [quote] (or [code])

[spoon]

Manufacturing defects

[NoiseAround]

Do manufacturing defects show up years down the line? I've ripped this CD before and I think I had the right CRC at the time:

…
Filename H:\[2007] Ire Works\11 - Dead As History.wav

Peak level 100.0 %
Track quality 100.0 %
Test CRC 86FE0E87
Copy CRC 86FE0E87
Copy OK

And here is somebody else's log:

Track 11

Filename C:\FLAC RIPS\Dillinger Escape Plan - 2007 - Ire Works\11 - Dead As History.wav

Pre-gap length 0:00:00.01

Peak level 100.0 %
Track quality 99.9 %
Test CRC 86FE0E87
Copy CRC 86FE0E87
Accurately ripped (confidence 26) [74077051]
Copy OK

So I had the correct CRC two years ago...

This post has been edited by db1989: Sep 25 2011, 11:19

Reason for edit: truncating first log to relevant part only

[greynol]

So I had the correct CRC two years ago...

Maybe, maybe not.

Manufacturing defects can cause consistent errors between different discs ripped with drives using the same or similar chipsets.

[NoiseAround]

I don't think I quite understand...
Are you saying that the other log (from the third party) could have a manufacturing defect with a similar chipset drive, resulting in the same CRC as mine?
Because their log does have a confidence of 26...

Thanks for the help/replies guys. This was part of the reason I always back up my music, incase one goes bad... but now that one is actually bad I feel like I need to buy it again. Gahhh it's a vicious cycle.

[greynol]

Are you saying that the other log (from the third party) could have a manufacturing defect with a similar chipset drive, resulting in the same CRC as mine?
Because their log does have a confidence of 26...

It is not beyond the realm of possibility.

but now that one is actually bad I feel like I need to buy it again. Gahhh it's a vicious cycle.

Have you tried fixing it with CUETools?

[NoiseAround]

I tried ripping the CD again with CTDB add-on for EAC (I tried using CUERipper first but it kept locking up my computer):

Here is the log I got back:

CODE

Exact Audio Copy V1.0 beta 2 from 29. April 2011

EAC extraction logfile from 26. September 2011, 11:00

The Dillinger Escape Plan / Ire Works

Used drive : TSSTcorpCDDVDW SH-S223C Adapter: 0 ID: 1

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : Yes
Make use of C2 pointers : No

Read offset correction : 697
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : Yes
Used interface : Native Win32 interface for Win NT & 2000
Gap handling : Appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 320 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files (x86)\Exact Audio Copy\Flac\flac.exe
Additional command line options : -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "PERFORMER=%albuminterpret%" -T "COMPOSER=%composer%" %haslyrics%--tag-from-file=LYRICS


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 2:41.53 | 0 | 12127
2 | 2:41.53 | 2:03.19 | 12128 | 21371
3 | 4:44.72 | 4:04.17 | 21372 | 39688
4 | 8:49.14 | 2:10.06 | 39689 | 49444
5 | 10:59.20 | 1:23.02 | 49445 | 55671
6 | 12:22.22 | 1:16.10 | 55672 | 61381
7 | 13:38.32 | 1:33.24 | 61382 | 68380
8 | 15:11.56 | 1:56.44 | 68381 | 77124
9 | 17:08.25 | 3:55.20 | 77125 | 94769
10 | 21:03.45 | 1:56.70 | 94770 | 103539
11 | 23:00.40 | 5:29.01 | 103540 | 128215
12 | 28:29.41 | 3:11.06 | 128216 | 142546
13 | 31:40.47 | 6:49.62 | 142547 | 173283


Track 1

Filename H:\[2007] Ire Works\01 - Fix Your Face.wav

Pre-gap length 0:00:02.00

Peak level 98.9 %
Extraction speed 1.9 X
Track quality 100.0 %
Test CRC 2E991AAD
Copy CRC 2E991AAD
Accurately ripped (confidence 2) [7E1376A1] (AR v2)
Copy OK

Track 2

Filename H:\[2007] Ire Works\02 - Lurch.wav

Peak level 98.9 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC 4B368AA1
Copy CRC 4B368AA1
Accurately ripped (confidence 2) [D5E6EA6B] (AR v2)
Copy OK

Track 3

Filename H:\[2007] Ire Works\03 - Black Bubblegum.wav

Peak level 100.0 %
Extraction speed 2.1 X
Track quality 100.0 %
Test CRC 772AB5D2
Copy CRC 772AB5D2
Accurately ripped (confidence 2) [D817709B] (AR v2)
Copy OK

Track 4

Filename H:\[2007] Ire Works\04 - Sick on Sunday.wav

Peak level 98.9 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC 9F973542
Copy CRC 9F973542
Accurately ripped (confidence 2) [DF88A5C6] (AR v2)
Copy OK

Track 5

Filename H:\[2007] Ire Works\05 - When Acting as a Particle.wav

Peak level 98.9 %
Extraction speed 1.6 X
Track quality 100.0 %
Test CRC B535A160
Copy CRC B535A160
Accurately ripped (confidence 2) [D164B0FE] (AR v2)
Copy OK

Track 6

Filename H:\[2007] Ire Works\06 - Nong Eye Gong.wav

Peak level 100.0 %
Extraction speed 1.6 X
Track quality 100.0 %
Test CRC 2E0EEE88
Copy CRC 2E0EEE88
Accurately ripped (confidence 2) [BB7FDF3E] (AR v2)
Copy OK

Track 7

Filename H:\[2007] Ire Works\07 - When Acting as a Wave.wav

Peak level 99.2 %
Extraction speed 1.3 X
Track quality 99.8 %
Test CRC 559ABBEB
Copy CRC 559ABBEB
Accurately ripped (confidence 2) [FF0E245B] (AR v2)
Copy OK

Track 8

Filename H:\[2007] Ire Works\08 - 82588.wav

Peak level 100.0 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC F91403FD
Copy CRC F91403FD
Accurately ripped (confidence 2) [F0DA64D4] (AR v2)
Copy OK

Track 9

Filename H:\[2007] Ire Works\09 - Milk Lizard.wav

Peak level 98.9 %
Extraction speed 2.1 X
Track quality 100.0 %
Test CRC 411584F4
Copy CRC 411584F4
Accurately ripped (confidence 2) [8041BB1A] (AR v2)
Copy OK

Track 10

Filename H:\[2007] Ire Works\10 - Party Smasher.wav

Peak level 99.0 %
Extraction speed 1.8 X
Track quality 100.0 %
Test CRC C60F0A60
Copy CRC C60F0A60
Accurately ripped (confidence 2) [3A465214] (AR v2)
Copy OK

Track 11

Filename H:\[2007] Ire Works\11 - Dead as History.wav

Peak level 100.0 %
Extraction speed 1.9 X
Track quality 99.9 %
Test CRC 2ABD425D
Copy CRC 86FE0E87
Accurately ripped (confidence 2) [23E5F32E] (AR v2)
Copy OK

Track 12

Filename H:\[2007] Ire Works\12 - Horse Hunter.wav

Peak level 99.0 %
Extraction speed 2.0 X
Track quality 100.0 %
Test CRC A07AE18B
Copy CRC A07AE18B
Accurately ripped (confidence 2) [531F95E1] (AR v2)
Copy OK

Track 13

Filename H:\[2007] Ire Works\13 - Mouth of Ghosts.wav

Peak level 100.0 %
Extraction speed 2.2 X
Track quality 100.0 %
Test CRC 7B7AA959
Copy CRC 7B7AA959
Accurately ripped (confidence 2) [DBA25474] (AR v2)
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: yN_FAFLUqczq_cPaejsg82PLMuU-] found, Submit result: yN_FAFLUqczq_cPaejsg82PLMuU- has been confirmed
[0cf488ed] (66/66) Accurately ripped


==== Log checksum 75610B934C7BCDC4D9545203CEB6224E844039ED7F69F7AC5D8E7BB8C193E35A ====

Could you explain to me what just happened? Track 11 has a different test and copy CRC but now says it has been accurately ripped? The CUETools segment at the end of the log doesn't really explain much. Did CTDB fix it?

Edit: I just checked the other logs, and the track 11 Copy CRC 86FE0E87 is the actual CRC according to other logs and the accuraterip database. So... I don't know how to interpret this log. Can I assume that the file came out correctly if it has the correct Copy CRC?

This post has been edited by NoiseAround: Sep 26 2011, 02:47

[greynol]

The Copy CRC is the CRC for the track as it was written to your hard drive.

Did CTDB fix it? It doesn't appear as though it did.

This post has been edited by greynol: Sep 26 2011, 03:57

[Gregory S. Chudo...]

EAC plugin currently cannot fix anything, it only detects errors and also helps others fix their CDs by submitting your successful rips. You just got lucky, and your last rip is without errors.

Adding repair function to CTDB plugin goes far beyond current plugin interface, because for that plugin needs to process the rip results after the whole CD has been ripped, and that would require either to delay the compression until the end of the disc, or implementing flac decoding support in EAC (the latter approach also wouldn't work with lossy compression). So we are stuck with using external application for repairs.

[mjb2006]

Thanks for updating your last post. The CTDB plug-in's log says that the whole-disc checksum matches 66 others in the database:

CODE

CTDB TOCID: yN_FAFLUqczq_cPaejsg82PLMuU-] found, Submit result: yN_FAFLUqczq_cPaejsg82PLMuU- has been confirmed
[0cf488ed] (66/66) Accurately ripped

...which is as it should be, since for that particular rip, you did luck out and get the 86FE0E87 Copy CRC on track 11, just like you recall getting originally, and just like everyone else has been getting. So in that particular case, you got a good rip.

The CTDB plug-in for EAC can't fix anything. It only works like AccurateRip right now, checking against its database of whole-disc checksums, and submitting the checksum & error correction data if the pressing is new to the database. To repair a rip, you must process it with CUETools, with Encode checked and the 'repair' script selected; if the pressing exists in CTDB, and your checksum doesn't match, then the output will (hopefully) be a repaired copy of the audio, in whatever format you had selected to encode to.

Running the repair script on your good rip will result in nothing happening. It won't fix what isn't broken.

Yes, manufacturing defects can show up years down the line. I have a CD manufactured by Nimbus c. 1986 that used to rip fine and that I never play, but that is now unreadable at the outermost track, even though there's no visible damage to it whatsoever.

[greynol]

Of the (assumed) manufacturing defect cases I've studied (of which there weren't all that many), they were pressing-specific. If I was able to verify my rip against an alternate pressing, which appears to be true in this case, then I would feel pretty comfortable about the result.

Thanks for the clarification about the CTDB plugin.

This post has been edited by greynol: Sep 26 2011, 04:06

[NoiseAround]

Ok, thanks for all the replies everybody. Really helpful, and just getting to learn about CUETools was great.

I had a better look at the back of the CD and noticed a spot underneath the plastic layer where the shiny surface seemed to have a subtle round blot, almost a little milky in colour, but still shiny. Impossible to take a picture of. It wasn't a smudge or a scrath, so it definitely looks like some sort of manufacturing defect. It's possible that it always had this defect but my other drive was perhaps of better quality and didn't have trouble reading it. Mostly I was just worried that it might have been the way I was storing my cds or maybe even the summer heat. I have some rare and oop cds that would be a shame to lose. But that doesn't seem to be the case.

[greynol]

That doesn't sound like it's necessarily a manufacturing defect that would be consistent across an entire pressing.

[Goratrix]

I've had a case of a manufacturing defect (weird barely visible smudges) on a brand new unscratched CD that made ripping two tracks impossible. And I know for sure it was a manufacturing defect as I bought a second brand new sealed copy and it had the same (although it produced different errors). The disc was the bonus disc to New Model Army - Thunder And Consolation limited edition. I still have both copies, tried them with two different drives, no success.

[alondon]

Ok, thanks for all the replies everybody. Really helpful, and just getting to learn about CUETools was great.

I had a better look at the back of the CD and noticed a spot underneath the plastic layer where the shiny surface seemed to have a subtle round blot, almost a little milky in colour, but still shiny. Impossible to take a picture of. It wasn't a smudge or a scrath, so it definitely looks like some sort of manufacturing defect. It's possible that it always had this defect but my other drive was perhaps of better quality and didn't have trouble reading it. Mostly I was just worried that it might have been the way I was storing my cds or maybe even the summer heat. I have some rare and oop cds that would be a shame to lose. But that doesn't seem to be the case.

Aluminum oxide (aka Disc Rot) can also create the complete scenario you describe.

[stephan_g]

It's possible that it always had this defect but my other drive was perhaps of better quality and didn't have trouble reading it.

That's the most likely explanation right there. Do not underestimate the differences in CD reading ability. I've had cases where my LG GSA-H42N (not a bad CD reader at all and fairly immune to scratches and such) would chew on a disc for ages and still fail to produce accurate rips on some tracks, but an age old Ricoh CD burner would chug through the same one just fine. Your drive appears to be quite slow, too.