Hi.

I ripped the same track three times using EAC in burst mode, until I got a CRC match at AccurateRip. If you look at the edited extract of the log below, I got the same copy CRC value each time, but only on the third attempt did I get an AccurateRip match.

This looks to me as though AR gave me two false negatives, until finally giving the correct result third time around.

What's going on?

Thanks!


Track 5

Filename F:\EAC\R.E.M\Document [Expanded]\05. Strange - R.E.M..wav

Timing problem 0:00:56

Peak level 97.7 %
Copy CRC F6192220
Cannot be verified as accurate (confidence 37) [35EB0B95], AccurateRip returned [18208F5D]
Copy finished

Track 5

Filename F:\EAC\R.E.M\Document [Expanded]\05. Strange - R.E.M..wav

Peak level 97.7 %
Copy CRC F6192220
Cannot be verified as accurate (confidence 37) [35EB0B95], AccurateRip returned [18208F5D]
Copy OK

Track 5

Filename F:\EAC\R.E.M\Document [Expanded]\05. Strange - R.E.M..wav

Timing problem 0:02:19

Peak level 97.7 %
Copy CRC F6192220
Accurately ripped (confidence 37) [18208F5D]
Copy finished

Please include the header with your log files.

>Cannot be verified as accurate (confidence 37) [35EB0B95],
> Accurately ripped (confidence 37) [18208F5D]

Different CRCs were checked against AccurateRip, EAC by default does not use NULL samples for CRC calculations, so if an error was on a NULL sample EAC would not report it.

But if there was an error an a NULL sample, it wouldn't be a NULL sample anymore, right?

If data was shifted within a window of null samples or silence was added or taken away, the CRC would still be the same.

Sorry for the delay, I've been away from my PC.

Here's the header:

Exact Audio Copy V0.99 prebeta 3 from 28. July 2007

EAC extraction logfile from 29. September 2007, 20:00

R.E.M. / Document [Expanded]

Used drive : _NEC DVD_RW ND-3550A Adapter: 1 ID: 1

Read mode : Burst

Read offset correction : 48
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 : No
Used interface : Installed external ASPI interface
Gap handling : Not detected, thus appended to previous track

Used output format : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : Yes
Command line compressor : C:\Program Files\Exact Audio Copy\flac.exe
Additional command line options : -V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.33 | 3:50.60 | 33 | 17342
2 | 3:51.18 | 2:48.62 | 17343 | 30004
3 | 6:40.05 | 3:21.45 | 30005 | 45124
4 | 10:01.50 | 3:34.08 | 45125 | 61182
5 | 13:35.58 | 2:33.17 | 61183 | 72674
6 | 16:09.00 | 4:06.73 | 72675 | 91197
7 | 20:15.73 | 3:17.55 | 91198 | 106027
8 | 23:33.53 | 3:24.52 | 106028 | 121379
9 | 26:58.30 | 3:21.23 | 121380 | 136477
10 | 30:19.53 | 4:10.27 | 136478 | 155254
11 | 34:30.05 | 5:22.30 | 155255 | 179434
12 | 39:52.35 | 3:47.08 | 179435 | 196467
13 | 43:39.43 | 2:16.57 | 196468 | 206724
14 | 45:56.25 | 4:06.35 | 206725 | 225209
15 | 50:02.60 | 8:22.43 | 225210 | 262902
16 | 58:25.28 | 3:26.10 | 262903 | 278362
17 | 61:51.38 | 5:52.30 | 278363 | 304792

So, is the null sample thing the only possible explanation? And is this in any sense a bug in EAC, or would the error be spotted in secure mode?

It is by far the most likely explanation.

Can't say without seeing the two tracks that gave the same CRC in EAC but gave different CRCs for AR.

Dunno. Did you try it yet?

EAC should really default to use NULL samples for crc calculations.

I wouldn't be upset to see that setting removed altogether.

Here: different T&C crc but same AR crc:

RamonSalazar, that's because there was a bug in the first prebeta (which has since been fixed). The test pass was checked with Accuraterip, not the copy, which explains why the first rip appears to be "accurately ripped" when it's not.

I see, thanks.

Use "codebox" and "/codebox" instead of "code" and "/code" when posting log files.



Never did hear back from the original poster about his problem. This isn't something I've seen before.