CUETools versions 1.9.5 through 2.1.4 (current), AccurateRip support & more Options

[Marc27]

uh I'm not intending to chase anyone...
The case actually applies to me...
I ripped with incorrect settings many albums, most were reported as accurate.
If I re-rip them again and compare both rips with a checksum verification tool, chances are they are both the same (considering that I used the correct offset in both rips). The other alternative is that the checksum verification (like CRC 128bit), reports differences between tracks of the two rips. That would most likely indicate that the first rip was different/inaccurate though it was reported as accurate and maybe shared the same AR/CTDB checksum. My question is how likely/or maybe possible is that this can happen.

In others words, up to what point I should be confident that my old rips would pass a CRC 128bit verification/be identical to re-rips with correct settings, or not.

[Gregory S. Chudo...]

So let's say this case scenario

1. A rip with burst mode and other incorrect settings.
2. Same disc rip with secure mode/correct settings.
3. Both rips have different CRC128/64.
4. AR/Cuetools databases report both as accurate.

How likely or unlikely is 4 (as well as 3)?

Normally there's a roughly 2^(-32) chance (1 disc out of 4294967296), assuming the errors in burst mode were random.

It's hard to estimate the chance of non-random errors which could in theory be caused by CD-drive's firmware or something like that, when the database can contain a CRC from someone with the drive which has exactly the same problem. But you can probably be sure this didn't happen to you if AR confidence level was high enough, because the majority of submissions would be made using different drives that are unlikely to have exactly the same bug.

There's a quite high probability that the CRC of the complete image will differ, when there are problems reading the first or the last few samples of the disc, which AR/CTDB deliberately ignore.
This shouldn't worry you, however, because those are small areas and usually are very close to silence, so those errors won't be audible.

To cut the long story short: you can trust AR if confidence levels are 'high enough'. You'll have to determine that 'high enough' level for yourself depending on how paranoid you are.

[Nassoo]

Hello again!
I'm still a newbie with this tool, so I need a little help... I'm trying to verify my flacs (with no cue file). For some of them, after the verification, the tags look like this:

ACCURATERIPCOUNT = 0
ACCURATERIPCOUNTALLOFFSETS = 147
ACCURATERIPCOUNTWITHOFFSET = 177
ACCURATERIPTOTAL = 165

I suppose this means the rip is not accurate?
My question is about ACCURATERIPCOUNTALLOFFSETS and ACCURATERIPCOUNT - which one shows if the rip is accurate?
When the result in CueTools is "AR: rip accurate (30/33)", which tag corresponds to the first number (30 in this case)?
I'll be grateful if you can point me where I could read a detailed description of the exact meaning of this tags.

Thank you in advance!

[marc2003]

enable the "batch log" pane (button to the left of the preferences "cog" button). then change the "input" section to "local database". then find the album and highlight it, then you'll see the full log in the bottom pane and you can see how the numbers correspond with the tags.

[Gregory S. Chudo...]

When the result in CueTools is "AR: rip accurate (30/33)", which tag corresponds to the first number (30 in this case)?

AR: rip accurate (ACCURATERIPCOUNTALLOFFSETS/ACCURATERIPTOTAL)
EAC shows (ACCURATERIPCOUNT/ACCURATERIPTOTAL).
ACCURATERIPCOUNTALLOFFSETS is the sum of confidence against all pressings.

[Porcus]

So you are saying I have an obligation to do this? [...] The saying goes "if you give a dog a bone, you do not want to hear from the dog if it does not taste nice".

Just a very few points in here.

1) Generally speaking, I think that «listen to good advise» is good advise, obligation or not.

2) ... and I think Spoon did -- or attempted to do -- just that. Take a look at http://www.hydrogenaudio.org/forums/index....showtopic=61468 .

3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.

4) For an "AccurateRip 3" to be feasible now, I think the following three considerations are relevant: (I) is AR2 fundamentally flawed?, (II) is «anyone» yet using AR2?, (III) what are the costs of actually correcting it?. For (I), I think the relevant benchmark is «how bad is this compared to the weakness which as a matter of fact did trigger an update?», (III) I leave to you coders (Gregory, you could maybe even give Spoon a cutandpastable codebone here? ), and for (II) ... well, I do not know. AR2 support found its way into EAC last November, so it might be too late to be a good option?

This post has been edited by Porcus: May 28 2011, 16:28

[zfox]

3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.

The current choice of format is not CRC32. Gregory supported CRC32 against hashes. Please read #63.

[Gregory S. Chudo...]

3) Gregory, you did contribute on the matter (posting #53 and later), and from what I can see, you supported the current choice of checksum, right? (#57). If the checksum is still flawed then well, too bad, but it is not because it was chosen without consulting the Hydrogenaudio braintrust.

I was against the whole idea of introducing a new CRC (#53), and in case it was decided to introduce a new CRC, i advocated the use of CRC32 (#53, #57, #63). I said (#63) that new CRC is not much better than the old one. But there's not much point in bringing it all up now. What's done is done, i don't think that it can easily be reversed.

4) For an "AccurateRip 3" to be feasible now, I think the following three considerations are relevant:
(I) is AR2 fundamentally flawed?, (II) is «anyone» yet using AR2?, (III) what are the costs of actually correcting it?.

I) No, it's not. And AR1 was not.
II) When i verify my rips with ARv2-supporting version of CUETools, i see quite a lot of AR2 CRCs. Probably around 5-10 percents of the database are V2 CRCs.
III) If it was to be replaced with CRC32, that would be very easy to implement in CUETools. Much-much simpler than to implement cross-pressing verification for AR2 CRC.

Gregory, you could maybe even give Spoon a cutandpastable codebone here?

CRC32 is very well known and it's implementations are all-over the place.
I already did provide a link to efficient Fletcher-32 CRC code - it's based on the same idea that AR2 CRC, but without the bug and is a bit faster: http://en.wikipedia.org/wiki/Fletcher%27s_...m#Optimizations
But it's a little bit too late for that.

At this point, my first choice would be to just drop ARv2 CRC and revert back to ARv1 CRC, and purge all ARv2 CRCs from the database if it's possible. Just to keep things simple.
My second choice would be to do nothing and live with ARv2. It's ugly, and doesn't support cross-pressing verification too well, but it works.
My third choice would be to purge all ARv2 CRCs from the database and switch to CRC32, just to stop all the speculations about the perceived "flaws" in AR.
Fletcher-32 would be my last choice. It's a quite strong and very fast CRC, but it doesn't have to be that strong or that fast, and it's not a very well-known CRC.

This post has been edited by Gregory S. Chudov: May 28 2011, 19:53

[zfox]

Let me guess... Spoon chose to work on his own implementation due to marketing reasons.
BTW, the whole AR idea was great and all credits go to Spoon, and secondly, to Gregory for extending this concept.

[spoon]

Lets talk a little about perceived flaws in AR2...yes on very small datasets you can simulate collisions more readily than a CRC32, but I do not think this is true once a large amount of data passes through either (and any track on a CD is a large amount of data).

[Porcus]

Lets talk a little about perceived flaws in AR2...yes on very small datasets you can simulate collisions more readily than a CRC32, but I do not think this is true once a large amount of data passes through either (and any track on a CD is a large amount of data).

Given that we have a "large amount of data" (i.e. a full track), and given also some «realistic drive behaviour», then it would be a good thing to have at least some partial knowledge of what errors are possible, plausible and likely.

A very particular example: I guess you guys know fairly well how drives interpolate missing samples. So I would suppose that a likely erroneous sample delivered from the CD drive, is the interpolated value. So the «distribution of erroneous samples» should be expected to be far from uniform.

How often could such an error (assuming that the true value is not by coincidence equal to the interpolated!) lead to a collision? (The answer does possibly depend on what is the distribution in real music of "middle samples" given the two neighbours.)

[Marc27]

Thanks again. I should have studied CRC tech specs... now I did.

You'll have to determine that 'high enough' level for yourself depending on how paranoid you are.

IMHO = or > 2 or if the number of matches is the highest, seems right.

Thanks for taking the time.

[HotShotFR]

A minor feature request if I may:

could it be possible to provide a general setting to "always overwrite" files, or perhaps only non-critical files (e.g. .accurip, .log, .cue...)? The setting checkbox which pops up at run-time allows overwriting files during a batch job but is not remembered between or within subsequent sessions.

(Or perhaps did I overlook something...)

[fadsplat]

Summary: .accurip says rip is accurate, and if you compare .accurip CRC32 values to .log CRC values each track matches, but .accurip says that CRC32 values don't match for some tracks.

Using CueTools 2.0.9, I ran a Verify on a recent rip, and the result is puzzling. The .accurip report generated by CueTools says that the rip is accurate, but the bottom section says that the CRC32 values for tracks 5-9 don't match the CRC values for same tracks in the log, but instead match other track numbers. This is very strange.

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 95.3 [B32808E7] [942C824D]
01 89.6 [82FBCB38] [97D51307] CRC32
02 87.2 [F88E3C98] [BB1556DD] CRC32
03 89.5 [B3BB9AC3] [6C8DE019] CRC32
04 90.6 [BA3FCC92] [B6938BD8] CRC32
05 92.1 [73266BBC] [C902FE6B] [71E0C6B3]: CRC32 for track 6
06 83.9 [71E0C6B3] [7CF02AB2] [EA5530EF]: CRC32 for track 8
07 90.5 [67E5854C] [8C6E2362] [CE06ED2E]: CRC32 for track 9
08 93.1 [EA5530EF] [F3CAC94F] [73266BBC]: CRC32 for track 5
09 95.3 [CE06ED2E] [88EA19E5] [67E5854C]: CRC32 for track 7

However, when I check for myself by reading the two documents, the CRC32 values shown in the .accurip report do match the CRC values in the log for every track.

Is this some bug in CueTools? Has CueTools somehow become confused on this particular comparison? What is going on here?

Below are the full .accurip report and .log.

.accurip report

[CUETools log; Date: 02/06/2011 9:31:03 AM; Version: 2.0.9]
[CTDB TOCID: TdM8HPYZNBzW2K9i4Rxd8q7hDRE-] disk not present in database.
[AccurateRip ID: 0013ddc8-00918ae5-770d7809] found.
Track [ CRC ] Status
01 [e485c1f8] (17/60) Accurately ripped
02 [5c99a1ef] (17/59) Accurately ripped
03 [53b76232] (17/62) Accurately ripped
04 [88c50190] (17/60) Accurately ripped
05 [e3566cab] (17/61) Accurately ripped
06 [054a1dbf] (17/62) Accurately ripped
07 [8cafe5ba] (17/62) Accurately ripped
08 [2205f363] (17/60) Accurately ripped
09 [e29ccfac] (17/59) Accurately ripped
Offsetted by -664:
01 [e29e85e0] (02/60) Accurately ripped
02 [ff76a437] (00/59) No match
03 [dffd9922] (02/62) Accurately ripped
04 [c9f6d8d0] (00/60) No match
05 [5d9065db] (02/61) Accurately ripped
06 [2cc4bd7f] (02/62) Accurately ripped
07 [f105bc7a] (02/62) Accurately ripped
08 [68293fc3] (00/60) No match
09 [05d63d34] (00/59) No match
Offsetted by 331:
01 [863e09f3] (02/60) Accurately ripped
02 [609e5a3e] (02/59) Accurately ripped
03 [1f8680a4] (02/62) Accurately ripped
04 [0ffb3268] (04/60) No match but offset
05 [58876795] (02/61) No match but offset
06 [0bd38b07] (02/62) Accurately ripped
07 [dee95922] (02/62) Accurately ripped
08 [e1c23bf7] (02/60) Accurately ripped
09 [67078253] (04/59) No match but offset
Offsetted by 367:
01 [ea962457] (35/60) Accurately ripped
02 [5c6a4612] (37/59) Accurately ripped
03 [99765bbc] (37/62) Accurately ripped
04 [76db3188] (37/60) No match but offset
05 [4590994d] (36/61) No match but offset
06 [59e0f167] (37/62) Accurately ripped
07 [40cc0502] (37/62) Accurately ripped
08 [fccca867] (37/60) Accurately ripped
09 [4dfcaf47] (36/59) No match but offset

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 95.3 [B32808E7] [942C824D]
01 89.6 [82FBCB38] [97D51307] CRC32
02 87.2 [F88E3C98] [BB1556DD] CRC32
03 89.5 [B3BB9AC3] [6C8DE019] CRC32
04 90.6 [BA3FCC92] [B6938BD8] CRC32
05 92.1 [73266BBC] [C902FE6B] [71E0C6B3]: CRC32 for track 6
06 83.9 [71E0C6B3] [7CF02AB2] [EA5530EF]: CRC32 for track 8
07 90.5 [67E5854C] [8C6E2362] [CE06ED2E]: CRC32 for track 9
08 93.1 [EA5530EF] [F3CAC94F] [73266BBC]: CRC32 for track 5
09 95.3 [CE06ED2E] [88EA19E5] [67E5854C]: CRC32 for track 7

.log

Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 1. June 2011, 18:51

Herbie Hancock / Takin' Off

Used drive : HL-DT-STDVD-ROM DU10N Adapter: 0 ID: 1

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

Read offset correction : 102
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\a Accessories\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -5 -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.00 | 7:07.72 | 0 | 32096
2 | 7:07.72 | 5:25.48 | 32097 | 56519
3 | 12:33.45 | 6:10.42 | 56520 | 84311
4 | 18:44.12 | 6:47.40 | 84312 | 114876
5 | 25:31.52 | 6:55.58 | 114877 | 146059
6 | 32:27.35 | 6:27.50 | 146060 | 175134
7 | 38:55.10 | 6:34.17 | 175135 | 204701
8 | 45:29.27 | 5:32.00 | 204702 | 229601
9 | 51:01.27 | 6:27.28 | 229602 | 258654


Track 1

Filename C:\Rip\01 - Watermelon Man.wav

Pre-gap length 0:00:02.00

Peak level 89.6 %
Track quality 100.0 %
Test CRC 82FBCB38
Copy CRC 82FBCB38
Accurately ripped (confidence 17) [E485C1F8]
Copy OK

Track 2

Filename C:\Rip\02 - Three Bags Full.wav

Peak level 87.2 %
Track quality 100.0 %
Test CRC F88E3C98
Copy CRC F88E3C98
Accurately ripped (confidence 17) [5C99A1EF]
Copy OK

Track 3

Filename C:\Rip\03 - Empty Pockets.wav

Peak level 89.5 %
Track quality 99.9 %
Test CRC B3BB9AC3
Copy CRC B3BB9AC3
Accurately ripped (confidence 17) [53B76232]
Copy OK

Track 4

Filename C:\Rip\04 - The Maze.wav

Peak level 90.6 %
Track quality 100.0 %
Test CRC BA3FCC92
Copy CRC BA3FCC92
Accurately ripped (confidence 17) [88C50190]
Copy OK

Track 6

Filename C:\Rip\06 - Alone and I.wav

Pre-gap length 0:00:01.06

Peak level 83.9 %
Track quality 100.0 %
Test CRC 71E0C6B3
Copy CRC 71E0C6B3
Accurately ripped (confidence 17) [054A1DBF]
Copy OK

Track 8

Filename C:\Rip\08 - Three Bags Full [bonus alt. take].wav

Peak level 93.1 %
Track quality 100.0 %
Test CRC EA5530EF
Copy CRC EA5530EF
Accurately ripped (confidence 17) [2205F363]
Copy OK

Track 9

Filename C:\Rip\09 - Empty Pockets [bonus alt. take].wav

Peak level 95.3 %
Track quality 100.0 %
Test CRC CE06ED2E
Copy CRC CE06ED2E
Accurately ripped (confidence 17) [E29CCFAC]
Copy OK


8 track(s) accurately ripped
1 track(s) canceled

Some tracks could not be verified as accurate

There were errors

End of status report

------------------------------------------------------------
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009

EAC extraction logfile from 1. June 2011, 19:19

Herbie Hancock / Takin' Off

Used drive : HL-DT-STDVD-ROM DU10N Adapter: 0 ID: 1

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

Read offset correction : 102
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\a Accessories\Exact Audio Copy\Flac\flac.exe
Additional command line options : -V -5 -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.00 | 7:07.72 | 0 | 32096
2 | 7:07.72 | 5:25.48 | 32097 | 56519
3 | 12:33.45 | 6:10.42 | 56520 | 84311
4 | 18:44.12 | 6:47.40 | 84312 | 114876
5 | 25:31.52 | 6:55.58 | 114877 | 146059
6 | 32:27.35 | 6:27.50 | 146060 | 175134
7 | 38:55.10 | 6:34.17 | 175135 | 204701
8 | 45:29.27 | 5:32.00 | 204702 | 229601
9 | 51:01.27 | 6:27.28 | 229602 | 258654


Track 5

Filename C:\Rip\05 - Driftin'.wav

Peak level 92.1 %
Track quality 99.7 %
Test CRC 73266BBC
Copy CRC 73266BBC
Accurately ripped (confidence 17) [E3566CAB]
Copy OK

Track 7

Filename C:\Rip\07 - Watermelon Man [bonus alt. take].wav

Peak level 90.5 %
Track quality 100.0 %
Test CRC 67E5854C
Copy CRC 67E5854C
Accurately ripped (confidence 17) [8CAFE5BA]
Copy OK


All tracks accurately ripped

No errors occurred

End of status report

[Goratrix]

CUETools gets confused by "nonstandard" logs, I think it's normal, you can't expect it to be able to parse any kind of weird track order and combination.

[korth]

the bottom section says that the CRC32 values for tracks 5-9 don't match the CRC values for same tracks in the log, but instead match other track numbers. This is very strange.

What Goratrix said. The log file is being read in order from top to bottom, not by track number. The tracks are listed out of order so they don't match up. If tracks 5 and 7 were where they belong, everything would be fine.

This post has been edited by korth: Jun 2 2011, 16:03

[fadsplat]

The log file is being read in order from top to bottom, not by track number. The tracks are listed out of order so they don't match up. If tracks 5 and 7 were where they belong, everything would be fine.

Ah, okay, that makes sense if that's how CueTools reads the log. Thanks for explaining that, and thanks to Goratrix. Very helpful.

[HotShotFR]

I saw some discussion about this somewhere else. How can all the tracks return "(0/0) No match but offset" ?

IIRC that is either due to past aggressive cleanup of the AR database (?) or, more likely, when only two conflicting rips have been submitted to the DB and thus await resolution by a third one.
I have a small number of rips that return such a "(0/0) No match but offset" or "(0/0) Rip not accurate"... which sounds a bit counterintuitive indeed.

Short update on this puzzling "issue", I just noticed one case where all tracks but one are verified as accurately ripped (confidence 2/2), the faulty (?) one shows as "0/0 No match". Seems quite weird.

[ThePampers]

Hi, I have a problem.
I recently ripped some CDs without creating a cue file or log (for testing).
Checking the tracks with Cuetools i see this :

CODE

[AccurateRip ID: 0010d9b6-0092b069-9809ab0b] found.
Track [ CRC ] Status
01 [ddbaf796] (00/26) No match
02 [1b6d1bd2] (00/25) No match
03 [49fa7b44] (00/26) No match
04 [e3aa907f] (00/27) No match
05 [ad26832d] (00/27) No match
06 [1f61e1e9] (00/26) No match
07 [e89cac08] (00/26) No match
08 [b4e3847b] (00/26) No match
09 [8f2c09c6] (00/26) No match
10 [a5fd5554] (00/26) No match
11 [d7e5383d] (00/26) No match
Offsetted by 97:
01 [5c886412] (26/26) Accurately ripped
02 [5947ff85] (25/25) Accurately ripped
03 [3fd968b6] (26/26) Accurately ripped
04 [2d13494a] (27/27) Accurately ripped
05 [2e7772e4] (27/27) Accurately ripped
06 [d4f7cae4] (26/26) Accurately ripped
07 [ff712985] (26/26) Accurately ripped
08 [668cd35d] (26/26) Accurately ripped
09 [c297e9bc] (26/26) Accurately ripped
10 [28fcfb1e] (26/26) Accurately ripped
11 [ac5e13c7] (26/26) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL]
-- 98,8 [D0DB84E6] [946F787A]
01 98,8 [360A85C1] [4BD6A120]
02 94,4 [3B05C5A4] [3F9A9D2C]
03 98,8 [CA35FC88] [5C05F1BB]
04 98,8 [B9B96159] [06AC6F45]
05 96,6 [6D2BDD22] [17B5A1AD]
06 96,6 [3CE8E6DC] [12D0F567]
07 97,7 [7D2E17CA] [D80DA5D3]
08 97,7 [97FBAFFA] [A43B733B]
09 98,8 [7AB9CBDB] [5BF4A851]
10 98,8 [1B9D17AF] [3AE6C26B]
11 98,8 [0026DCEA] [1ADB9BB2]

Now I have created with Cuetools the correct cue file (+97 offsetted), then burn and re-rip with EAC (last beta 1.02) to verify the integrity.
EAC does not find any tracks correct (CRC data from AccurateRip database) :

CODE

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

EAC extraction logfile from 5. June 2011, 2:20

Sammy Hagar and the Wabos / Livin' It Up

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

Read mode : Burst

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 : Installed external ASPI interface
Gap handling : Appended to previous track

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 2:56.72 | 0 | 13271
2 | 2:56.72 | 4:20.38 | 13272 | 32809
3 | 7:17.35 | 3:34.15 | 32810 | 48874
4 | 10:51.50 | 4:39.30 | 48875 | 69829
5 | 15:31.05 | 3:41.25 | 69830 | 86429
6 | 19:12.30 | 2:18.07 | 86430 | 96786
7 | 21:30.37 | 3:37.10 | 96787 | 113071
8 | 25:07.47 | 4:23.43 | 113072 | 132839
9 | 29:31.15 | 4:21.27 | 132840 | 152441
10 | 33:52.42 | 4:24.35 | 152442 | 172276
11 | 38:17.02 | 2:58.48 | 172277 | 185674


Track 1

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\01. Sam I Am.wav

Pre-gap length 0:00:02.00

Peak level 98.8 %
Extraction speed 14.9 X
Test CRC 5F6459E7
Copy CRC 5F6459E7
Cannot be verified as accurate (confidence 26) [908F7E1E], AccurateRip returned [5C886412] (AR v2)
Copy OK

Track 2

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\02. Living on a Coastline.wav

Peak level 94.4 %
Extraction speed 20.3 X
Test CRC 40CFCCDB
Copy CRC 40CFCCDB
Cannot be verified as accurate (confidence 25) [6B9F2E0C], AccurateRip returned [5947FF85] (AR v2)
Copy OK

Track 3

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\03. Mexico.wav

Peak level 98.8 %
Extraction speed 21.9 X
Test CRC 2F1CE7EC
Copy CRC 2F1CE7EC
Cannot be verified as accurate (confidence 26) [1A43DF57], AccurateRip returned [3FD968B6] (AR v2)
Copy OK

Track 4

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\04. The Way We Live.wav

Peak level 98.8 %
Extraction speed 23.6 X
Test CRC 689321A8
Copy CRC 689321A8
Cannot be verified as accurate (confidence 27) [F346154E], AccurateRip returned [2D13494A] (AR v2)
Copy OK

Track 5

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\05. I Love This Bar.wav

Peak level 96.6 %
Extraction speed 25.0 X
Test CRC 772E3055
Copy CRC 772E3055
Cannot be verified as accurate (confidence 27) [19EFCB2A], AccurateRip returned [2E7772E4] (AR v2)
Copy OK

Track 6

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\06. One Sip.wav

Peak level 96.6 %
Extraction speed 26.0 X
Test CRC 31918E26
Copy CRC 31918E26
Cannot be verified as accurate (confidence 26) [361532C3], AccurateRip returned [D4F7CAE4] (AR v2)
Copy OK

Track 7

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\07. Rainy Day Woman #12,#35.wav

Peak level 97.7 %
Extraction speed 27.1 X
Test CRC 624C4D70
Copy CRC 624C4D70
Cannot be verified as accurate (confidence 26) [7A79873F], AccurateRip returned [FF712985] (AR v2)
Copy OK

Track 8

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\08. Halfway to Memphis.wav

Peak level 97.7 %
Extraction speed 28.4 X
Test CRC BAEA4D87
Copy CRC BAEA4D87
Cannot be verified as accurate (confidence 26) [074514C6], AccurateRip returned [668CD35D] (AR v2)
Copy OK

Track 9

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\09. Sailin.wav

Peak level 98.8 %
Extraction speed 29.7 X
Test CRC 6761AA6F
Copy CRC 6761AA6F
Cannot be verified as accurate (confidence 26) [7304C855], AccurateRip returned [C297E9BC] (AR v2)
Copy OK

Track 10

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\10. Let Me Take You There.wav

Peak level 98.8 %
Extraction speed 31.0 X
Test CRC 070ECDFD
Copy CRC 070ECDFD
Cannot be verified as accurate (confidence 26) [5613D63A], AccurateRip returned [28FCFB1E] (AR v2)
Copy OK

Track 11

Filename E:\ Sammy Hagar and the Wabos (2006) - Livin' It Up\11. Some Day.wav

Peak level 98.8 %
Extraction speed 32.0 X
Test CRC 3067D159
Copy CRC 3067D159
Cannot be verified as accurate (confidence 26) [F3E4844A], AccurateRip returned [AC5E13C7] (AR v2)
Copy OK


No tracks could be verified as accurate
You may have a different pressing from the one(s) in the database

No errors occurred

End of status report

==== Log checksum E7C0D84CE375C7EA0A055F4332ABFD5B95257FD60C77469B46C7080A217A9C48 ====

I can recreate the exact cue file without using the audio CD ?
I have to set something else?
I have to re-rip each disc again?
Thanks in advance .



Edit : Added log.

This post has been edited by ThePampers: Jun 5 2011, 01:28

[Nino-kun]

Your cue file was correct from begining. You just have shifted audio data in wave file. CUETools can shift data in wave file so image become "accurate". And you did it. You don't need write image back to CD. If really want to burn CD and rip it again, you need to set write offset in your burning software, or data will be shifted again and you also don't get "accurate" copy.

[Marc27]

I noticed a minor inconvenience while verifying multiple folders. If the disc directory contains more than one cue file (flac.cue;wav.cue), the same disc will be verified several times, one for each cue. Maybe the local database may be able to skip this redundant checks? (if "skip recently verified" is selected).
Thanks.

[sauvage78]

Any clue when the new version is coming (I thought it was planned for end of May) ? The AR update of June is up & I would like to update my "not present in database" rips but I would prefer using an updated CT (Specially for the HDCD detection bug). If the implementation of AR V2 is too long, just push it back to next version ...

[Gregory S. Chudo...]

ARv2 support (without pressings) is already implemented. I will try to release 2.1.2 within a week. Sorry for the delay, but i got a bit distracted with CTDB plugin, web site update and switch to cloud hosting.

[sauvage78]

Ok, thks for the quick anwser. I'm gonna wait then.

[Gregory S. Chudo...]

CUETools 2.1.2 is ready.
http://www.cuetools.net/install/CUETools_2.1.2.rar

This post has been edited by Gregory S. Chudov: Jun 13 2011, 22:32