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

[lipidicman]

Thanks again Korth. I'm only up to page 9 so far! Trying to take it all in rather than skim.

As I understand it, by doing at least 2 passes it is already doing test and copy. The log file shows both CRCs anyway.

[lipidicman]

With EAC I found this drive can overread. Perhaps I made a mistake, or does CueRipper always set this to 'No'?

Similar question asked and answered. I have a Plextor CDR capable of Overread into Lead-In and Lead-Out. Also No in CUERipper.

More testing of Cueripper.

When I compare against EAC (with overread) some CDs have identical test CRC32 for the last track. This will be because CueRipper is filling up the offset with zeroes, and the missed part contained zeros anyway. My offset is +30. Other CDs do appear to have data to the end.

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

I suppose it might even be a good feature here for those people correcting offsets if you could check that you are only moving zeroes around (although I understand that correcting offsets has no real benefits, I only enter the offset in the main window to alter the offset for a verify to get the ARv2 result if it wasn't corrected properly at rip)

[mjb2006]

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9
(would be simpler if shntool had a "don't write any files" option)

[lipidicman]

Does anyone know of a program which can easily confirm that a FLAC file ends with digital silence?

mkdir tmp9 && shntool.exe trim -d tmp9 -q -e test.flac && echo The file ends with digital silence.
rmdir /q /s tmp9
(would be simpler if shntool had a "don't write any files" option)

Clever, but I wasn't thinking straight this morning. "Fill up missing offset samples with silence : Yes" will stop me from testing this way.

I'm testing CueRipper results against EAC. EAC overreads into the lead out with my PLEXTOR DVDR PX-716A (+30 offset)

Am I just being picky wanting my last track CRC32 to match what I get when I run EAC test in burst mode? It usually does because the last 30 samples are usually digital silence.

I'm just regarding the CRC32 as being superior to the (flawed) AR CRC (and even the v2 has flaws right?). Isn't this why Gregory uses CRC32? Am I wrong here?

Coming soon: How I Learned to Stop Worrying and Love the Rip

[korth]

I thought you already figured out that a few leading and trailing samples were removed from the CTDB CRC because drives with different offsets and no overread capability will produce different data in those areas. The link points to a discussion about the localDB but the two are similar.
AR CRCs are also calculated with a few leading samples from the first track and a few trailing samples from the last track removed.
I guess I don't have the same obsession for a possible 30 samples (0.00068 seconds) of inaudible digital noise at the end of the disc if the rest of the disc verifies.

This post has been edited by korth: Feb 18 2012, 21:09

[lipidicman]

Yes, I know about how AR and CTDB drop the start and end (5 and 10 sectors). I'm not really worried about those last few samples in my rips. What I am doing is testing my CueRipper rips against EAC results. The only way I have to do this is to use the full CRC32 from the EAC log. As I understand it CRC is less robust (hence why Gregory uses CRC32), and ARv1 is further flawed (hence ARv2).

I guess I'm trying to check if I have one of these errors in EAC, or drive bugs, that I keep hearing about. Greynol might be able to point me in the right direction here. I figured that using two drives and two bits of software would flush any problems out.

It's the scientific training.....just a few more checks and then I'll be happy

I do think that checking for digital silence could be implemented when people are correcting offsets in CueTools. I know it has no real benefit to correct the offset and the downside is losing more samples. But if you check for zeroes, then the downside vanishes.

[lipidicman]

Just finished ripping 80 cds to discover:

Used drive : PLEXTOR DVDR PX-716A Adapter: 1 ID: 0
Gap handling: Not detected, thus appended to previous track



Now, I understand that this does not affect the FLACs, but means my cuesheet will have no Index 00. Other than the negative numbers on a burnt CD there are no bad consequences are there? I read this guide to gaps years ago

I do think the program should warn if it fails gap detection

A couple of other issues.
1) I had a problem where unique didn't work (may have been my fault as I had manually renamed the directory to remove an extraneous 'disc1') and the program simply overwrote the files without asking. Is this the expected behaviour?
2) I'm trying my other drive in the light of the gap detection. I see a changed CTDB confidence. Should I get this increase as a result of my own re-rip? Is it the change of drive?

This post has been edited by lipidicman: Feb 19 2012, 00:10

[lipidicman]

Just finished ripping 80 cds to discover:

Used drive : PLEXTOR DVDR PX-716A Adapter: 1 ID: 0
Gap handling: Not detected, thus appended to previous track

Strange, this is not consistent. Out of 80 cds, 4 were not detected (consistently, with several retries) although one has just had the gaps detected where they weren't before.

This may not be CueRipper though. I think I recall problems with EAC, although my recollection is that EAC would hang during detection. This was a long time ago though, so I could be wrong.

[Goratrix]

Other than the negative numbers on a burnt CD there are no bad consequences are there?

This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).

[lipidicman]

Other than the negative numbers on a burnt CD there are no bad consequences are there?

This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).

I always think you need to be careful. Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.

[Goratrix]

Other than the negative numbers on a burnt CD there are no bad consequences are there?

This is correct. You really shouldn't be worrying about gaps, as long as you use a proper method of handling them (i.e. either rip to image or rip to tracks with gaps appended).

I always think you need to be careful. Back before Accuraterip, most people said you didn't need to worry about pregaps and data tracks.

HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.

[lipidicman]

HTOA and data tracks are part of the data in a disc, so if someone left those out, he left out a part of the disc. But pregaps (INDEX 0) are a different case, they are just markers.

Yes, of course I agree.

[korth]

Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection

That is how the program notifies you [link]

[lipidicman]

Gap handling: Not detected, thus appended to previous track
I do think the program should warn if it fails gap detection

That is how the program notifies you [link]

Cheers korth. It is no problem now that I know this. I looked once I got to that post.

Again, this is a documentation issue. I think I'll make an account for the Cuetools wiki.

And I'm happier now that I see it wasn't all the rips I had completed.

[pontomedon]

I hope this is the right place to ask - I have the following problem: I ripped a CD (The Lion King OST) in EAC, resulting in a few errors in one track, every other track was verified OK by AccurateRip:

CODE

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

EAC extraction logfile from 23. February 2012, 20:09

Various / The Lion King OST

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

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

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

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:59.67 | 0 | 17991
2 | 3:59.67 | 2:50.73 | 17992 | 30814
3 | 6:50.65 | 3:40.15 | 30815 | 47329
4 | 10:31.05 | 3:33.50 | 47330 | 63354
5 | 14:04.55 | 2:57.52 | 63355 | 76681
6 | 17:02.32 | 2:55.33 | 76682 | 89839
7 | 19:57.65 | 4:17.50 | 89840 | 109164
8 | 24:15.40 | 3:45.17 | 109165 | 126056
9 | 28:00.57 | 5:59.05 | 126057 | 152986
10 | 33:59.62 | 4:51.50 | 152987 | 174861
11 | 38:51.37 | 3:36.73 | 174862 | 191134
12 | 42:28.35 | 3:59.45 | 191135 | 209104


Range status and errors

Selected range

Filename Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.wav

Suspicious position 0:41:22
Suspicious position 0:41:26

Peak level 98.3 %
Extraction speed 9.3 X
Range quality 99.6 %
Copy CRC 201635C8
Copy finished

There were errors


AccurateRip summary

Track 1 accurately ripped (confidence 5) [8F75F0CE] (AR v2)
Track 2 accurately ripped (confidence 5) [B94FCBF7] (AR v2)
Track 3 accurately ripped (confidence 5) [057830A9] (AR v2)
Track 4 accurately ripped (confidence 5) [9072E0B2] (AR v2)
Track 5 accurately ripped (confidence 5) [45BC209F] (AR v2)
Track 6 accurately ripped (confidence 5) [69A80D86] (AR v2)
Track 7 accurately ripped (confidence 5) [CEFBBEB7] (AR v2)
Track 8 accurately ripped (confidence 5) [54A17B6F] (AR v2)
Track 9 accurately ripped (confidence 5) [377CD6A5] (AR v2)
Track 10 accurately ripped (confidence 5) [5942A28C] (AR v2)
Track 11 cannot be verified as accurate (confidence 94) [AC42013C], AccurateRip returned [47CF4212] (AR v2)
Track 12 accurately ripped (confidence 5) [B2C61F12] (AR v2)

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

Some tracks could not be verified as accurate

End of status report

---- CUETools DB Plugin V2.1.3

[CTDB TOCID: V1WRWT9HKBEErwwrV9RGpqqiZP8-] found, Submit result: V1WRWT9HKBEErwwrV9RGpqqiZP8- has been submitted
[fc6cb270] (162/168) Differs in 9300 samples @41:20:11-41:20:12,41:20:28-41:20:29,41:20:44-41:20:45,41:20:61-41:20:62,41:21:02-41:21:03,41:21:19-41:21:20,41:21:35-41:21:36,41:21:52-41:21:53,41:21:68-41:21:69,41:22:10-41:22:11,41:22:26-41:22:27,41:22:43-41:22:44,41:22:59-41:22:60,41:23:01-41:23:02,41:23:17-41:23:18,41:23:34-41:23:35,41:23:50-41:23:51,41:23:67-41:23:68,41:24:08-41:24:09,41:24:25-41:24:26,41:24:41-41:24:42,41:24:58-41:24:59,41:24:74-41:25:00,41:25:16-41:25:17,41:25:32-41:25:33,41:25:49-41:25:50,41:25:65-41:25:66,41:26:07-41:26:08,41:26:23-41:26:24,41:26:40-41:26:41,41:26:56-41:26:57,41:26:73-41:26:74,41:27:15,41:27:31-41:27:32,41:27:48,41:27:64-41:27:65,41:28:06,41:28:22-41:28:23
[d03a4fda] (001/168) No match
[557785fe] (001/168) No match
[8036c248] (001/168) No match
[e23534ca] (001/168) No match
[523a016f] (001/168) No match
[9d808615] (001/168) No match
You can use CUETools to repair this rip.

I've never used CUETools before, but i wanted to give it a try to repair the rip. When i load the cue file, and run the encode mode with the repair script selected it verifies the tracks and then stops with the message

CODE

Y:\Audio\Trans\Various - The Lion King OST\Various - The Lion King OST.cue: differs in 9300 samples, confidence 163, or verified OK, confidence 1.

Sounds like there are multiple entries in the CTDB database, i might even have uploaded the incorrect one myself, as EAC states "has been submitted" in the log. Is there a possibility to repair the rip?

[lipidicman]

Is there a possibility to repair the rip?

It looks like you are getting the batch mode log, select the cue sheet before you click go. Cuetools should then ask you which entries in CTDB you want to use for the repair.

I've also had a few issues where I've had to ask it to repair several times. Initially it goes through the verify and stops, then the next time it works and I'm not sure why. Someone else might be able to shine some light on this.

[pontomedon]

Ah thank you, i was using the batch mode, it worked now.

This post has been edited by pontomedon: Feb 24 2012, 12:48

[lipidicman]

Ah thank you, i was using the batch mode, it worked now.

Glad to help. I've only been using CueTools for a week and I've been doing all the asking until now.

[BrassDude]

I'm using the latest version of CUETools 2.1.2a for verifying my rips and populating the CTDB. I found a problem with multi-disc albums that have 5 or more discs if each disc is ripped into multiple tracks. CUETools nicely detects the individual discs if the files are propperly tagged - but only to a maximum of 5 discs. If there are more than 5 disc for that album, all the remaining tracks are grouped in one big disc - the 5th one. Is there a parameter that I can set (max. discs) or is this a bug? Of course if each disc is ripped into a single flac file then there is no problem with the multi-disc albums.

[korth]

You can switch Input to Multiselect Browser and select cues for more than 5 discs. Detection (as you put it) does max out at 5.

This post has been edited by korth: Mar 3 2012, 20:06

[BrassDude]

Thanks for your help korth. Can you be a bit more specific - I didn't really understand and see where I can switch to Multiselect Browser.

Also why is this magic number 5 hardcoded? There are many album box-sets out there with definitely more than 5 discs. Maybe that could be a parameter in a future version that one could set under the options. :-)

[korth]

See the down arrow after Input:? Click on it.

Also why is this magic number 5 hardcoded?

That I can't answer. Only know it from my own usage. Gregory seems quite busy the past few months so I just help out when I can answer a question.

[Porcus]

I know I am replying to some > 3 year old post , but, concerning AccurateRip retro-verification:

i'm still quite pessimistic about the possibility of recovering an album structure, when tracks were split. Ok, we can sacrifice that split track and focus on verifying other tracks, but for that we have to know for sure it's length.

A suggestion for the case where a cuesheet is absent:
(I) Check files for ACCURATERIPID tags. Then users who use CUERipper, will be able to retro-check AR status later, without the cuesheet (and users who read this forum, could very often get the impression that cuesheets are only useful for writing back a copy ...)
(II) Check files for AccurateRipDISCId tags (my emph.). dBpoweramp writes those. CUERipper and dBpoweramp users are a minority compared to EAC users, but if you consider (I) to be worthwile support for CUERipper users, it should be hardly much effort to do dBpoweramp's tag as well.
(III) Could CDTOC be used the same way? MusicBrainz IDs?


(... 72 pages and counting ... if you could even find information in this thread, you wouldn't know if it is up-to-date :-o )

[jensend]

I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?

[lipidicman]

I'm aware that this goes somewhat against the grain of the point of CueTools, but is there any way one can use CueRipper to rip just select individual tracks rather than a full CD?

Because of the way accuraterip works, I would rip the whole CD in track mode then just grab the tracks I wanted. Or you could use EAC.