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

[zfox]

Greg, the latest CUERipper cannot detect drive settings from a PLEXTOR BD-ROM PX-B120U 1.11 (USB). An Exception is thrown when the ripping process initiates. Medium is present.



This post has been edited by zfox: Mar 7 2013, 12:36

[mjb2006]

Since CTDB started per-track verification, all rip results from CUERipper and the EAC plugin are submitted but repair data is only supposed to be accepted for good rips. Per-disc verification can have several (1/x) No match results from rips with some errors by design. Those results are stored to increase confidence levels for the tracks without errors. The detailed log is Off by default so most users should only see the per-track results similar to AR.
CUETools only submits to CTDB if AR confidence is greater than 1 AND no existing entry is found in CTDB.

[EDIT]
You're probably seeing a bad repair submission from the EAC plugin. See CTDB EAC Plugin: Known_issues. Don't trust (1/x) results for repair.
But it could also be an alternate pressing. If I ever get the guide written for the wiki, I have an example of such a disc.

I ripped a scratched CD with EAC. The CTDB plug-in submitted the bad rip, as expected:

CODE

Exact Audio Copy V1.0 beta 3 from 29. August 2011

EAC extraction logfile from 21. March 2013, 2:11

Venus Hum / Big Beautiful Sky

Used drive : PLDS DVD-RW DH16ABSH Adapter: 0 ID: 1

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

Read offset correction : 6
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 : Not detected, thus 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 | 4:00.55 | 0 | 18054
2 | 4:00.55 | 3:46.70 | 18055 | 35074
3 | 7:47.50 | 3:51.63 | 35075 | 52462
4 | 11:39.38 | 4:05.40 | 52463 | 70877
5 | 15:45.03 | 4:19.72 | 70878 | 90374
6 | 20:05.00 | 3:16.70 | 90375 | 105144
7 | 23:21.70 | 3:20.23 | 105145 | 120167
8 | 26:42.18 | 4:23.10 | 120168 | 139902
9 | 31:05.28 | 4:37.62 | 139903 | 160739
10 | 35:43.15 | 4:07.40 | 160740 | 179304
11 | 39:50.55 | 3:54.33 | 179305 | 196887
12 | 43:45.13 | 3:49.17 | 196888 | 214079
13 | 50:06.30 | 5:25.14 | 225480 | 249868


Track 1

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[01] Venus Hum - Hummingbirds.wav

Peak level 99.9 %
Extraction speed 5.8 X
Track quality 99.9 %
Copy CRC CC117BC9
Accurately ripped (confidence 2) [A64BC7C9] (AR v2)
Copy OK

Track 2

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[02] Venus Hum - Montana.wav

Peak level 99.9 %
Extraction speed 7.6 X
Track quality 100.0 %
Copy CRC ECD92270
Accurately ripped (confidence 2) [A5BBB289] (AR v2)
Copy OK

Track 3

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[03] Venus Hum - Soul Sloshing.wav

Peak level 99.9 %
Extraction speed 8.5 X
Track quality 100.0 %
Copy CRC B024FA16
Accurately ripped (confidence 2) [E5A1EA29] (AR v2)
Copy OK

Track 4

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[04] Venus Hum - Wordless May.wav

Peak level 99.9 %
Extraction speed 9.2 X
Track quality 100.0 %
Copy CRC 58AA8AAD
Accurately ripped (confidence 2) [E744AD30] (AR v2)
Copy OK

Track 5

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[05] Venus Hum - Alice.wav

Suspicious position 0:03:19 - 0:03:24

Peak level 99.9 %
Extraction speed 2.8 X
Track quality 98.7 %
Copy CRC FCA14352
Cannot be verified as accurate (confidence 27) [F5A38655], AccurateRip returned [FD2A830B] (AR v2)
Copy finished

Track 6

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[06] Venus Hum - Lumberjacks.wav

Peak level 99.9 %
Extraction speed 9.9 X
Track quality 100.0 %
Copy CRC A0DE05F6
Accurately ripped (confidence 2) [21B3171D] (AR v2)
Copy OK

Track 7

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[07] Venus Hum - Beautiful Spain.wav

Peak level 99.9 %
Extraction speed 10.8 X
Track quality 100.0 %
Copy CRC 230A2618
Accurately ripped (confidence 2) [BCD1BD5A] (AR v2)
Copy OK

Track 8

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[08] Venus Hum - The Bells.wav

Peak level 99.9 %
Extraction speed 11.4 X
Track quality 100.0 %
Copy CRC E388B1C0
Accurately ripped (confidence 2) [8103622F] (AR v2)
Copy OK

Track 9

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[09] Venus Hum - Springtime #2.wav

Peak level 99.9 %
Extraction speed 11.1 X
Track quality 100.0 %
Copy CRC 61436095
Accurately ripped (confidence 2) [CEA24984] (AR v2)
Copy OK

Track 10

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[10] Venus Hum - Honey.wav

Peak level 99.9 %
Extraction speed 12.4 X
Track quality 100.0 %
Copy CRC DF87E5C4
Accurately ripped (confidence 2) [375E42E5] (AR v2)
Copy OK

Track 11

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[11] Venus Hum - Sonic Boom.wav

Peak level 99.9 %
Extraction speed 12.8 X
Track quality 100.0 %
Copy CRC EB1BD55B
Accurately ripped (confidence 2) [222135FC] (AR v2)
Copy OK

Track 12

Filename I:\incoming music\_new rips\Venus Hum - Big Beautiful Sky\[12] Venus Hum - Bella Luna.wav

Peak level 99.9 %
Extraction speed 13.1 X
Track quality 100.0 %
Copy CRC DEDB90BA
Accurately ripped (confidence 2) [B731197C] (AR v2)
Copy OK


11 track(s) accurately ripped
1 track(s) could not be verified as accurate

Some tracks could not be verified as accurate

There were errors

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: 57yKe23QeyaVP_eCU_cTkYq8sIw-] found, Submit result: 57yKe23QeyaVP_eCU_cTkYq8sIw- has been submitted
[d1e028a7] (33/33) Differs in 498 samples @19:04:16,19:05:06-19:05:07,19:05:45,19:06:61,19:06:74-19:07:00,19:07:12-19:07:13,19:07:25-19:07:26,19:08:41-19:08:42,19:09:05-19:09:06,19:09:44
You can use CUETools to repair this rip.

So now CTDB has 8 submissions, 7 of which are identical, presumably good rips, plus my bad one. (not sure if it matters I was using the 2.1.3 plugin)

I then re-ripped it with CUERipper, which also had trouble with the scratched track:

CODE

[CUETools log; Date: 3/21/2013 2:50:50 AM; Version: 2.1.4]
CD-Extra data track length 05:25:14.
[CTDB TOCID: 57yKe23QeyaVP_eCU_cTkYq8sIw-] found.
Track | CTDB Status
1 | (9/9) Accurately ripped
2 | (9/9) Accurately ripped
3 | (9/9) Accurately ripped
4 | (9/9) Accurately ripped
5 | (7/9) Differs in 90 samples @03:20:03,03:20:42,03:22:22-03:22:23,03:23:13,03:30:07, or (1/9) differs in 90 samples @03:20:03,03:20:42,03:22:22-03:22:23,03:23:13,03:30:07
6 | (9/9) Accurately ripped
7 | (9/9) Accurately ripped
8 | (9/9) Accurately ripped
9 | (9/9) Accurately ripped
10 | (9/9) Accurately ripped
11 | (9/9) Accurately ripped
12 | (9/9) Accurately ripped
[AccurateRip ID: 0015a670-00cc644e-a40d030d] found.
Track [ CRC | V2 ] Status
01 [12884c66|a64bc7c9] (28+02/30) Accurately ripped
02 [b3a4581d|a5bbb289] (29+02/31) Accurately ripped
03 [8716e2e3|e5a1ea29] (28+02/30) Accurately ripped
04 [1b3000ee|e744ad30] (28+02/30) Accurately ripped
05 [5a789296|c8fda304] (00+00/29) No match
06 [c930d756|21b3171d] (28+02/30) Accurately ripped
07 [b934b899|bcd1bd5a] (27+02/29) Accurately ripped
08 [12695676|8103622f] (27+02/29) Accurately ripped
09 [b9a7d402|cea24984] (27+02/29) Accurately ripped
10 [09fa0c5c|375e42e5] (27+02/29) Accurately ripped
11 [9a909811|222135fc] (26+02/28) Accurately ripped
12 [5d405a40|b731197c] (25+02/27) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [EB8A4739] [01964A15]
01 99.9 [CC117BC9] [73379AF5]
02 99.9 [ECD92270] [5F08F957]
03 99.9 [B024FA16] [D597085A]
04 99.9 [58AA8AAD] [AB8637B3]
05 99.9 [9424BF4A] [CB9A1600]
06 99.9 [A0DE05F6] [4FA4E9E0]
07 99.9 [230A2618] [FAF190F3]
08 99.9 [E388B1C0] [F001FAF1]
09 99.9 [61436095] [74AE5D1A]
10 99.9 [DF87E5C4] [97298B19]
11 99.9 [EB1BD55B] [45D1D6CF]
12 99.9 [DEDB90BA] [6FBC05BE]

I should've made a note of what the post-rip dialog said. I believe it said something about differing in 90 samples, something submitted... so it seems bad rips can be submitted from CUERipper? Meaning there are now 9 submissions (7 good, 2 bad) (plus 1 with no data track):

http://db.cuetools.net/?tocid=57yKe23QeyaVP_eCU_cTkYq8sIw-

Both rippers said I could maybe repair the rip with CUETools, so I attempted to do so by dragging the CUERipper rip's .cue file into CUETools, selecting Encode/repair, Tracks, Lossless/flac.

But CUETools won't do anything. After it verifies the tracks, it doesn't prompt me or anything. It just says, in the log section:

CODE

I:\New folder\Venus Hum\2003 - Big Beautiful Sky\Venus Hum - Big Beautiful Sky.cue: differs in 90 samples, confidence 7, or differs in 90 samples, confidence 1, or verified OK, confidence 1.

How can I make it repair this rip to match the 7 presumably good submissions?

This post has been edited by mjb2006: Mar 21 2013, 10:35

[Gregory S. Chudo...]

There is a known problem where it wouldn't do anything, because repair doesn't work in batch mode (drag and drop mode, or multiselect file browser, or when selecting a folder).
Just hide the browser or switch folder browser.

[ChronoSphere]

Two questions:

- is offset correction "harmless", as in, does it change something audible? If not, why would I want to do it?
- CUETools doesn't seem to support foobar's %album artist%. Does it

This appears to do what HotShotFR was trying to do.
ref: CUETools Advanced Settings: Encoders

Extension: wv
Path: wavpack.exe (wavpack.exe copied to CUETools folder)
Parameters: -hb%Mx -c -m - %O
Modes: 256 320
Name: wv_hybrid

Creates hybrid .wv and .wvc correction files.
[edit]: .wv is registered in CUETools as a 'lossless' encoder so that's where you'll find 'wv_hybrid' for encoding.

Coming back to this, I'm pretty close to what I wanted to achieve, but there are a few problems. I'm going from one file with embedded cuesheet -> separate tracks, this leads to following output

- separate tracks with their respective .wvc
- the tracks don't have any tags beyond %album% and %artist% in them
- there seems to be no way to define a naming scheme for the tracks, only for the cuesheet itself
- the cuesheet is not written in utf-8 even though the internal cue was utf-8 (need this for all the foreign characters, rus/jpn)
- the cuesheet is messed up for the second track (resulting in an unparseable cue), for example:

CODE

REM GENRE "Rock"
REM DATE 1991
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Alice Cooper"
TITLE "Hey Stoopid"
REM REPLAYGAIN_ALBUM_GAIN -6.45 dB
REM REPLAYGAIN_ALBUM_PEAK 0.972931
FILE "01. Hey Stoopid.wv" WAVE
TRACK 01 AUDIO
TITLE "Hey Stoopid"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Love's A Loaded Gun"
INDEX 00 04:32:56
FILE "02. Love's A Loaded Gun.wv" WAVE
INDEX 01 00:00:00
TRACK 03 AUDIO
TITLE "Snakebite"
INDEX 00 04:09:47
FILE "03. Snakebite.wv" WAVE
INDEX 01 00:00:00
TRACK 04 AUDIO
TITLE "Burning Our Bed"
INDEX 00 04:31:29
FILE "04. Burning Our Bed.wv" WAVE
INDEX 01 00:00:00
TRACK 05 AUDIO
TITLE "Dangerous Tonight"
INDEX 00 04:32:71
FILE "05. Dangerous Tonight.wv" WAVE
INDEX 01 00:00:00
TRACK 06 AUDIO
TITLE "Might As Well Be On Mars"
INDEX 00 04:40:02
FILE "06. Might As Well Be On Mars.wv" WAVE
INDEX 01 00:00:00
TRACK 07 AUDIO
TITLE "Feed My Frankenstein"
INDEX 00 07:07:46
FILE "07. Feed My Frankenstein.wv" WAVE
INDEX 01 00:00:00
TRACK 08 AUDIO
TITLE "Hurricane Years"
INDEX 00 04:42:72
FILE "08. Hurricane Years.wv" WAVE
INDEX 01 00:00:00
TRACK 09 AUDIO
TITLE "Little By Little"
INDEX 00 03:56:71
FILE "09. Little By Little.wv" WAVE
INDEX 01 00:00:00
TRACK 10 AUDIO
TITLE "Die For You"
INDEX 00 04:33:34
FILE "10. Die For You.wv" WAVE
INDEX 01 00:00:00
TRACK 11 AUDIO
TITLE "Dirty Dreams"
INDEX 00 04:15:04
FILE "11. Dirty Dreams.wv" WAVE
INDEX 01 00:00:00
TRACK 12 AUDIO
TITLE "Wind-Up Toy"
INDEX 00 03:27:59
FILE "12. Wind-Up Toy.wv" WAVE
INDEX 01 00:00:00

Any ideas? I'd rather not re-tag the whole library after conversion...

[Gregory S. Chudo...]

- offset correction is _ almost_ harmless - it might loose some samples at the beginning or end (depending on whether offset is positive or negative), number of lost samples equals offset, but in 99% of cases those samples would be null anyway. But as i explained several times here, i don't see any reason to do this.
- CUETools does support "album artist", but this tag is only written if track artists are specified and differ from album artist.
- the naming scheme for tracks should be defined in "Track format" option.
- utf8 is used when cuesheet has characters that are missing in your default codepage, e.g. if you have Russian Windows version, utf8 will be used for Japanese, but not for Russian.
- the cue-sheet is not messed up, it's called "Gaps appended/non-compliant". You can try using "Gaps prepended" if you want fb2k to read it, but that would also change your audio files - they will contain silence before tracks, not after tracks, which might not be what you want. Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

[greynol]

Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

Seriously, this!

A cue sheet is a cue sheet, not a playlist. If you need a playlist, use a playlist.

[ChronoSphere]

Thanks for the fast response,

- CUETools does support "album artist", but this tag is only written if track artists are specified and differ from album artist.

I see. I guess there is no possibility of writing something like %album artist%[ ／%track artist%] as output then?

- the naming scheme for tracks should be defined in "Track format" option.

Found it, thanks!

- utf8 is used when cuesheet has characters that are missing in your default codepage, e.g. if you have Russian Windows version, utf8 will be used for Japanese, but not for Russian.

Hmm well, my codepage for non-unicode programs is set to Japanese, so I guess that's why it doesn't use UTF-8. For compatibility reasons though, it'd be nice to have an option to force it to use UTF-8 all the time...

- the cue-sheet is not messed up, it's called "Gaps appended/non-compliant". You can try using "Gaps prepended" if you want fb2k to read it, but that would also change your audio files - they will contain silence before tracks, not after tracks, which might not be what you want. Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

I guess I just don't understand the format of it then, to me it looks like it groups 2 first tracks together to one and shifts the rest. The cuesheets CUERipper creates don't have this format even though I configured it to keep HTOA. I must be misunderstanding something here, I don't see why this format is needed when converting from single file -> separate tracks when it was not needed to preserver the HTOA/gaps when I ripped the CD...

Ask Peter to support "Gaps appended" cue-sheets in fb2k, or just don't use cue-sheets with fb2k.

Seriously, this!

A cue sheet is a cue sheet, not a playlist. If you need a playlist, use a playlist.

As long as that cuesheet can still be used to burn the CD back perfectly, all is fine. I didn't plan to use it as a playlist, I was just confused since it's the first time I saw a non-compliant cuesheet.

edit: Any idea about track tags? Can I get it to put title/replaygain info from the embedded cuesheet into the separate tracks?

This post has been edited by ChronoSphere: Mar 24 2013, 21:32

[Gregory S. Chudo...]

I see. I guess there is no possibility of writing something like %album artist%[ ／%track artist%] as output then?

I thought we were talking about tags. If we're talking about filenames, %artist% means different things in output path format and in track format. In the first case it means album artist, in the second case - track artist.
For example, you might have output path format "%music%\%artist%\[%year% - ]%album%[' ('%unique%')']\%artist% - %album%.cue" and track format "%tracknumber%.[ %artist% -] %title%".
You will get files like "C:\Users\user\Music\Various Artists\1990 - Greatest Hits\Various Artists - Greatest Hits.cue" and "C:\Users\user\Music\Various Artists\1990 - Greatest Hits\01. Abba - Mamma Mia.wv".

For compatibility reasons though, it'd be nice to have an option to force it to use UTF-8 all the time...

This might be a good idea.

I don't see why this format is needed when converting from single file -> separate tracks when it was not needed to preserver the HTOA/gaps when I ripped the CD...

It is needed when there are gaps between tracks. Not all CDs have gaps. Also, CUERipper might for some reason be unable to detect gaps with your drive.

edit: Any idea about track tags? Can I get it to put title/replaygain info from the embedded cuesheet into the separate tracks?

CUETools doesn't transfer replay gain. Those tags are nonstandard, and would probably have to be recalculated anyway after splitting album into tracks - individual tracks might have a different gain compared to the whole album.
As for the track title, it should have been transferred, unless you disabled it by unchecking "Write basic tags from CUE data".

This post has been edited by Gregory S. Chudov: Mar 24 2013, 23:05

[ChronoSphere]

It is needed when there are gaps between tracks. Not all CDs have gaps. Also, CUERipper might for some reason be unable to detect gaps with your drive.

This seems to be the case I guess. I do remember some kind of gap related error, but that was on a scratched CD. Is correct gap detection not related to AR/CTDB results? How can I test if it's detecting the gaps correctly?

Here's the internal .cue CUERipper created for comparison

CODE

REM GENRE Rock
REM DATE 1991
REM COMMENT ExactAudioCopy v0.99pb4
PERFORMER "Alice Cooper"
TITLE "Hey Stoopid"
REM REPLAYGAIN_ALBUM_GAIN -6.45 dB
REM REPLAYGAIN_ALBUM_PEAK 0.972931
FILE "DUMMY" WAVE
TRACK 01 AUDIO
TITLE "Hey Stoopid"
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Love's A Loaded Gun"
INDEX 00 04:32:56
INDEX 01 04:34:37
TRACK 03 AUDIO
TITLE "Snakebite"
INDEX 00 08:44:09
INDEX 01 08:45:65
TRACK 04 AUDIO
TITLE "Burning Our Bed"
INDEX 00 13:17:19
INDEX 01 13:19:00
TRACK 05 AUDIO
TITLE "Dangerous Tonight"
INDEX 00 17:51:71
INDEX 01 17:53:52
TRACK 06 AUDIO
TITLE "Might As Well Be On Mars"
INDEX 00 22:33:54
INDEX 01 22:35:35
TRACK 07 AUDIO
TITLE "Feed My Frankenstein"
INDEX 00 29:43:06
INDEX 01 29:44:62
TRACK 08 AUDIO
TITLE "Hurricane Years"
INDEX 00 34:27:59
INDEX 01 34:29:40
TRACK 09 AUDIO
TITLE "Little By Little"
INDEX 00 38:26:36
INDEX 01 38:28:17
TRACK 10 AUDIO
TITLE "Die For You"
INDEX 00 43:01:51
INDEX 01 43:03:32
TRACK 11 AUDIO
TITLE "Dirty Dreams"
INDEX 00 47:18:36
INDEX 01 47:20:17
TRACK 12 AUDIO
TITLE "Wind-Up Toy"
INDEX 00 50:48:01
INDEX 01 50:49:57

Doesn't this one handle gaps as well? I always thought that the index 00/01 was exactly for that :x

CUETools doesn't transfer replay gain. Those tags are nonstandard, and would probably have to be recalculated anyway after splitting album into tracks - individual tracks might have a different gain compared to the whole album.
As for the track title, it should have been transferred, unless you disabled it by unchecking "Write basic tags from CUE data".

I'm kinda noticing my whole options are messed up for some reason.
The option was indeed unchecked. I guess recalculating replay gain is not a big problem, it's usually fast. The tags shouldn't change though, foobar calculates both track and album gain, those values are still valid since the tracks still represent one album.

What does %unique% do exactly btw?
Thanks for your patience ^^;

[Gregory S. Chudo...]

How can I test if it's detecting the gaps correctly?
Here's the internal .cue CUERipper created for comparison

This CUE-sheet has sane INDEX 00 entries, which means that CUERipper is detecting the gaps correctly.
This CUE-sheet is from a single-file disc image. Non-compliant cue-sheets are for file-per-track gaps-appended rips. Gaps-prepended cue-sheet would look more like a single-file one, but there are other problems with gaps-prepended rips. For example, when you select a track in a player and click "play", you might have to listen to the ending of the previous track first.

What does %unique% do exactly btw?

It makes sure that if the target file already exists, a new folder is created.
This might happen if you have a two disc release or several remasters of the same album, or just several rips of the same disc.
It's not very useful when you are processing a single album - you might prefer to see a warning dialog that tells you that file already exists instead. That's what happens if you remove %unique% from your path template.
But when you are batch-processing a lot of albums, you might want to make sure each one will end up in a different folder instead of just being skipped.

[ChronoSphere]

I think I understand now, thanks. Seeing as ImgBurn seems to parse the non-compliant cuesheet correctly, I can just safely ignore the fact foobar can't parse it - I guess the reason being that you don't need a .cue for playback if you have separate tracks anyway. And converting back to a single file "restores" the single file version, so it's all good.

Now to decide if I really want to change my storage scheme and format

edit: though I probably wait till you have the time to add that "force utf-8" option, if you do.

This post has been edited by ChronoSphere: Mar 25 2013, 02:10

[eleria]

Hello, I have a little problem.
My drive is recognized by accuraterip as having a +667 offset (it's true at 100% according to thousands of drive records), there is 1 CTDB and 2 AccurateripDB records, and the log tells me

CODE

Track cannot be verified as accurate (confidence 2)  [A2616C17], AccurateRip returned [F9186714]

Then

CODE

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

At the end of the ripping sequence I got a popup saying that the data was sent to CTDB and that the rip would be OK if I had an offset of 664 not 667.

I've never had such case so I don't know what to do, should I consider MY rip is accurate and the other one isn't ?
I mean my drive can't have a different offset than accuraterip says because I've ripped quite a few other CDs and both CTDB and AccurateDB always said my rip were accurate.

[korth]

Likely just a different pressing than the one in the AR database. Your rip is probably accurate but I'd need to see the full log(s).
Your drive offset should be correct at +667.

This post has been edited by korth: Mar 25 2013, 13:21

[eleria]

Thanks for the reply, here are 3 logs including the problematic one which is the last.

CODE

CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 16. November 2012, 15:51

At the Drive-In / Relationship of Command

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

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

Read offset correction                      : 667
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

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:55.07 |         0    |    13131  
        2  |  2:55.07 |  3:17.60 |     13132    |    27966  
        3  |  6:12.67 |  4:19.73 |     27967    |    47464  
        4  | 10:32.65 |  3:27.35 |     47465    |    63024  
        5  | 14:00.25 |  6:05.20 |     63025    |    90419  
        6  | 20:05.45 |  3:02.72 |     90420    |   104141  
        7  | 23:08.42 |  5:01.08 |    104142    |   126724  
        8  | 28:09.50 |  2:55.37 |    126725    |   139886  
        9  | 31:05.12 |  5:24.65 |    139887    |   164251  
       10  | 36:30.02 |  3:23.08 |    164252    |   179484  
       11  | 39:53.10 |  5:34.15 |    179485    |   204549  
       12  | 45:27.25 |  4:00.47 |    204550    |   222596  
       13  | 49:27.72 |  4:13.10 |    222597    |   241581  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\At the Drive-In - Relationship of Command - 2000\At the Drive-In - Relationship of Command.wav

     Peak level 99.9 %
     Range quality 100.0 %
     Test CRC 2505FC11
     Copy CRC 2505FC11
     Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 19)  [F631A120]
Track  2  accurately ripped (confidence 19)  [18852F53]
Track  3  accurately ripped (confidence 19)  [02AD2E58]
Track  4  accurately ripped (confidence 19)  [E919CB93]
Track  5  accurately ripped (confidence 19)  [967FF13E]
Track  6  accurately ripped (confidence 19)  [40902E96]
Track  7  accurately ripped (confidence 18)  [A8CDF656]
Track  8  accurately ripped (confidence 18)  [0C01D025]
Track  9  accurately ripped (confidence 19)  [FD3D5565]
Track 10  accurately ripped (confidence 19)  [C7C865D2]
Track 11  accurately ripped (confidence 18)  [2A360003]
Track 12  accurately ripped (confidence 18)  [6247A558]
Track 13  accurately ripped (confidence 17)  [C5DC9BF1]

All tracks accurately ripped

End of status report

CODE

CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 8. November 2012, 14:46

Pin-Up Went Down / 2 Unlimited

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

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

Read offset correction                      : 667
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

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 |  1:36.50 |         0    |     7249  
        2  |  1:36.50 |  3:18.37 |      7250    |    22136  
        3  |  4:55.12 |  3:50.15 |     22137    |    39401  
        4  |  8:45.27 |  4:07.46 |     39402    |    57972  
        5  | 12:52.73 |  2:21.48 |     57973    |    68595  
        6  | 15:14.46 |  5:30.45 |     68596    |    93390  
        7  | 20:45.16 |  2:37.63 |     93391    |   105228  
        8  | 23:23.04 |  2:42.60 |    105229    |   117438  
        9  | 26:05.64 |  1:33.12 |    117439    |   124425  
       10  | 27:39.01 |  4:34.47 |    124426    |   145022  
       11  | 32:13.48 |  3:04.71 |    145023    |   158893  
       12  | 35:18.44 |  3:15.35 |    158894    |   173553  
       13  | 38:34.04 |  3:32.39 |    173554    |   189492  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\Pin-Up Went Down\2008 - 2 Unlimited\Pin-Up Went Down - 2 Unlimited.wav

     Peak level 100.0 %
     Range quality 100.0 %
     Test CRC 43E7AD84
     Copy CRC 43E7AD84
     Copy OK

No errors occurred


AccurateRip summary

Track  1  accurately ripped (confidence 4)  [5045D70C]
Track  2  accurately ripped (confidence 4)  [D5625C27]
Track  3  accurately ripped (confidence 4)  [3334CED0]
Track  4  accurately ripped (confidence 4)  [6EBEEE8B]
Track  5  accurately ripped (confidence 4)  [016BB552]
Track  6  accurately ripped (confidence 4)  [28741680]
Track  7  accurately ripped (confidence 4)  [1FB50058]
Track  8  accurately ripped (confidence 4)  [529E605C]
Track  9  accurately ripped (confidence 4)  [60D0D6E4]
Track 10  accurately ripped (confidence 4)  [CC93B6CB]
Track 11  accurately ripped (confidence 4)  [7A48C17B]
Track 12  accurately ripped (confidence 4)  [1FF38C77]
Track 13  accurately ripped (confidence 4)  [33588998]

All tracks accurately ripped

End of status report

Last, this is the problematic one :

CODE

CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 25. March 2013, 11:10

Deja Vu / Baroque in the Future

Used drive  : HL-DT-ST DVDRAM GH22NS50   Adapter: 1  ID: 0

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

Read offset correction                      : 667
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

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 |  3:50.42 |         0    |    17291  
        2  |  3:50.42 |  5:52.25 |     17292    |    43716  
        3  |  9:42.67 |  3:33.34 |     43717    |    59725  
        4  | 13:16.26 |  5:29.54 |     59726    |    84454  
        5  | 18:46.05 |  3:42.67 |     84455    |   101171  
        6  | 22:28.72 |  6:37.64 |    101172    |   131010  
        7  | 29:06.61 |  7:53.15 |    131011    |   166500  
        8  | 37:00.01 |  5:50.13 |    166501    |   192763  
        9  | 42:50.14 |  8:06.13 |    192764    |   229226  


Range status and errors

Selected range

     Filename C:\Users\Luthee\Music\Deja Vu - Baroque in the Future - 1988\Deja Vu - Baroque in the Future.wav

     Peak level 96.6 %
     Range quality 100.0 %
     Test CRC 62B2D3F3
     Copy CRC 62B2D3F3
     Copy OK

No errors occurred


AccurateRip summary

Track  1  cannot be verified as accurate (confidence 2)  [A2616C17], AccurateRip returned [F9186714]
Track  2  cannot be verified as accurate (confidence 2)  [6CEF18F6], AccurateRip returned [41EFB4BF]
Track  3  cannot be verified as accurate (confidence 2)  [F1FD619B], AccurateRip returned [1EC8B4A5]
Track  4  cannot be verified as accurate (confidence 2)  [49F2315B], AccurateRip returned [FB9B2DF2]
Track  5  cannot be verified as accurate (confidence 2)  [866E0C80], AccurateRip returned [590B95DF]
Track  6  cannot be verified as accurate (confidence 2)  [93F11EC8], AccurateRip returned [919F7895]
Track  7  cannot be verified as accurate (confidence 2)  [6148B71D], AccurateRip returned [52AB16FB]
Track  8  cannot be verified as accurate (confidence 2)  [6963ADF9], AccurateRip returned [522BED4E]
Track  9  cannot be verified as accurate (confidence 2)  [5F2E26E3], AccurateRip returned [0C3A1EA5]

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

End of status report

[korth]

Your rip matched the entry in the CTDB so confidence there is now 2 and your rip is accurate according to that database. I'm getting this info from the database using info in the log, not from the log itself. Sorry, I should have been more specific on the logs. I meant *.log and *.accurip for the last rip only. The *.accurip log gives additional info.

This post has been edited by korth: Mar 25 2013, 16:22

[themanuel]

Can either CueRipper or CueTools be used in single file mode, or do I have to do all operations on all tracks always?

I'm quickly jumping into the CueTools bandwagon after years of using EAC. I ripped one of my old CD's (in great shape) and after many tries, finally got an error-free rip (according to EAC) of two tracks that would not verify in the AR database. Then I listened to those two tracks and found audible glitches on both of them. This sent brought my confidence in EAC very low. Today I tried CueRipper on the same CD, although a different drive, and only one of the problem tracks would not verify but it sounded glitch free, all of this on the first attempt! I then proceeded to repair it with CueTools and it managed to verify afterwards.

What does CueTools actually repair?

This post has been edited by themanuel: Mar 25 2013, 17:59

[eleria]

@korth Ah, I'm relieved. Thanks for the quick replies :3
I'm a bit new to CueTools it's only been like 6 rips, so of course I didn't check what's in the accurip

This post has been edited by eleria: Mar 25 2013, 17:44

[korth]

Can either CueRipper or CueTools be used in single file mode, or do I have to do all operations on all tracks always?

Assuming you meant single track. CUERipper can only rip entire discs. It cannot rip just one or two tracks. CUETools is also designed to work on the entire disc rip, not just one or two tracks.

What does CueTools actually repair?

The CTDB stores a very small recovery record similar to PAR2. See also CUETools_Database. (Some of the text isn't up to date but the general idea is the same. I'll update it this week.)

I'm a bit new to CueTools it's only been like 6 rips, so of course I didn't check what's in the accurip

Don't forget to look over the wiki pages.

This post has been edited by korth: Mar 25 2013, 19:22

[themanuel]

Assuming you meant single track. CUERipper can only rip entire discs. It cannot rip just one or two tracks. CUETools is also designed to work on the entire disc rip, not just one or two tracks.

I see. Thanks for your answers. The reason I asked about single track ripping is because with EAC, sometimes I could not get a track or two to verify with the first attempt but a second ripping attempt would get it right. This would happen because I would change the ripping mode, or simply a second shot at the same ripping mode. It was a painful iterative process with some tracks on some CD’s, but it would have been worst if I had to re-rip the entire disc on each attempt.

Is this not necessary with CueRipper?
If I can’t get a track to verify the first time, no amount of retries will do it?

[korth]

You can change the extraction method but you have to re-rip the entire disc. See Extraction method. On scuffed or scratched discs, I use Paranoid.

[themanuel]

Thanks. I'll keep playing with CueRipper to understand its capabilities, but I like it already.

[Lazlo Nibble]

Is there (or will there soon be) a way to get ArCueDotNet.exe to output the full "detailed" log with the CTDB information?

[Gregory S. Chudo...]

Is there (or will there soon be) a way to get ArCueDotNet.exe to output the full "detailed" log with the CTDB information?

 ArCueDotNet.exe.zip ( 2.49K ) Number of downloads: 22

[themanuel]

Is there any way I can add album artists as a tag when ripping with CueRipper?

[Gregory S. Chudo...]

It is supposed to just work. I mean, if you specify track artists different from album artist.