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

[greynol]

Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

Or you have a good rip, but CT says otherwise and offers to fix it with errant data?

I've seen a few titles in my collection where this could potentially happen. Not necessarily because of "fake" submissions, but because the database could be filled with titles that were pressed from masters that had errors.

As such, I'd be reluctant to suggest that others blindly fix their rips, especially if the ripping software didn't indicate there was an issue.

This post has been edited by greynol: Aug 22 2012, 17:18

[Gregory S. Chudo...]

Although the fact that the rip has 9 submissions in CTDB and none in AR is quite suspicious.

No, it's not. It's very common for new releases, because AR is only updated once per month, and CTDB is updated instantly.

If (and I'm wildly speculating here, don't kill me ), if the OP is veryifing a rip obtained from, cough, some other sources than his own CD, then he should not be looking at the CTDB results at all.

The source of a rip doesn't have anything to do with the question and is off-topic.

Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

That is not true.

[Goratrix]

Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

That is not true.

So there is a mechanism that somehow prevents fake submissions submitted from CUETools verification?

[jensend]

Last week I'd been working on ripping my whole collection, hit the metadata reload bug several times, and quit for a while in frustration.

Today I said "I really need to get that out of the way and get all these cds out of the room; I'll just hope I can work around the problem." Had just about finished typing in the track titles (long titles - some of which require special characters- plus opus numbers etc) for one 32-track CD when it reloaded without warning and seemingly without cause. I was ticked off enough that I almost broke my keyboard.

This bug completely breaks my ability to use the software.

How difficult would this be to fix? Would it pretty much just be a matter of adding calls to data.selectedRelease.metadata.Save() in a couple choice locations?

I have no C# experience, nor do I have VS installed right now, but I do have some C, C++, and Java experience, and if it's needed to help solve the problem I could try to help debug in an effort to figure out what triggers the reload.

[Porcus]

It should be specified in the cue sheet fed to CT, no?

That's a matter of what you mean by that “should”. Users do put CUETools at work on folders without any cuesheet at all.

[Dario]

Gregory, are there any chances that you will:

• Support XLD log files. There are people who use Mac notebooks and Windows desktops, so I think that it'd come in handy for CUETools to support parsing XLD log files (automatic CRC matching against the log, pre-gap and data-track detection).
• Decoding TAK files through the .dll instead of the command-line tool. This would eliminate the only problem with TAK-- lack of support for Unicode names.

Thank you for all your work.

This post has been edited by Dario: Aug 26 2012, 21:59

[wipeout]

Is it possible to make CueRipper embed an internal cuesheet as well as the vorbis comment version in flac images? I use flactag to manage my flac images and it gets metadata from musicbrainz, using the internal cuesheet to calculate the discid in order to get to a musicbrainz release id. If not directly, if there's some scripting component I missed where I could call "metaflac --import-cuesheet-from=%filename.cue %filename.flac" after ripping a CD that would be great as well. If this is documented, I missed it and I apologize in advance.

[korth]

CUERipper does embed the CUE sheet when ripping to a single-file flac image and creates a separate CUE sheet file.
The "Version" tag is not currently supported.

[Corwin]

The CUETools count is off by one. It shows 49 but my script counts the minimum matched is 50.

CODE

for TRACK in `seq 1 10`; do cat Belinda\ Carlisle\ -\ Real.log | gawk '/^\W0*'''$TRACK'''\W.*\(.*\)\W+Accurate/ {print $3}' | tr "()/" " " | gawk '{ print $1 }' | gawk -F '+' '{ sum+=$1+$2} END {print sum}'; done

52
53
51
52
52
51
50
52
50
52

CODE

[CUETools log; Date: 9/5/2012 2:19:26 AM; Version: 2.1.4]
Offset applied: 182
[AccurateRip ID: 001228b0-0091798d-830b260a] found.
Track [ CRC | V2 ] Status
01 [71570e5b|b876ed06] (03+00/58) Accurately ripped
02 [67668a00|8948ef9c] (03+00/59) Accurately ripped
03 [8f3a9af7|29bfaea8] (03+00/57) Accurately ripped
04 [f34f26e9|cf0ed7c6] (03+00/58) Accurately ripped
05 [34edf7e7|c72e7d8c] (03+00/58) Accurately ripped
06 [5bca7050|5941e4b2] (03+00/57) Accurately ripped
07 [449be498|e75fbb4b] (03+00/56) Accurately ripped
08 [ef1c16f0|ce911b56] (03+00/58) Accurately ripped
09 [f49365df|491ce18f] (03+00/58) Accurately ripped
10 [b1f4dc6d|739cecf0] (03+00/58) Accurately ripped
Offsetted by 23:
01 [9011fc4a] (41/58) Accurately ripped
02 [82366e41] (41/59) Accurately ripped
03 [f50c3069] (40/57) Accurately ripped
04 [61a972d4] (41/58) Accurately ripped
05 [43843bbc] (41/58) Accurately ripped
06 [36f10bc7] (40/57) Accurately ripped
07 [d8de7672] (41/56) Accurately ripped
08 [b943b741] (41/58) Accurately ripped
09 [dc83c804] (41/58) Accurately ripped
10 [b4f493ac] (41/58) Accurately ripped
Offsetted by 168:
01 [8594d361] (06/58) Accurately ripped
02 [701a0c16] (07/59) Accurately ripped
03 [1de790a7] (06/57) Accurately ripped
04 [3ac15171] (06/58) Accurately ripped
05 [cbffe75f] (06/58) Accurately ripped
06 [bdef91f8] (06/57) Accurately ripped
07 [1b60c008] (06/56) Accurately ripped
08 [bed95c08] (06/58) Accurately ripped
09 [e0a6e4d7] (06/58) Accurately ripped
10 [6ed164d5] (06/58) Accurately ripped
Offsetted by -244:
01 [90186840] (02/58) Accurately ripped
02 [dc2205af] (02/59) Accurately ripped
03 [0927055f] (02/57) Accurately ripped
04 [1dd40185] (02/58) Accurately ripped
05 [4123284b] (02/58) Accurately ripped
06 [041a9adc] (02/57) Accurately ripped
07 [e81c7520] (00/56) No match (V2 was not tested)
08 [78400e04] (02/58) Accurately ripped
09 [bc2df083] (00/58) No match (V2 was not tested)
10 [443aa899] (02/58) Accurately ripped

This post has been edited by db1989: Sep 6 2012, 12:32

Reason for edit: Please enclose large items within [codebox] tags.

[Porcus]

The CUETools count is off by one.

If so, then I like it that way, it prevents “verification” against my own submission. Maybe there should be a feature for “I have submitted”, or maybe (I haven't read the source) CUETools checks for log entries (/tags?) indicating that so was done?

This post has been edited by Porcus: Sep 6 2012, 09:06

[Corwin]

I have a few questions regarding s a CUETools (GUI) Verify log:

[CUETools log; Date: 9/7/2012 2:13:59 AM; Version: 2.1.4]
[CTDB TOCID: 3oyAwpWTUNxhhoGNcmgBa3GoPH4-] found.
Track | CTDB Status
1 | (2/2) Accurately ripped
2 | (2/2) Accurately ripped
3 | (2/2) Accurately ripped
4 | (2/2) Accurately ripped
5 | (2/2) Accurately ripped
6 | (2/2) Accurately ripped
7 | (2/2) Accurately ripped
8 | (2/2) Accurately ripped
9 | (2/2) Accurately ripped
[AccurateRip ID: 0013b09d-009109a0-700d6d09] found.
Track [ CRC | V2 ] Status
01 [a1fc6808|677ad65d] (4+0/4) Accurately ripped
02 [527deaee|532e0924] (4+0/4) Accurately ripped
03 [8f485bb2|30f27910] (4+0/4) Accurately ripped
04 [06692c20|6a3b2800] (4+0/4) Accurately ripped
05 [180343e7|8c2a774b] (4+0/4) Accurately ripped
06 [5c269cd6|f6fff705] (4+0/4) Accurately ripped
07 [4ef738f2|069dbe9a] (4+0/4) Accurately ripped
08 [decdd0f7|eeb83fcd] (4+0/4) Accurately ripped
09 [5e24a32a|9d5e0ae1] (0+0/4) No match

...


#1: Is the reason it's good on CTDB but not AccurateRip most likey because it's the last track and CTDB ignores a few more frames than AccurateRip does?
#2: CTDB is a whole CD checksum, correct? (This is perfect and awesome). Shouldn't the CTDB part just be "(2/2) Accurately ripped"?
#3: ArCueTools which I compile with mono for Linux does not seem to have any CTDB support. Any chance it will in the future?

[Corwin]

In case there are any Linux people out there, this is the command I'm currently using (2.1.4.2) to turn ArCueTools into a stand alone exe for linux:

CODE

mkbundle ArCueDotNet.exe CUETools.Processor.dll taglib-sharp.dll CUETools.Codecs.dll CUETools.Ripper.dll CUETools.CDImage.dll CUETools.Compression.dll CUETools.AccurateRip.dll CUETools.Parity.dll CUETools.CTDB.dll Freedb.dll CSScriptLibrary.v1.1.dll CUETools.Codecs.LossyWAV.dll --static --deps -o ArCueTools

You can then copy it to /usr/local/bin

[korth]

Edit: deleted

#2. CTDB 2 now has per track verification. To see the original whole disc result, you need to enable the detailed log. See this. Note: There was a bug in the detailed log section in 2.1.4 if you downloaded prior to Jul 11 2012. If you're not sure you have the corrected 2.1.4, grab the latest here.

This post has been edited by korth: Sep 7 2012, 02:37

[Corwin]

I have my source files on a RO (read only) drive labeled W:, and I have a RW drive labeled Y:

Input dir: W:\Iron Maiden\Iron Maiden - 2002 - Run the the Hills (CDS)\

I can set the template to: Y:\CUETmp\%filename%.cue and when I do a verify the .accurip file correctly goes there. The problem is I may have multiple cue files with the same name, ie:

Iron Maiden - 2002 - Run to the Hills (CDS)
Iron Maiden - 2002 - Run to the Hills (CDS V2)

will both have 'Iron Maiden - 2002 - Run to the Hills.flac.cue' in them. This is how I want it.

If I set the template to: Y:\CUETmp\%dirname%\%filename%.cue
I get this in the Output box: Y:\CUETmp\W:\Iron Maiden\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac

The tooltip says it's foobar2000 format. Looking at http://wiki.hydrogenaudio.org/index.php?ti...irectoryname.25
It says: %directoryname% Returns the name of the parent directory only, not the complete path.

So I should have 'Y:\CUETmp\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac', not 'Y:\CUETmp\W:\Iron Maiden\Iron Maiden - 2002 - Run to the Hills (CDS)\Iron Maiden - Run to the Hills.flac.flac'

[Corwin]

I'm running today's release of 2.1.4 with detailed logs enabled. I'm seeing this a lot in the logs:

CODE

[CUETools log; Date: 9/7/2012 1:13:00 AM; Version: 2.1.4]
CD-Extra data track length 16:13:48.
[CTDB TOCID: eh.lX1OGA2fWGK0Waw.2hS7qO08-] found.
        [ CTDBID ] Status
        [a5600ba6] (71/82) , Accurately ripped
        [a5600ba6] (04/82) Has no data track, Accurately ripped
        [c702aeb1] (02/82) , Accurately ripped
        [24b2f511] (01/82) , No match
        [9c4277a2] (03/82) , Accurately ripped
        [3af65ca0] (01/82) Differs in 3 samples @45:11:59

I assume those commas should not be there?

[Corwin]

Here's a better example of the numbering bug. 33/34 for the entire album, but all tracks are 34/34

CODE

[CUETools log; Date: 9/7/2012 2:32:29 AM; Version: 2.1.4]
[CTDB TOCID: qUrQvKCekqMe8BhgyPUESesZhRM-] found.
        [ CTDBID ] Status
        [2fd2ac1c] (33/34) Accurately ripped
        [15d2da57] (01/34) No match
Track | CTDB Status
  1   | (34/34) Accurately ripped
  2   | (34/34) Accurately ripped
  3   | (34/34) Accurately ripped
  4   | (34/34) Accurately ripped
  5   | (34/34) Accurately ripped
  6   | (34/34) Accurately ripped
  7   | (33/34) Accurately ripped
  8   | (34/34) Accurately ripped
  9   | (34/34) Accurately ripped
10   | (34/34) Accurately ripped

[korth]

The tooltip says it's foobar2000 format.

See also Cuetools_templates. Actually it's 'based on' foobar2000 format not a complete duplicaion. %directoryname% in CUETools does return the full path.
Can't you use Y:\CUETmp\%artist% - [%year% - ]%album%\%filename%.cue ?

I assume those commas should not be there?

Not if the CD-Extra data track length is the same otherwise a message would precede the comma. The original bug included discs with a CD-Extra data track. This was probably overlooked for functionality in lieu of appearance.

Here's a better example of the numbering bug. 33/34 for the entire album, but all tracks are 34/34

33/34 + 01/34 = 34/34. There are 33 matches + 1 'No match'. You'll also note that track 7 only has 33/34 matches so the maximum can only be 33/34 matches.

This post has been edited by korth: Sep 7 2012, 13:27

[greynol]

Should say 33/33 since the rogue 1 clearly hasn't been validated and as such has been put in limbo.

What does AR say about this track using either EAC or dBpoweramp?

[korth]

9/10 tracks match. If you put the entire record in limbo you would also exclude the 9 matching tracks from per-track verification.

[greynol]

Who said anything about putting the entire record into limbo? I was specifically talking about track 7.

Is CT handling track submissions that are not validated differently from AR?

This post has been edited by greynol: Sep 7 2012, 15:32

[korth]

CTDB is still using a whole disc (modified) CRC32 as a db record identifier (CTDBID) so the non-matching Track 7 is part of the record that exists under a different CTDBID. The 34 in xx/34 are the 34 CTDBID records under that CTDB TOCID (an identifier based on the disc's TOC layout) so there are still 34 track 7's if there are 34 CTDBID records.

[greynol]

Right. I made the mistake in thinking it was an AR record that was being presented where rogue entries are suppressed.

[Corwin]

See also Cuetools_templates.

Thank you. I previously looked in the wiki for that page but couldn't find it for some reason.

Can't you use Y:\CUETmp\%artist% - [%year% - ]%album%\%filename%.cue ?

That will fail all over the place:

CODE

# ls Iron\ Maiden\ -\ 2002\ -\ Run*
Iron Maiden - 2002 - Run to the Hills (CDS):
Iron Maiden - Run to the Hills.cbr   Iron Maiden - Run to the Hills.flac.cue        Iron Maiden - Run to the Hills.log
Iron Maiden - Run to the Hills.flac  Iron Maiden - Run to the Hills (Live '01).mov

Iron Maiden - 2002 - Run to the Hills (CDS V2):
Iron Maiden - Run to the Hills (Camp Chaos).mov  Iron Maiden - Run to the Hills.flac      Iron Maiden - Run to the Hills.log
Iron Maiden - Run to the Hills.cbr               Iron Maiden - Run to the Hills.flac.cue

CODE

# ls Iron\ Maiden\ -\ 1984\ -\ Power*
Iron Maiden - 1984 - Powerslave:
Iron Maiden - Powerslave.cbr  Iron Maiden - Powerslave.flac  Iron Maiden - Powerslave.flac.cue  Iron Maiden - Powerslave.log

Iron Maiden - 1984 - Powerslave (1998 Remaster):
Iron Maiden - 2 Minutes to Midnight.mov  Iron Maiden - Powerslave.cbr   Iron Maiden - Powerslave.flac.cue
Iron Maiden - Aces High.mov              Iron Maiden - Powerslave.flac  Iron Maiden - Powerslave.log

I'm either going to have to modify CUETools to get a parent directory option or attempt to set up a UnionFS. Considering I have a few thousand parent level directories (band names) I'm not sure that's going to fly. Having a %parentdir% var would be by far the easiest and cleanest.

You'll also note that track 7 only has 33/34 matches so the maximum can only be 33/34 matches.

Thank you. I saw 34/34 every time until you specifically pointed out track 7. My mistake.

[Corwin]

The %unique% tage is completely dead in 2.1.4. I get prompted if I want to overwrite with the following template:

Y:\CUETmp\%artist% - %album%[ - %unique%].flac.cue


Overwrite?
Y:\CUETmp\Black Sabbath - Black Sabbath.flac.accurip

[korth]

The log file name format is specified in CUETools Advanced Settings: AccurateRip tab under Log file; Name format:
You can change it to %filename%[ - %unique].accurip. I have it set similar.

This post has been edited by korth: Sep 8 2012, 13:18