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

[ChronoSphere]

If CUETools says it's HDCD, it most certainly is

It doesn't really make sense for it to be a HDCD when the first CD isn't; the first CD contains the songs with vocals, the second only contains some of the songs w/o vocals + some tracks that didn't make it to the soundtrack.

This post has been edited by ChronoSphere: Jun 22 2010, 22:24

[ChronoSphere]

Can't seem to edit my last post for some reason...

I just re-viewed the log cuetools created and it did detect the first cd as hdcd too. I must have been really tired when I checked it the last time.

edit: I have a question about offset correction: is it safe to do it? Does it affect something audible or is it simply for having a cue that is closer to the original?

This post has been edited by ChronoSphere: Jun 25 2010, 22:27

[Gregory S. Chudo...]

I have a question about offset correction: is it safe to do it? Does it affect something audible or is it simply for having a cue that is closer to the original?

It is relatively safe, that's exactly what EAC does when your drive has non-zero offset and is not capable of overreading (most drives aren't). You can loose only as many samples as the offset, i.e. few milliseconds at one of the edges of the disc. However, there's not much point in doing this. EAC does it to be able to use it's primitive AccurateRip implementation, but CUETools can verify non-offset-corrected rips, so there's really no point. Unless you want to burn a CD-R and want it to be non-distinguishable from the original CD, and you didn't use offset correction when you ripped it, or you want to use a burning program that is incapable of offset-correction for write-offset.

[ChronoSphere]

I see. What about my post on the previous page? Any idea why CueTools submits rips to the CTDB despite saying itself that they are not accurate?

[Gregory S. Chudo...]

Presumably that's because there's a slight discrepancy in two ways CUETools determines if the rip is accurate.
If it was really inaccurate, the message would read 'rip not accurate, (0/2)', not (2/2).
I wasn't able to reproduce such case yet, but my guess is that each track is accurate, but not within the same offset.
Such rip shouldn't have been submitted, i will correct this.

[Zetto]

When I try to convert or verify via commandline I get this:

Processing XYZ.cue:
Error: Object reference not set to an instance of an object.

[Akkurat]

The profile/settings system is still buggy and not fixed/redesigned (check my notes from January (perhaps the 11th point in the codebox list)), that's what most probably is causing the error.

[Zetto]

thanks, that helped.

I get another error when verifying a rip with a data track as track 1.

When I verify with the cue I get:

CODE

Exception: Invalid track number.

Well, that's most likely because track 01 (the data track) isn't referenced in the cue. it starts with track 02.

But why do I get the following error:

When I verify with the audio files as input I get this:

CODE

Exception: crc.Combine length cannot be negative
Parameter name: len2

It runs through until the very end until that error pops up.

This post has been edited by Zetto: Jun 28 2010, 23:31

[Gregory S. Chudo...]

Are you sure you are using the latest version (2.0.9)?

[Zetto]

yes I'm using 2.0.9

[Gregory S. Chudo...]

Ok, confirmed the bug with CDs that have data track in the beginning. Working on it. Thanks.

[Zetto]

no prob. Thanks for the support!

[SpaceAgeHero]

Hey Greg,

CODE

[CUETools log; Date: 29.06.2010 18:54:15; Version: 2.0.9]
[CTDB TOCID: ddtaskdPyyRBfBOJeWntybiAIDI-] found.
        [ CTDBID ] Status
        [438774b6] (12/12) Has pregap length 00:00:32
[AccurateRip ID: 00091292-002c06df-350b9705] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL]
--   99,6 [904E2FF5] [8161D8C5]          
01   99,6 [5EF4CF04] [CDEB36BC]          
02   99,6 [9665242D] [B0708154]          
03   99,5 [E383ED8C] [2A6F4929]          
04   99,6 [604AC167] [BF52E65F]          
05   99,6 [63648CD3] [24AA0426]

CUETools has detected that this rip normally has a pregap length of 00:00:32 even though I have no CUE sheet for this anymore.
But it doesn't clearly show that the rip is accurate. Also the AccurateRip ID seems to be calculated wrong!

I know that the right ID here is 00091352-002c097e-390b9705.
So if I add this as ACCURATERIPID tag to my files, everything is fine, even though there still is no pregap information!

CODE

[CUETools log; Date: 29.06.2010 18:59:21; Version: 2.0.9]
Using preserved id, actual id is 00091292-002c06df-350b9705.
[CTDB TOCID: ddtaskdPyyRBfBOJeWntybiAIDI-] found.
        [ CTDBID ] Status
        [438774b6] (12/12) Has pregap length 00:00:32
[AccurateRip ID: 00091352-002c097e-390b9705] found.
Track   [ CRC    ] Status
01     [7302cda8] (15/15) Accurately ripped
02     [7cb47b43] (15/15) Accurately ripped
03     [ffe08507] (15/15) Accurately ripped
04     [c7acc227] (14/14) Accurately ripped
05     [86577805] (15/15) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
--   99,6 [904E2FF5] [8161D8C5]          
01   99,6 [5EF4CF04] [CDEB36BC]          
02   99,6 [9665242D] [B0708154]          
03   99,5 [E383ED8C] [2A6F4929]          
04   99,6 [604AC167] [BF52E65F]          
05   99,6 [63648CD3] [24AA0426]

Personally I don't care much about gaps and pregaps, I only want accurate audio tracks but I still wanted to report this.
Not sure if this is a bug!?

[radu]

Hi,

Thanks for the tool, it's VERY useful.

I would like a more detailed CUETools log:

1. instead of: [AccurateRip ID: 0022e065-018b7275-da0ed20f] found. -> [AccurateRip ID: 0022e065-018b7275-da0ed20f]: rip accurate (70/70) or rip not accurate
2. if the cue file is invalid or corrupt put in the log the same message that is output as on the screen. (e.g. unable to locate the audio files.)
3. if the cue file is invalid, get past it and try to check the files as there was no cue at all.
4. if there is no cue: put that info into the log.
5. add the info from the CUETools DB page:

TOC ID GkJJuhhILfFRrKunU6io4JUkLB0-
CRC32 ID BC01CDF1
Musicbrainz ID AXEyRA3OelAz7XpuJINN4eoZqJo- (-)
CDDB/Freedb ID
6608A909
AccurateRip ID 000b4a46-00549711-6608a909
Artist YMCK
Title YMCK SONGBOOK -songs before 8bit-

6. Any other information you can think of would be more than welcomed.

Thank you.

[sauvage78]

Hi Greg,
I found a sub-optimal CT behavior, I wouldn't call this a bug, but for the first time I tried to "encode/fix offset/highest confidence" on an enhanced CD with no log but for which I know that it is in CTDB with the good data track length. I would have expected Cuetools to grab the data track length from CTDB & then "fix" the offset, instead of that CT didn't even checked CTDB & returned not present in AR database ;( ... so it seems that depending on the chosen options the automatic grabbing of the data track length from CTDB doesn't always work. I know the box for CTDB is only there for the "verify" option, but in this case it would be usefull for the "encode" option.

Not a priority, but still I wanted to point this out.
See Ya Next Bug

This post has been edited by sauvage78: Jul 3 2010, 18:53

[dalza]

Hello. I am new to ripping cds and just discoverd CUETools. The reason why I am using this program is to verify that files ripped to FLAC before I started using DBPoweramp are Accurately Ripped. If I understand correctly, this is possible with CUETools.

I downloaded the program and verified a cd already ripped to FLAC. Here are the settings I used to Verify:




Advanced Settings:



My first set of questions is about the settings I selected. There are many actions in the Advanced Settings AccurateRip tab that I do not understand:

1) Under “Verify”, If I select “Write AccurateRip tags” what does this do?
2) Should I check the “Encode if verified” box? What does this do?
3) What does “fix offset “ do?

As you can tell, I’m a complete newbie and confused by all of these options . My end goal is to have a “perfect” FLAC file. Any recommended settings would be greatly appreciated.


My second question is about interpreting the CUETools log file that was generated using the above settings. Here it is. My question is pretty simple, What does all this garble mean? Sorry for being obtuse, but I don’t get it.

I would appreciate any and all help from forum members who are familiar with how CUETools works. Thanks in advance.
David (CUETools log below)


[CUETools log; Date: 03/07/2010 18:26:49; Version: 2.0.9]
[CTDB TOCID: 95rD6_gaJlQ702Uih.7d4KcJWQI-] disk not present in database.
[AccurateRip ID: 000f830c-0087f90e-9e095e0b] found.
Track [ CRC ] Status
01 [ff3f3996] (10/83) Accurately ripped
02 [e4793440] (10/84) Accurately ripped
03 [b8efbe8d] (10/83) Accurately ripped
04 [c01b811d] (10/83) Accurately ripped
05 [43181ce7] (10/86) Accurately ripped
06 [de75205e] (10/82) Accurately ripped
07 [9e56391d] (10/83) Accurately ripped
08 [7febe9c3] (10/81) Accurately ripped
09 [18f874a2] (10/82) Accurately ripped
10 [6579da7a] (10/81) Accurately ripped
11 [3d350037] (09/78) Accurately ripped
Offsetted by -139:
01 [225989a9] (02/83) Accurately ripped
02 [834c65a5] (04/84) Accurately ripped
03 [b1bd302b] (03/83) Accurately ripped
04 [63ef226e] (03/83) Accurately ripped
05 [3d01e358] (04/86) Accurately ripped
06 [5df4efbd] (03/82) Accurately ripped
07 [f54a9f42] (03/83) Accurately ripped
08 [8f9ed44f] (03/81) Accurately ripped
09 [36c516f8] (03/82) Accurately ripped
10 [5c43ae7c] (03/81) Accurately ripped
11 [1b372a50] (03/78) Accurately ripped
Offsetted by -3:
01 [659c0e34] (04/83) Accurately ripped
02 [4d0f8f1b] (04/84) Accurately ripped
03 [8aced1ad] (04/83) Accurately ripped
04 [0f277056] (04/83) Accurately ripped
05 [e508e640] (04/86) Accurately ripped
06 [b34392f3] (04/82) Accurately ripped
07 [2959386c] (04/83) Accurately ripped
08 [85c9192f] (04/81) Accurately ripped
09 [9a88d7e8] (04/82) Accurately ripped
10 [7d38394c] (04/81) Accurately ripped
11 [2806a41a] (04/78) Accurately ripped
Offsetted by 32:
01 [8063f331] (03/83) Accurately ripped
02 [dee9cb4b] (03/84) Accurately ripped
03 [f9edf282] (03/83) Accurately ripped
04 [ca46debd] (03/83) Accurately ripped
05 [2e650e87] (03/86) Accurately ripped
06 [1b280735] (03/82) Accurately ripped
07 [d3f73cfa] (03/83) Accurately ripped
08 [415f4543] (03/81) Accurately ripped
09 [5d9efc62] (03/82) Accurately ripped
10 [12e091ba] (03/81) Accurately ripped
11 [07addc46] (03/78) Accurately ripped
Offsetted by 106:
01 [de390f34] (03/83) Accurately ripped
02 [fa7ece3c] (03/84) Accurately ripped
03 [bc8518f7] (03/83) Accurately ripped
04 [81cb273f] (03/83) Accurately ripped
05 [3e86fd49] (03/86) Accurately ripped
06 [8dfb43e1] (03/82) Accurately ripped
07 [6ea03332] (03/83) Accurately ripped
08 [b0ba08db] (03/81) Accurately ripped
09 [8c60164e] (03/82) Accurately ripped
10 [73de197e] (03/81) Accurately ripped
11 [faa3d39b] (03/78) Accurately ripped
Offsetted by 210:
01 [6c37ed60] (05/83) Accurately ripped
02 [134e1fc0] (05/84) Accurately ripped
03 [4cef6c4b] (05/83) Accurately ripped
04 [22d81787] (05/83) Accurately ripped
05 [fb410e91] (05/86) Accurately ripped
06 [954a1ac6] (05/82) Accurately ripped
07 [636725a1] (05/83) Accurately ripped
08 [e570f23b] (05/81) Accurately ripped
09 [ab7d4f7e] (05/82) Accurately ripped
10 [e76bed0e] (05/81) Accurately ripped
11 [16692efd] (05/78) Accurately ripped
Offsetted by 322:
01 [2e086f82] (06/83) Accurately ripped
02 [3d8b21c7] (06/84) Accurately ripped
03 [b9a06a54] (06/83) Accurately ripped
04 [466fdf37] (06/83) Accurately ripped
05 [b2ce5c41] (06/86) Accurately ripped
06 [166751bf] (06/82) Accurately ripped
07 [77696594] (06/83) Accurately ripped
08 [0a84b27b] (06/81) Accurately ripped
09 [1bc42a9e] (06/82) Accurately ripped
10 [c6536e6e] (05/81) Accurately ripped
11 [da306141] (05/78) Accurately ripped
Offsetted by 404:
01 [885064e3] (03/83) Accurately ripped
02 [5e841d80] (03/84) Accurately ripped
03 [591f1a99] (03/83) Accurately ripped
04 [807eff21] (03/83) Accurately ripped
05 [bdc3876b] (03/86) Accurately ripped
06 [14576ada] (03/82) Accurately ripped
07 [ff07d415] (03/83) Accurately ripped
08 [6a3c4cf3] (03/81) Accurately ripped
09 [9baee67a] (03/82) Accurately ripped
10 [92aaa402] (03/81) Accurately ripped
11 [b33833d4] (03/78) Accurately ripped
Offsetted by 583:
01 [4fcdd808] (47/83) Accurately ripped
02 [372608ff] (46/84) Accurately ripped
03 [8a83be4f] (46/83) Accurately ripped
04 [696192d8] (46/83) Accurately ripped
05 [a9f9ef02] (48/86) Accurately ripped
06 [8dc076c7] (45/82) Accurately ripped
07 [10757bc0] (46/83) Accurately ripped
08 [0c5994c7] (44/81) Accurately ripped
09 [13b26dd4] (45/82) Accurately ripped
10 [b4a13510] (45/81) Accurately ripped
11 [c2ecdaf4] (43/78) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL]
-- 97,7 [17F26069] [E1009768]
01 97,7 [892C8A27] [5691D5C3]
02 97,7 [F0EFA722] [5D1F4396]
03 97,7 [28B74073] [0EF429AF]
04 97,7 [4EA94D9A] [F4E2F878]
05 97,7 [F35D9F86] [8826FF3A]
06 70,3 [E2ED01A2] [0507905C]
07 97,7 [82FFCD3C] [4C2F1FE9]
08 97,7 [3FC39BF3] [E72698BA]
09 97,7 [DCB3F1A2] [2358F3F3]
10 97,7 [351C6CEF] [71CE4EA8]
11 97,7 [AACB5D37] [2BC520A4]

[sauvage78]

dalza:

1) Under “Verify”, If I select “Write AccurateRip tags” what does this do?
2) Should I check the “Encode if verified” box? What does this do?
3) What does “fix offset “ do?

Pretty much all the options you asked does what it says it does, so you need to do some serious reading, anyway it's a sunny sunday here & I am in a good mood, so here is some short answers:
1, I don't use this option but I think it must write a specific tag with the confidence level, maybe for use with F2K.

Edit: Both 2 & 3 are parameters for "Encode/If verified" & "Encode/Fix Offset" options on the main CT screen.

2, Well just as it says: it encodes only if the rip is verified accurate, you can rise or lower the requirement.
3, Well just as it says: it "fixes the offset" either to the nearest offset (no matter confidence) (tick) or to the highest confidence (no matter offset) (untick), this is usefull if you didn't set the offset while ripping for "nearest" or usefull if you want shorter/easier to read logs for "highest" ... anyway both are useless if you only care for audio quality. Those are mostly .accurip display options.

What does all this garble mean?

It means your rip is perfect. (Tip: use Codebox to post long logs)

Have a nice sunny Sunday. See Ya.

This post has been edited by sauvage78: Jul 4 2010, 12:43

[Zetto]

"Write AccurateRip tags" does just what is sais. Writing AccurateRip tags to your checked files.

Following tags are written:

ACCURATERIPCOUNT
ACCURATERIPCOUNTALLOFFSETS
ACCURATERIPCRC
ACCURATERIPDISCID
ACCURATERIPID
ACCURATERIPTOTAL

This post has been edited by Zetto: Jul 4 2010, 14:25

[SpaceAgeHero]

Hey Greg,

I'm back with one more issue with this wonderful tool:

When multiple discs are ripped to tracks and stored in the same folder, CUETools won't recognize anything above disc 5.
When there is also 6 discs or more, all the tracks are shown under disc 5.

[X0R]

This might be a bug, or maybe I misunderstood the script.
If I verify multiple Albums with [%directoryname%\]%filename%-new[%unique%].cue,
if a *.accurip exists inside the folder, CueTools will prompt to overwrite.

-Did I wrongly assume the %unique% variable will prevent the prompt?

Also, If I use [%directoryname%\]%filename%-new[%unique%].cue, & choose ENCODE, with no audio output,
I get a "source & destination path cannot be the same" error.

This post has been edited by X0R: Jul 5 2010, 00:10

[dalza]

Thank you Sauvage78 & Zetto for your quick responses (I'm glad the weather was nice yesterday ) .

Although I think I’m starting to understand this program a bit better, I am still confused by how to set the option to achieve the results I want (and yes, I did already read through most of this topic’s 44 pages!).

Let’s say I start with a FLAC files on my computer; for example the Fleetwood Mac Album.

My goal is to verify that the rip I have is “perfect” (accurate). So, I run the “Verify” function and get the log report posted above. Now, I have to interpret the results. This is where I am having some difficulties.

The first set of info in the log is:

Track [ CRC ] Status
01 [ff3f3996] (10/83) Accurately ripped
02 [e4793440] (10/84) Accurately ripped
03 [b8efbe8d] (10/83) Accurately ripped
04 [c01b811d] (10/83) Accurately ripped
05 [43181ce7] (10/86) Accurately ripped
06 [de75205e] (10/82) Accurately ripped
07 [9e56391d] (10/83) Accurately ripped
08 [7febe9c3] (10/81) Accurately ripped
09 [18f874a2] (10/82) Accurately ripped
10 [6579da7a] (10/81) Accurately ripped
11 [3d350037] (09/78) Accurately ripped

1) This first set results verifies that the FLAC files I tested are accurate, right?
2) So, for Track 1 for example, it is accurately ripped with a confidence level of 10. Is this correct?
3) If this is the case, than I have nothing more to do, correct?

Where I start to get confused is with all of the subsequent sets of info about “Offsetting”. If the first set of information is Accurately Ripped, then for my purposes, all of the other information is extraneous… I don’t have to worry about it. Is this correct?

I hope my questions are clear. At this point, my only goal is to verify that the FLAC files I have on my computer are bit perfect (accurate).

One more question in anticipation: If I find that a rip I have is not accurate, can CUETools fix it?

Thank you all for your help.

Sincerely,
David

[sauvage78]

dalza:
1, Yes
2, Yes
3, Yes, nothing.
4, Yes, because "a match is a match" & because all tracks are always accurate on each single offset, all the pack of results are pressings that only differs by the offset. In your case, you can "fix" offset from pressing X to pressing Y & still have a perfect match, it's not always the case. In fact in your case you can consider that the confidence level is much higher than 10, because all the pressings are nearly identical. The log looks very long but in fact it is a simple case.
5, If the rip is in CTDB maybe. Note that, because databases are not perfect, a non-accurate result doesn't necessarily means that the rip is bad. AR works more on positive results than on negative results, if it matches with a confidence 2 you can say that it is almost certainly perfect (with the exception of a few samples in the very beginning/end). If it doesn't then you can only make guesses/probability with the overall information provided by all pressings. Sometimes the probability of a scratch is obviously high, sometimes you can't tell.

See Ya.

This post has been edited by sauvage78: Jul 5 2010, 10:23

[dalza]

Sauvage78, thanks again for your help.

In fact, when you say "pressings" do you mean "cd-drive offsets"? Sorry if my question is naive, but I'm still a bit confused.

In any case, thanks for answering all of my questions. I can now get to work verifying the rips I already have and then deciding which disks I have to re-rip/re-buy.

And by the way, thank you to everyone who maintains/improves this great program!

Sincerely,
David

[sauvage78]

By "pressing" I mean physical edition of the CD, those can differ just by the offset due to write offset small shift when "re-pressing" (your case) or more than just by the offset, if the content was edited in some way before being "re-pressed".

In your case, pressings & offsets are "the same", because all pressings only differs by the offset, which means one pressing=one write offset.

I am not speaking of your personnal CD-drive offset, you fixed it while ripping because you match with offset 0.

The machine used to press CD, just like your CD-drive does have different write offsets too, these are the offset you see in the .accurip. For exemple, pressing X with offset +123 may be produced in Europe with a machine with a write offset +123 while pressing Y with offset +321 may be produced in America with a machine with write offset +321 (using the same master).

This is a very theoric simplification, you'll soon realize that there is often more pressings/offsets than possible markets which means compagnies selling CD don't care about the offset, they obviously just re-press when there is a commercial demand, creating lots of pressings that only differs by the offset over the years.

This post has been edited by sauvage78: Jul 5 2010, 11:22

[Revy]

OK, I might be dumb but I tried everything I can imagine, and CUETOOLS doesn't work with me, when I try to open it says "CUETOOLS HAS STOPPED WORKING". Nothing more.

I use windows 7 64bits, I tried to download .net framework 2.0 but it seems windows 7 already includes that (installer says it).
I have installed framework 4.0 too. C++ 2005/2008/2010 were already installed before I downloaded cuetools.

If it helps the only cuetools I can seem to open is the experimental one (2.0.2a)

EDIT2: Tried to use the debug function in VS2010 and... Exception has been thrown by the target of an invocation. {"Font 'Courier New' does not support style 'Regular'."} I didn't have courier new installed somehow and the program crashes because of that. Reinstalled the font and problem solved. Might want to work around that font demand so it won't crash

This post has been edited by Revy: Jul 5 2010, 18:00