Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Inconsistent AccurateRip results? (Read 11628 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Inconsistent AccurateRip results?

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

Inconsistent AccurateRip results?

Reply #2 –
>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.

Inconsistent AccurateRip results?

Reply #3 –
Quote from: spoon on
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?

Inconsistent AccurateRip results?

Reply #4 –
Quote from: HydroFred on
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.

Inconsistent AccurateRip results?

Reply #5 –
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?

Inconsistent AccurateRip results?

Reply #6 –
Quote from: alfienoakes101 on
So, is the null sample thing the only possible explanation?
It is by far the most likely explanation.

Quote from: alfienoakes101 on
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.

Quote from: alfienoakes101 on
would the error be spotted in secure mode?
Dunno.  Did you try it yet?

Inconsistent AccurateRip results?

Reply #7 –
EAC should really default to use NULL samples for crc calculations.

Inconsistent AccurateRip results?

Reply #9 –
Here: different T&C crc but same AR crc:

Code: [Select]
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

Inconsistent AccurateRip results?

Reply #10 –
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.

Inconsistent AccurateRip results?

Reply #11 –
I see, thanks.

Inconsistent AccurateRip results?

Reply #12 –
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.