IPB

Welcome Guest ( Log In | Register )

104 Pages V  « < 77 78 79 80 81 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
greynol
post Aug 22 2012, 17:06
Post #1951





Group: Super Moderator
Posts: 10256
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (Goratrix @ Aug 22 2012, 08:37) *
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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Aug 22 2012, 17:08
Post #1952





Group: Developer
Posts: 705
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (Goratrix @ Aug 22 2012, 11:37) *
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.

QUOTE (Goratrix @ Aug 22 2012, 11:37) *
If (and I'm wildly speculating here, don't kill me cool.gif ), 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.

QUOTE (Goratrix @ Aug 22 2012, 11:37) *
Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

That is not true.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
Goratrix
post Aug 22 2012, 17:12
Post #1953





Group: Members
Posts: 131
Joined: 5-August 08
Member No.: 56722



QUOTE (Gregory S. Chudov @ Aug 22 2012, 18:08) *
QUOTE (Goratrix @ Aug 22 2012, 11:37) *
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?
Go to the top of the page
+Quote Post
jensend
post Aug 22 2012, 21:30
Post #1954





Group: Members
Posts: 149
Joined: 21-May 05
Member No.: 22191



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.
Go to the top of the page
+Quote Post
Porcus
post Aug 22 2012, 21:56
Post #1955





Group: Members
Posts: 1957
Joined: 30-November 06
Member No.: 38207



QUOTE (greynol @ Aug 22 2012, 18:02) *
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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Dario
post Aug 26 2012, 21:59
Post #1956





Group: Members
Posts: 158
Joined: 20-September 11
Member No.: 93842



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
Go to the top of the page
+Quote Post
wipeout
post Sep 4 2012, 08:15
Post #1957





Group: Members
Posts: 5
Joined: 28-March 04
Member No.: 13053



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.
Go to the top of the page
+Quote Post
korth
post Sep 4 2012, 13:32
Post #1958





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



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.


--------------------
korth
Go to the top of the page
+Quote Post
Corwin
post Sep 5 2012, 10:55
Post #1959





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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.
Go to the top of the page
+Quote Post
Porcus
post Sep 6 2012, 09:05
Post #1960





Group: Members
Posts: 1957
Joined: 30-November 06
Member No.: 38207



QUOTE (Corwin @ Sep 5 2012, 11:55) *
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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 00:00
Post #1961





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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?
Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 02:15
Post #1962





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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
Go to the top of the page
+Quote Post
korth
post Sep 7 2012, 02:22
Post #1963





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



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


--------------------
korth
Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 09:05
Post #1964





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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'


Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 09:29
Post #1965





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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?
Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 12:45
Post #1966





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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
Go to the top of the page
+Quote Post
korth
post Sep 7 2012, 13:22
Post #1967





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



QUOTE
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 ?

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

QUOTE
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


--------------------
korth
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 13:29
Post #1968





Group: Super Moderator
Posts: 10256
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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?


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
korth
post Sep 7 2012, 14:04
Post #1969





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



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


--------------------
korth
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 15:16
Post #1970





Group: Super Moderator
Posts: 10256
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
korth
post Sep 7 2012, 18:11
Post #1971





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



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.


--------------------
korth
Go to the top of the page
+Quote Post
greynol
post Sep 7 2012, 18:15
Post #1972





Group: Super Moderator
Posts: 10256
Joined: 1-April 04
From: San Francisco
Member No.: 13167



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


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Corwin
post Sep 7 2012, 22:55
Post #1973





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



QUOTE (korth @ Sep 7 2012, 04:22) *

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

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



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

Go to the top of the page
+Quote Post
Corwin
post Sep 8 2012, 08:01
Post #1974





Group: Members
Posts: 37
Joined: 20-May 07
Member No.: 43617



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
Go to the top of the page
+Quote Post
korth
post Sep 8 2012, 12:56
Post #1975





Group: Members
Posts: 456
Joined: 13-March 11
Member No.: 88969



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


--------------------
korth
Go to the top of the page
+Quote Post

104 Pages V  « < 77 78 79 80 81 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 26th November 2014 - 06:31