Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1893715 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1075
Quote
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1076
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?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1077
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.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1078
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?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1079
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.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1080
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1081
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1082
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: [Select]
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: [Select]
Exception: crc.Combine length cannot be negative
Parameter name: len2


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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1083
Are you sure you are using the latest version (2.0.9)?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1084
yes I'm using 2.0.9

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1085
Ok, confirmed the bug with CDs that have data track in the beginning. Working on it. Thanks.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1086
no prob. Thanks for the support!

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1087
Hey Greg,

Code: [Select]
[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: [Select]
[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!?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1088
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:
Quote
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1089
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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1090
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:

.  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]   

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1091
dalza:
Quote
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.

Quote
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1092
"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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1093
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1094
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1095
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

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1096
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1097
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

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1098
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.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1099
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