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

[Gregory S. Chudo...]

CUERipper always does at least two passes in secure mode. If results from those two passes differ, or the drive reports C2 errors, it does more passes, and the error correction progress bar lights up. If the problem persists, it eventually marks suspicious positions in the log file. But it is not collecting separate CRCs for those passes, because some parts of a track can be read twice while other parts can be read many times.

So before version 2.1.4 it just printed the same CRC twice. It was pointed out to me that this is misleading, because some people actually like to compare CRCs with their own eyes, so 2.1.4 just prints one CRC unless you check 'Test & Copy', in which case it now collects two sets of CRCs by reading the whole CD twice, doing at least two passes each time, so every sector is read at least 4 times.

I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy), or if i expect problems ripping a certain CD and don't mind waiting a bit longer, i use Paranoid mode (which reads every sector at least 3 times). This is usually faster than test&copy in secure mode, but has a better chance of doing a perfect rip.

Unlike Paranoid mode, Test&Copy doesn't increase your chances of getting an accurate rip, so i guess the only reason it is so popular is that you can see two sets of CRCs with your own eyes and compare them yourself, instead of trusting the ripper to compare each bit of data from several passes and print out the suspicious positions.

This post has been edited by Gregory S. Chudov: Apr 22 2012, 18:20

[korth]

CUERipper: There still appears to be a problem with EAC style rip log in Paranoid mode.
Just tested Burst mode. Everything was fine. Switched to Paranoid mode, rip was fine, rip log says Burst mode. Even the wav file locations show the folder for previous Burst rip. Restarted CUERipper. Switched to Paranoid mode, rip was fine, rip log says Secure mode. File locations correct.

[Isayama]

I personally find this an overkill, but that's what many people are used to. Personally, i just use default settings (secure mode, no test&copy),...

Thanks a lot, that's exactly the kind of precisions I was waiting for. This does clarify the process and the changes made. Now this question's been figured out, I can resume ripping my CDs without wondering

Cheers

[Pepzhez]

Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.

[NetRanger]

Am I the only one who has encountered a problem with the CUERipper 2.1.4 'Test & Copy' mode? I'm unable to use it. Whenever I have the box checked I get an Exception error: "Gap Detection Failed." It does this with every disc I have tried, using two different drives. CUERipper works perfectly fine if I do not check the 'Test & Copy' box.

I can't think of any logical reason why choosing 'Test & Copy' would cause gap detection to fail, but it does.

'Test & Copy' works just fine here. Have made like 4-5 rips with it.

[NetRanger]

What about getting a 'Medium' option for 'Album art search'. There is only Small and Large available now.

[Gregory S. Chudo...]

CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.

[NetRanger]

CUERipper is not using Google to search images. It uses artwork from Musicbrainz & Discogs, and there are only full size pictures and thumbnails in those databases. However i will consider implementing custom image sizes by downloading full size images, than shrinking them to desired size.

Thnx for the reply/info Gregory.

[NetRanger]

Just noticed that the embedded cover art gets added twice.

[Pepzhez]

'Test & Copy' works just fine here. Have made like 4-5 rips with it.

Very strange problem. I still can't figure out why it's giving me that Exception error. Test & Copy is merely a switch that tells CUERipper to start the ripping process over again after the first cycle is complete. There doesn't seem to be any reason why it would make a difference whether or not I have the switch engaged. Odd.

[radu]

1. I thought that the confidence results are only based on actual rips, but after I verify an rip not present in CTDB with CUETools, next time will have confidence 1. Can you please explain?

2. I got quite a few errors like this:

CODE

.\Joss Stone - 2005-07-08 - Mind Body & Soul\Joss Stone - 2005-07-08 - Mind Body & Soul.cue: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index.

And the accurip log reads:

CODE

[CUETools log; Date: 4/25/2012 8:54:01 PM; Version: 2.1.4]
[CTDB TOCID: YDhmfif05xgrPtNh8.pN4sFhCp8-] found.
        [ CTDBID ] Status
        [eb466f8b] (25/48) Accurately ripped
        [0dd4fda1] (01/48) No match

Is it accurate or not? And why is the log looking like that?

Edit: that's the whole log.

This post has been edited by radu: Apr 26 2012, 01:58

[Gregory S. Chudo...]

1. I haven't disabled CUETools submissions yet, so for CDs that are not yet present in the database any rip with AR confidence >= 2 can be submitted, and will have CTDB confidence == 1 (AR confidence is ignored, but CTDB confidence cannot be zero). Only results with CTDB confidence >= 2 can be considered reliable, which means that CTDB no longer trusts AR, but AR-verified rips need only one independent rip to be confirmed and receive CTDB confidence == 2.

2. Thanks, found a bug in the code that produces detailed CTDB log. This happens when CD has a data track. My advice is turn detailed CTDB log off until i make a hotfix. This option is off by default, so most users don't need to worry.

[radu]

CODE

Index was out of range. Must be non-negative and less than the size of the collection.

So this means that the CD has a data track, it could be a perfectly good rip, but it cannot be verified. Is that correct?

[Gregory S. Chudo...]

Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log

[radu]

Yep. It is perfectly verified. "(25/48) Accurately ripped". Just turn off the detailed option of the log, the standard one is easier to read.
Also refer to this: http://www.cuetools.net/wiki/CUETools_log

Now I got it. I only have that message and the weird log when I use the detailed option.


I want to thank you for all your work you put in the development of CT, I really appreciate it. It is one of the few applications I install the first day I have a new OS.

Thank you.

[SpaceAgeHero]

Hey folks,

I have two questions.

1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.

2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?

Thanks!

:-)

[korth]

1. Is there any way to make CUETools transfer tags 1:1 on conversion? Whenever I convert files, the full value for %date& is truncated. For instance "1995-11-20" is only "1995" after conversion.

CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?

2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?

Untick 'to nearest' in Advanced Options on the AccurateRip tab.

This post has been edited by korth: Apr 30 2012, 13:57

[bilbo]

2. Can I somehow configure CUETools to always fix offsets to the result with the highest confidence?

Why would anyone want to do this? This whole process is to make an accurate copy of your CD. So, you want to go through the trouble of creating an accurate copy and in the final step convert it into an inaccurate copy?

[SpaceAgeHero]

CUETools is getting that info from your cue file or online database. Does your cue file have 1995-11-20?

Yes. I have all my music stored as FLAC images where the CUE sheets are embedded though.
The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".
I've made some tests with different settings in the tagging menu.
However either the date is truncated, or it is copied completely - but then the disc number info is missing.

Untick 'to nearest' in Advanced Options on the AccurateRip tab.

Thanks! :-)

[korth]

The embedded CUE sheet has the value as shown here: "REM DATE 1995-11-20".

OK that helps a little. Using the embedded cue only, it does appear that CUETools reads the date correctly, will use it as %DATE% everywhere else (templates, cue, embedded cue) but does not write it to the tags if split into tracks (date is blank if more than 4 digits). So if you're converting to tracks, I won't be able to help with settings unless Gregory wants to change this.

[mthomas1]

I've been an EAC user and recently started working with CUERipper. I really like the speed of the ripper. One downside, however, is the metadata. I really like having access to the GD3 database in EAC. I find it often has CDs that aren't in musicbrainz and the quality of the metadata (especially the higher res images) seems better. Andre seems to have worked out a really cheap lifetime license for EAC users to get access to GD3. Do you think it would be possible to add this to CUERipper?

[Gregory S. Chudo...]

I'm not sure about obtaining cheap lifetime licenses, but it shouldn't be difficult to add support for GD3 to CUERipper for users who purchase their your own licenses.

On the other hand, i'm not sure i want to promote proprietary solution when we have decent open alternatives, i would rather work on improving integration with musicbrainz.

[NetRanger]

When using 'EAC style log' in CUERipper, should it not say 'CUERipper extraction log' on the 2nd row of the log instead of 'EAC extraction log'?

[korth]

Does it not say 'CUERipper' on the top line of the page? Everything below that mimics the EAC logfile and should tell us so.
'EAC-style extraction logfile' maybe.

[NetRanger]

Just because the option say 'EAC style log' doesn't mean it have to say EAC in a CUERipper log or?