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

[korth]

I would rather advise users to go to http://www.cuetools.net/wiki/ (And then perform a couple of searches, and then ask.)

I had assumed B00ze would use the search feature to look up answers to specific questions as I did in the example.

[db1989]

How can I split the image with this cue sheet?
[snip]
The gaps look very odd, and I get this error: 'Exception: Indexes must be in chronological order' error.

JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.

It’s never too late! I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which won’t affect splitting or the audio itself anyway.

[JeanV]

JeanV, you need to use codebox tags when posting logs, etc., so they appear in a scrollable section. Too late now.

What did you use to generate that cue sheet? Or did you just "find" it somewhere? It's damaged beyond repair.

The timestamp after each INDEX ## is supposed to be a position (minutes:seconds:frames format) within most recently mentioned audio FILE (or whichever file you're forcing the cue sheet to be used with). So track 10 index 01 begins at 33:54:45 and track 11 index 01 begins at 38:09:18 ... probably correct. But this means it is nonsensical for track 11 index 00, which is in between, to be at 13:35:66. The story is the same for all the other index 00s.

For splitting, you really only need the index 01s (because you're splitting on track boundaries, and for this disc there's no track 01 index 00 to worry about). So to "fix" the cue sheet, you could delete the INDEX 00 lines, and then it should "work". It no longer represents the original CD, but in this case, that's not a change from the status quo. It didn't represent the original CD properly anyway

If you were to use the cue sheet with the index 00s deleted to burn a copy, the resulting CD-R will be mastered with no 'gaps' (places where you see the cd player count from a negative time up to 0:00 at the end of each track). The audio and the main track boundaries will be OK.

It’s never too late! I agree with your conclusions that the INDEX 00 values are nonsensical, so they should just be removed, which won’t affect splitting or the audio itself anyway.

Many thanks, mjb2006 and db1989, sorry for missing the codebox tag.

I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 - #142) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?

[db1989]

There’s only one way to find out. It’s certainly a possibility. Maybe we should’ve thought of that!

[korth]

I also thought that deleting the INDEX 00 lines might be the only way to go, but then found these two posts (#140 - #142) in the forums, which suggest changing the Gap/Index retrieval method (and I don't know what that is) might fix the gaps. Could the cue sheet be rectified doing so?

In EAC, having the wrong Gap/Index retrieval method can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.

This post has been edited by korth: Dec 19 2011, 18:04

[JeanV]

In EAC, having the wrong Gap/Index retrieval method can result in "strange" gaps. You didn't specify how your cue was created. Post(s) #139-142 are referring to a cue created using EAC.

Ah, so that's got to do with EAC and how the rip was done beforehand. Now, deleting the INDEX 00 lines is the best bet for me. Thank you. :-)

This post has been edited by JeanV: Dec 19 2011, 18:50

[d3m0n1q_733rz]

I've happened upon a bit of a small (though pretty resource intensive) bug that causes CueTools 2.1.2a to keep the takc encoder open when changing an offset fails. I had an offset that I was attempting to change to a positive number when it said there was an error with the stream not allowing seeking. After the failure, the takc.exe program was left running and still attempting to encode. I ended up with 8 of them slowing down my computer before I finally decided to investigate what was being so resource intensive. So you might want to fix this bug in 2.1.2b. I'm also looking for a way to fix some problems with multiple offsets due to sync errors from other programs. I have different songs come up as being accurate with some offsets (-24) and others coming up as no match found. Is it possible to change the software to base the matches of the unmatched songs upon the accurate results of the songs around them so as to increase recovery of extremely poor rips?
For example, if an offset of -24 results in the greatest number of accurate rip results for most songs, it won't necessarily mean it for all songs so matching the results with samples will be difficult. However, if we allow multiple different offsets (different for each song), it will increase the chance of a repair due to sync errors. So, is it unheard of to so such a thing? I would like to make repairs as simple, automated and intelligent as possible. Unfortunately, this means shifting tracks around (filling the shifts with 0s and making them mostly bad samples) until they mostly fit the CRC and then replacing the bad samples afterward to complete the repair.

Let me know what you think!

[fadsplat]

Windows 7 Home Premium 64-bit
CueTools 2.1.2a

Hi:

I normally use CueTools in Drag 'n' Drop Mode. One of the reasons is i like the wide window which more easily shows the results and summary line after a Verify operation.

I created Windows "Send To" shortcut so I can right-click a .cue sheet to have it automatically open in CueTools, ready to Verify. However, when CueTools launches this way, it is not in Drag 'n' Drop Mode, ut is instead a tall, narrow window that seems to be Hide Browser mode. I am unable to make that window wider, which makes it awkward to ready Verify results.

1. How can I have CueTools always launch into my preferrred Drag 'n' Drop Mode, even when it launches by a file being sent to it via a Send To shortcut? Are there settings I can change to do this, or some command string or batch file that could launch CueTools with some switches or parameters?

Drag 'n' Drop Mode shows a nice summary of the Verify, e.g. AR: rip accurate (41/41), CTDB: verified OK, confidence 41, but does not show the full .accurip results in the CueTools window. Other modes show full full .accurip results but do not include the nice summary statement.
2. Is there a way to have CueTools display both the summary line and the full results after a Verify?



Thanks

This post has been edited by fadsplat: Dec 24 2011, 17:42

[kotekzot]

Hi, I have a couple of rips that CUETools has to do offset correction on to verify against AccurateRip DB. Is there any way to permanently "fix" them, or has the necessary data been lost due to poor ripping?

Also, if a dummy cue sheet passes AR validation, can it be considered exact?

Thanks!

This post has been edited by kotekzot: Dec 26 2011, 17:37

[sauvage78]

kotekzot:

1: Use Encode\Fix Offset. Default is "fix to nearest". You can change it "fix to highest" in the options.
Nothing is lost as offsets doesn't matter, the only thing you may have lost is the knowledge of which offset was the original one of your CD, but it doesn't really matter as all those pressings that only differs by an offset are equivalent.

Edit: You can also fix them manually one by one if you know exactly which offset you wanna match, just enter the wanted offset in the front offset box & encode. It will be sharper but much longer as nothing will be automatic then.

2: The splitpoints aka INDEX 01 in a CDImage.cue (or Tracks length if you prefer) are correct. Other info of various importance that a CUE can contain are missing.

No new CT version for Christmas ... blah ;(

This post has been edited by sauvage78: Dec 26 2011, 18:42

[d3m0n1q_733rz]

Another bug found! Most recent version of CueRipper errors when you click the track length of a data track. Unhandled exception.

[El Kabong]

Hey guys, I just downloaded a flac file I verified with CT (as always) which turned out to be a "no match but offset" one.

CODE

[CUETools log; Date: 22/12/2011 1:43:39; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track [ CRC ] Status
01 [de1e3119] (0/1) No match
02 [03693299] (0/1) No match
03 [062b2a55] (0/1) No match
04 [9504aee9] (0/1) No match
05 [af53be68] (0/1) No match
06 [9e7138e5] (0/1) No match
07 [55dd40f2] (0/1) No match
08 [7065ff8a] (0/1) No match
09 [0aead0ac] (0/1) No match
Offsetted by -24:
01 [ae80cc09] (0/1) No match but offset
02 [87947cc1] (0/1) No match but offset
03 [20946c45] (0/1) No match but offset
04 [ea57ba99] (0/1) No match but offset
05 [69917058] (0/1) No match but offset
06 [55f7c0dd] (0/1) No match but offset
07 [142944ea] (0/1) No match but offset
08 [2e5f2af2] (0/1) No match but offset
09 [1396e04c] (0/1) No match but offset

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [93962B01] [47181DCC] CRC32
01 96,6 [C19C5852] [9A9B82D7]
02 100,0 [5AB35513] [7237144A]
03 98,0 [D3545233] [02FF9787]
04 98,3 [1F1F7C47] [489EB4AE]
05 97,9 [F6A1F5E0] [C9E2C524]
06 98,2 [7A2F2D39] [20D741B3]
07 97,2 [012EE406] [65418D67]
08 95,8 [A497CE45] [E95C3C68]
09 97,2 [CA6013F4] [1705EC9C]

Well, I ended up burning anyways, offset-correcting in the meantime.
With this my "brand new" CD I repeated the process of ripping & verifying, BUT... now it turned out to be "accurately ripped".

CODE

[CUETools log; Date: 01/01/2012 3:10:10; Version: 2.1.2a]
[CTDB TOCID: q.J5giMFoJd0kQr3cHgcHLEkh7s-] disk not present in database.
[AccurateRip ID: 000fed5b-006fb89e-6e098309] found.
Track [ CRC ] Status
01 [ae80cc09] (0/1) No match but offset
02 [87947cc1] (0/1) No match but offset
03 [20946c45] (0/1) No match but offset
04 [ea57ba99] (0/1) No match but offset
05 [69917058] (0/1) No match but offset
06 [55f7c0dd] (0/1) No match but offset
07 [142944ea] (0/1) No match but offset
08 [2e5f2af2] (0/1) No match but offset
09 [1396e04c] (0/1) No match but offset
AccurateRip v2:
01 [cff94e79] (1/1) Accurately ripped
02 [9d16df24] (1/1) Accurately ripped
03 [3d30d8f8] (1/1) Accurately ripped
04 [08b4a99a] (1/1) Accurately ripped
05 [df62cb36] (1/1) Accurately ripped
06 [77080667] (1/1) Accurately ripped
07 [9a55ed90] (1/1) Accurately ripped
08 [34e7f011] (1/1) Accurately ripped
09 [40d8ff09] (1/1) Accurately ripped

Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100,0 [D079E009] [47181DCC] CRC32
01 96,6 [4D444A54] [9A9B82D7]
02 100,0 [D843C366] [7237144A]
03 98,0 [F3E83C36] [02FF9787]
04 98,3 [6F92B98A] [489EB4AE]
05 97,9 [497DC845] [C9E2C524]
06 98,2 [365EF879] [20D741B3]
07 97,2 [11BFDF1F] [65418D67]
08 95,8 [C3D27F4A] [E95C3C68]
09 97,2 [C0B98852] [1705EC9C]

Can someone tell me why doesn't CT warn of this ARv2 match for the offset(-24) instead of stating this misleading message.
I've been discarding all those "no match but offset" since long ago taking them for bad rips, and now I suddenly come across they were all probably good.

Thanks in advance!

This post has been edited by El Kabong: Jan 1 2012, 08:07

[Goratrix]

First, it's not nice to talk about verifying illegal downloads in this thread, CueTools was not designed for that purpose. Second, AR2 verification does not perform offset checking. There was a debate between Spoon and Gregory a few months ago in this thread, and Gregory said that AR2 verification across pressings is too time consuming or something, so it's not implemented (yet?).

[sauvage78]

Actually CT only display ARv2 results on the actual offset, I think displaying ARv2 results on other offsets is planned for a future version.
The actual way of displaying was thought for ARv1, actually displaying ARv2 is more a quick "hack" than anything else.
The full support of ARv2 is on the TODO list, but I agree it is taking too much time, according to me there are several reasons for this:
1- There was a disagreement between Spoon & Gregory about the usefullness of ARv2, now Gregory is more or less "forced" to support something he didn't asked for (as time goes by, I tend to agree with Gregory personnaly)
2- With full ARv2 support the displaying of log might completely change as Gregory posted an idea of horizontal log displaying in order to avoid very long vertical logs, reinventing the wheel might take longer than expected.
3- I suspect Gregory is more or less willing to make CTDB independent from AR as I suspect that despite his diplomatic behavior he didn't appreciated that much how ARv2 was implemented without his help. Gregory already stated that there is no CRC that AR stores & that CTDB doesn't store anymore. In the beginning CTDB was AR dependent, because both were using different CRC (tracks vs image) if I recall correctly. (Don't slam me if I am wrong Greynol !)
4- The introduction of the CTDB plugin for EAC makes the future of CT even harder to read, as it seems very efficient in term of submissions (even bad ones). Will there be a CTDB plugin for dBpoweramp in order to have a single database for all rippers dBpoweramp/Cueripper/EAC ??? I doubt Spoon would like the idea much ... will Gregory work with EAC more closely ? no one knows.
5- Gregory just get married & is currently cheating his computer. Full ARv2 support would certainly be faster if he would have wed Spoon. (Just Kidding Spoon !)

Anyway it would be great If Gregory could clear the future of the CTDB for 2012. I mean we all see what should be fixed or improved in CT, but actually we are at a point where any further CT development is dependent on how Spoon/Gregory/Andree are willing ... or not willing ... to work together on an harmonized verification\correction database.

As an end user, the way I see it: there is Spoon on one side & Gregory & Andree on the other, because Spoon already has his baby [AR which is GREAT, no discussion] & because Spoon sells software [which means he wants to keep control of his business which is natural]. Furthermore the recent past (ARv2) has shown that Gregory & Spoon didn't work that well together. As far as I understood both have respect for each other works as developpers, but none (well to be honest specially Spoon IMHO) is willing to let the other introduce himself in his own business. It is likely that Spoon invested too much time in AR development to drop it in favor of a cross-ripper improved CTDB platform. Furthermore is Gregory really wiling to achieve the development & manage such a platform ? For me there are hints that shows we tend toward this, but the fact that there is actually no futher CT visible development is also an hint that Gregory has a lot of hesitation himself ... because with or without the help of Spoon & Andree ... it's likely a lot of work.

Be warned, some of the above might be complete bullshits due to high speculation It's new year day & maybe I'm still drunk.

[spoon]

ARv2 was a simple fix to a flaw, it required about 10 minutes of programming effort to implement in a program which already uses ARv1. Despite all the talk about how CRC32 should have been used, I have never seen a false positive from AR, also ARv1 CRC is there also, so potentially you have 64 bits of CRC!

I have always said, for a program to state is compatible with ARv2 it should use the offset CRCs to check across pressings, this is efficient (typically a CD will have 4 offsets which need checking), after all we are not computing the next unknown prime number, just simple CRCs on audio.

AccurateRip is being worked on to allow the ~99.99999% of people who do not use a secure ripper to be able to verify their rips, and possibly correct bad rips, whilst being able to work on single files. I am sure I am not alone when I rip an album, listen to the tracks I like and delete the ones I do not like.

[sauvage78]

The biggest problem with CT not fully supporting ARv2 is that ARv1 submissions has more or less stopped (didn't hunt to verify if it's completely stopped), so with recent CD (post ARv2 introduction), ARv2 is often more populated than ARv1 ... & with CT not fully supporting ARv2 you don't see the whole picture of submissions anymore. If you don't fix offset while ripping, with a "post ARv2 introduction" new CD ... you may completely miss the submissions as those will be invisible.

It's also a problem when "fixing to highest" offset in database, nowadays I am unable to guess if it's already "fixed to highest" as I miss "half" (exagerating but sooner or later it will be half) of the submissions, & I am sure that it introduces other missbehaviors with other uses of CT than mine.

This post has been edited by sauvage78: Jan 1 2012, 13:25

[El Kabong]

All clearer now thanks to your replies, sauvage78 & spoon.
I'm not an everyday forum visitor (cause I have to take care of my own "illegal" forum ), so I didn't know it already was in a TODO list. Hope it soon get implemented in a vertical log display way (preferably) so we can catch the full picture. It would be of great use for fighting people's laziness who tends to do untidy works, sometimes not even correcting their drives' offsets... or what's worse: enabling enconding & decoding offset correction! . Thus making us other users waste our precious time. Still more, not to mention those unaware of EAC!!!
Personal benefits aside, best wishes for a near future agreement upon such a feature so needed by end users.

Cheers & Happy New Year!

PS (to whom it may concern): As for today, US laws are not worldwide applicable... fortunately.

[mjb2006]

sometimes not even correcting their drives' offsets

That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Besides, if those drives couldn't overread, then you know the samples at the very beginning or end of the rip were actually read from the CD, rather than padded with zeroes. So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons.

[El Kabong]

That's hardly a crime, since CUETools doesn't require offset correction for AR or CTDB verification. What benefit does offset correction have, then?

Regarding ARv2 verification, I guess my example speaks by itself.
What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

So some might say the non-offset-corrected rip makes for a more accurate copy of the original CD, in terms of content...notwithstanding the silliness of worrying about a few milliseconds'-worth of samples that are most likely silence.

No point of discussion here. Of course, it's not that important but very useful indeed. Otherwise, it wouldn't even have ever got implemented... I suppose.
That's why I trust CT so hard.

Regarding copyright law, even though just mentioning material of questionable origin isn't a violation or the Hydrogenaudio Terms of Service, it's generally a good idea to avoid doing it, as it turns otherwise helpful people into disdainful curmudgeons.

Let's say I was sneaking my cousin's machine then.
Ssssh!

[Goratrix]

What to do then if you find an old non-matching EAC's log or some AR-disabled log or no log at all?

Buy the CD?

[korth]

Gregory,
I know you're working on CTDB 2.0 and 'ignore pregap' was the last thing you worked on but what's this?

CTDB: disk not present in database, submit: discs with pregaps not supported in this protocol version.

Looks like discs with pregaps are being rejected in the current CTDB. I don't recall having this message come up on previous submissions.

This post has been edited by korth: Jan 12 2012, 18:03

[Anakunda]

I've go strange error when starting conversion, Stream doesnot support lookup.
What does it mean and how to fix it? Thanks.

[korth]

discs with pregaps not supported in this protocol version.

Looks like I get the same CTDB message with CUERipper on discs with pregap.

[Anakunda]

HI I see that CUEtools doesnot copy ISRC codes from original CUEsheet to new CUEsheet, could it be fixed in next version?

[Anakunda]

I suppose here's another shortcoming: copying old LOG file to new destination converts from Unicode to ANSI. This is basically bad because since this the LOG file can't be checked by EAC log verifier anymore (it only can read LOG files in Unicode). If possible please copy it raw (no codepage conversion). If I overlooked something in options then sorry but I think not, only options to forcing ANSI deals with file names which is different thing.