Inconsistency in reporting from AccurateRip, CueTools, and EAC log

[fartlekrun]

I hope someone can help me understand these results. The EAC rip is a good rip, according to EAC.

The AccurateRip results in the EAC ripping log say:
No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

When I Verify the .cue in CueTools, CueTools' single line report in its window is:
AR: rip not accurate (0/4)

The .accurip report says:
[AccurateRip ID: 000e5094-00729308-9d091a0a] found.
Track [ CRC ] Status
01 [9cb2e7b7] (0/4) No match
02 [408078d3] (0/4) No match
03 [ec618f65] (0/4) No match
04 [01a58682] (0/4) No match
05 [f40f7a78] (0/4) No match
06 [d32030f9] (0/4) No match
07 [4523a46c] (0/4) No match
08 [c4638237] (0/4) No match
09 [798f0e55] (0/4) No match
10 [45058c6b] (0/4) No match


So, CueTools clearly states that the rip is not accurate. The .accurip report simply says "no match". But EAC's ripping log says it could be a different pressing, which is a very different statement from what CueTools says.

What is the conclusion? Is it that this is a different pressing, or that it is an inaccurate rip? The AccurateRip results in the EAC log saying it could be a different pressing seems credible, since this is a 1984 Australian pressing so likely not common. It's likely that the pressing in the database is a US or UK disk.

[twit]

I think it would be helpful to provide a bit more information:

- the exact version number of EAC you used
- the exact extract from EAC showing the rip result ("good" seems like your judgment of what EAC reported, rather than exactly what EAC reported)
- the settings you used for EAC (including but not limited to C2 pointers on or off)
- timing: are both results fairly close in time to each other (a few days at most), or are they months apart?

Without more information, I'd think that the CueTools result is the more credible, following the basic engineering principle that the result with more information is more likely to be more credible (EAC didn't find the disc, but CueTools did).

I think dBpoweramp would provide the most information for verifying such rips because it uses AccurateRip v2 with cross-pressing check, which neither CueTools nor EAC can do in full yet. And I think you are better off using C2 pointers if you think your drive uses them fairly well.

EAC also has a new version out as of November 23 - try that if you haven't. Good luck!

[Spoon]

Re: Inconsistency in reporting from AccurateRip, CueTools, and EAC log

They are both reporting the same thing, just with different wording.

I cannot see every track being inaccurate, so you have a different pressing (CueTools can check across pressings, but if the pressing offset is too large it cannot).

[fartlekrun]

Re: Inconsistency in reporting from AccurateRip, CueTools, and EAC log

Thanks for the replies.

twit. Right, I should have said it's EAC V0.99 prebeta 4. I didn't include the entire log, because I've noticed that having tons of pasted info sometimes intimidates people into not bothering with the thread.

Spoon: thanks, that was my thinking. Since everything else about the rip looks good, and the track reporting is consisent at 0/4 for each track, I think it's a different pressing. It is a 1984 Australian pressing, so probably not common.

The CueTools reporting is misleading though, to say "rip not accurate (0/4)". Surely in such cases it would be more accurate to say, as EAC did, that it could be a different pressing.

[golfer20636]

Re: Inconsistency in reporting from AccurateRip, CueTools, and EAC log

I don't think CUETOOLS uses the AccurateRip v2 database. I would recommend ripping the cd with CUERIPPER then use CUETOOLS to compare your EAC or dBpoweramp rip using the CTDB for a comparison.

[Porcus]

Re: Inconsistency in reporting from AccurateRip, CueTools, and EAC log

I don't think CUETOOLS uses the AccurateRip v2 database.

It does not crosscheck for different pressings with AR2.