Inconsistent AccurateRip results? Options

[alfienoakes101]

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

[greynol]

Please include the header with your log files.

[spoon]

>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.

[HydroFred]

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?

[greynol]

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.

[alfienoakes101]

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?

[greynol]

So, is the null sample thing the only possible explanation?

It is by far the most likely explanation.

And is this in any sense a bug in EAC?

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

would the error be spotted in secure mode?

Dunno. Did you try it yet?

[spoon]

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

[greynol]

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

[RamonSalazar]

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

CODE

Exact Audio Copy V0.99 prebeta 1 from 25. May 2007

EAC extraction logfile from 30. June 2007, 13:22

Led Zeppelin / II

Used drive : PLEXTOR DVDR PX-760A Adapter: 4 ID: 0

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

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

Track 3

Filename C:\EAC Rips\Led Zeppelin - II (Remaster)\03 - The Lemon Song.wav

Pre-gap length 0:00:01.52

Peak level 100.0 %
Track quality 100.0 %
Test CRC 8B5A3B71
Copy CRC F915A77B
Accurately ripped (confidence 60) [064518F0]
Copy OK

No errors occurred

---

Exact Audio Copy V0.99 prebeta 1 from 25. May 2007

EAC extraction logfile from 30. June 2007, 13:30

Led Zeppelin / II

Used drive : PLEXTOR DVDR PX-760A Adapter: 4 ID: 0

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

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

Track 3

Filename C:\EAC Rips\Led Zeppelin - II (Remaster)\03 - The Lemon Song.wav

Pre-gap length 0:00:01.52

Peak level 100.0 %
Track quality 100.0 %
Test CRC 8B5A3B71
Copy CRC 8B5A3B71
Accurately ripped (confidence 60) [064518F0]
Copy OK

No errors occurred

This post has been edited by RamonSalazar: Nov 18 2007, 20:37

[verbajim]

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.

This post has been edited by verbajim: Nov 18 2007, 10:41

[RamonSalazar]

I see, thanks.

[greynol]

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.

This post has been edited by greynol: Nov 19 2007, 07:07