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

[Dynamic]

Still waiting for Grigory to chime in for your first question.
In the meantime, the config is in %appdata%\CUERipper\settings.txt
Default should be:
DetectHDCD=1
Wait750FramesForHDCD=1
[edit: deleted much of requote]

Thanks for steering me in that direction. I didn't think to look for an settings file and check. Looks encouragingly like the CUETools settings dialogue box, and hopefully theres enough code re-use that both will behave the same. Then again, might be an experimental undocumented feature.

Maybe I'll have to dig out those old Dire Straits remasters and check and report back one day.

Cheers.

This post has been edited by Dynamic: Jun 30 2012, 09:34

[n0v!ze]

This is my first shot with CUERipper. The good thing is that the generated CUE sheet contains more data than with EAC (for example CATALOG is correctly set). The generated log file looks overall good, here is the head:

CODE

CUERipper v2.1.4 Copyright (C) 2008-12 Grigory Chudov

EAC extraction logfile from 3. July 2012, 10:07

Hallows Eve / Tales of Terror

Used drive  : PLEXTOR CD-R   PX-W8432T   Adapter: 1  ID: 0

Read mode               : Secure
Utilize accurate stream : Yes
Defeat audio cache      : Yes
Make use of C2 pointers : No

Read offset correction                      : 355
Overread into Lead-In and Lead-Out          : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks   : No
Null samples used in CRC calculations       : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

<snip>

All tracks accurately ripped

No errors occurred

End of status report

I wonder why the working (!) C2 error correction on this drive is not recognized and how to format the generated file names (don't want a period behind %tracknumber%). Also, this drive should be able to overread into Lead-In and Lead-Out.

When I open the output folder in Mp3tag then the tag shown is APEv2 (APEv2) for all tracks . I consider this a real error as this should be ID3v2.3 (actually that's the whole point of using True Audio instead of FLAC).

Regards

[korth]

how to format the generated file names (don't want a period behind %tracknumber%).

In 2.1.4, it can be changed in Options. Prior versions go to %appdata%\CUERipper\settings.txt and adjust 'TrackFilenameFormat='.

I wonder why the working (!) C2 error correction on this drive is not recognized and ... this drive should be able to overread into Lead-In and Lead-Out.

I'll defer to the program developer but the question has been asked before.

When I open the output folder in Mp3tag then the tag shown is APEv2 (APEv2)

Again I'll defer to the program developer but can confirm TTA and TAK are set to use APEv2 tags in CUETools/CUERipper. TagLib# (TagLib-Sharp) used for all other formats.

[n0v!ze]

Thanks, korth. Must have overlooked that period in the options pane.

[korth]

Grigory,
CUETools 2.1.4, ALAC Input and 'repair' script. Everything appears to work fine except the resulting files verify exactly the same (no change, not repaired). I ran across this by accident while running a few Encode tests. I've duplicated the results multiple times. Converting from ALAC to FLAC, then running the 'repair' script on the FLAC files, the resulting files verify accurate (repaired).

[korth]

Not limited to ALAC. Same problem with WV and TTA Input (multiple tries).
FLAC, APE & WAV repair OK. TAK not tested.

[Gregory S. Chudo...]

ALAC Input and 'repair' script.

Thanks for reporting this. I made a small bugfix release to address this and 'Detailed log' problem. Didn't bump the version number, just overwrote the same download location.

[NetRanger]

ALAC Input and 'repair' script.

Thanks for reporting this. I made a small bugfix release to address this and 'Detailed log' problem. Didn't bump the version number, just overwrote the same download location.

So v2.1.4 is the new stable version now?

[NetRanger]

@ Gregory

Do u have any plans on adding AccurateRip cross-pressing verification?

It would be gr8 it if could be added.

[korth]

So v2.1.4 is the new stable version now?

If downloaded after Jul 11 2012, then v2.1.4 is labeled the current stable version.

Do u have any plans on adding AccurateRip cross-pressing verification?

You of course meant ARv2 cross-pressing verification? CUETools already has ARv1 cross-pressing verification.
I agree it should be added if possible. Perhaps even optional (can be turned on/off) or as a custom script if execution speed is still an issue.

[NetRanger]

You of course meant ARv2 cross-pressing verification? CUETools already has ARv1 cross-pressing verification.
I agree it should be added if possible. Perhaps even optional (can be turned on/off) or as a custom script if execution speed is still an issue.

Yeah, it's the ARv2 i'm talking about.

A option to turn thecross-pressing verification On/Off would be gr8 to have available.

[bilbo]

IIRC Gregory mentioned that it is much harder to check cross pressing in ARv2 and questioned the need for ARv2. From Spoons latest announcements, it looks like he is ripping off Gregory's idea to do a paid service using ARv2. It even includes error correcting that Gregory pioneered.

The obvious nest step would be for spoon to kill ARv1, so everyone would have to use his paid service.

I think that we need to load as much as we can to the CueToolsDB so we can still have free functionality in the future!

[ChronoSphere]

I tried running this under linux mint 13, via mono /path/to/CUETools.exe but I'm getting

CODE

Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
[ERROR] FATAL UNHANDLED EXCEPTION: System.TypeLoadException: A type load exception has occurred.

Any idea what I might be missing?

[jensend]

I'm about to re-rip my entire collection (I recently acquired an external hd large enough for me to store the lossless originals). I've been thinking I'd use CueRipper but I'm having two problems.

First, I can't seem to get the output path template to include the genre.

Second, though I see in changelogs that you have added support for MusicBrainz's new schema, I don't see any way to add most of that kind of information to the metadata.

BTW, might I suggest that you ask HA for your own subforum? Having a single thread for all support requests, announcements, development discussion, etc is extremely cumbersome.

[jensend]

To be more specific about the problem with the genre: if I put %genre% in the path template it just outputs %genre%, and if I put $meta(genre) or something similar there it fails to give me a pathname at all.

I don't know whether it's relevant, but the metadata CueRipper found for the disc didn't list a genre; I put it in myself.

I ask about the new schema mostly for the ability to list other credited artists. In particular, a lot of my collection is classical music, so it's helpful to be able to list composer, performing group, and conductor.

[korth]

This won't help much (I'm not the developer).

To be more specific about the problem with the genre: if I put %genre% in the path template it just outputs %genre%

%genre% would be the correct syntax. [%genre%] even better to make it conditional. I can confirm that though it works in the filename template in CUETools, it does not work in CUERipper.

I don't know whether it's relevant, but the metadata CueRipper found for the disc didn't list a genre; I put it in myself.

Genre is not retrieved from MusicBrainz or Discogs.

I ask about the new schema mostly for the ability to list other credited artists. In particular, a lot of my collection is classical music, so it's helpful to be able to list composer, performing group, and conductor.

Some of the new schema can be used in the filename template only. It is currently not possible to add tags in addition to those listed in the Meta or Tracks window. You can edit the Track Artist by clicking the track # column in the track window for any track. Track Comment currently not working.
(Note: Barcode in the Meta window is written to the CUE file only as CATALOG tag.)

[jensend]

Unfortunate that we haven't heard back from Gregory about the %album% bug.

Another problem: CueRipper seems to reload the metadata fairly frequently. If you've made edits, they are discarded unless you've ripped the CD with those edits to the metadata. This is *extremely* frustrating when you have a CD with a lot of tracks, various track artists, etc that needs a lot of metadata attention.

I don't know what causes it. One thing that reliably seems to trigger it is reading or playing the disc with another application while I have CueRipper open with the edits. Most of the time it just seems to randomly happen while I'm typing the metadata in, but maybe there's some application, system service, etc that tries to read from the cd drive occasionally. In case it's relevant, this is on a WinXP machine with .net framework 3.5 SP1 (and of course 3.0, 2.0).

Also, if you use the button to submit changes to FreeDB they'll just send an email saying "Existing entry found with higher revision than submitted." The trouble is that CueRipper doesn't increment the revision number when you submit corrections to FreeDB. Other rippers, incl. EAC and even old CDex, automatically increase the revision number.

I'd like to reiterate my suggestion that you ask HA for a hosted subforum so not all the bug reports, discussions, etc have to be in just one thread.

BTW is it preferred to submit these to the SF bugtracker?

[Gregory S. Chudo...]

What %album% bug? You mean %genre%? I'll look into it.

Musicbrainz: it had a lot of extra information, such as conductor/composer/etc even before new generation schema (NGS), and no, CUETools doesn't currently support most of these tags. Main change in Musicbrainz NGS (new generation schema) was replacing release events with releases, so CUETools can lets you select the correct reissue of a CD and supports Label/Catalog number/Release date.

CUERipper currently saves metadata edits only when you start ripping, and reloads it only if the system reports that a drive (not necessarily the currently selected drive) has had a disc ejected or loaded. I don't know what might cause the OS to report this erroneously (never happened to me), but i should probably make CUERipper save metadata when this happens.

I always forget to check SF bugtracker I do read everything that's posted here, even if i'm sometimes too busy/lazy to answer.

[jensend]

Yes, I mean %genre%; my bad. Thanks for looking into it.

Saving the metadata on those occasions would be a great help. If it doesn't have to be the currently selected drive which gets inserted/reloaded to cause CueRipper to reload, I wonder if the OS may be reporting erroneous events on my external hard drive which I'm saving all the music to, since it seems to spin down/spin up much more frequently than I'd wish. (Perhaps CueRipper could also restrict reloads to load/eject events on the currently selected drive?)

Thanks for the MusicBrainz clarification as well; the current behavior isn't really that problematic, I just wondered what the ngs support mentioned in the changelog amounted to.

[nvrbckdwn]

Here's my CUETools Log (Verify Mode)

CODE

[CUETools log; Date: 8/22/2012 7:57:01 PM; Version: 2.1.4]
[CTDB TOCID: hEht88BfBHFLCpTqcVzUc3NxeQM-] found.
Track | CTDB Status
  1   | (9/9) Accurately ripped
  2   | (9/9) Accurately ripped
  3   | (9/9) Accurately ripped
  4   | (9/9) Accurately ripped
  5   | (9/9) Accurately ripped
  6   | (9/9) Accurately ripped
  7   | (9/9) Accurately ripped
  8   | (9/9) Accurately ripped
  9   | (9/9) Accurately ripped
10   | (9/9) Accurately ripped
11   | (9/9) Accurately ripped
12   | (9/9) Accurately ripped
13   | (9/9) Accurately ripped
14   | (9/9) Accurately ripped
15   | (9/9) Accurately ripped
16   | (9/9) Accurately ripped
17   | (9/9) Accurately ripped
[AccurateRip ID: 002de805-0246d414-f711d611] disk not present in database.

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
--  100.0 [D78D3B12] [E33CA45B]  W/O NULL
01  100.0 [5C6B629A] [2CEB2478]          
02  100.0 [2143D219] [C1819E6C]          
03   99.1 [131CA7DD] [8C89D7FA]          
04  100.0 [11C6AFAB] [CDC171C9]          
05  100.0 [63CFFACD] [9D25555F]          
06  100.0 [E4806D30] [864D8C0F]          
07  100.0 [CA68015C] [D2912A94]          
08  100.0 [1205D4C4] [FD47E5D7]          
09  100.0 [C45DCF3C] [FC743F84]          
10  100.0 [E099EADD] [20AB6016]          
11  100.0 [5EC526C6] [71A3F021]          
12  100.0 [6957FB29] [4F4E0918]          
13  100.0 [87E62411] [9108D17B]          
14  100.0 [EF7D6B45] [C1037029]          
15  100.0 [EF0A712C] [F8651FED]          
16  100.0 [CEA38418] [05E7BE21]          
17  100.0 [895E1F77] [E4BDFF83]

What does it mean? Thanks in advance for the answer. Sorry for my bad English.

[Porcus]

What does it mean?

Short answer: That your rip is OK.

It matches all of the CTDB's nine rips. CUETools finds no AccurateRip submission to compare with. The last section of the log is checksums.

[korth]

Here's my CUETools Log (Verify Mode). What does it mean? Thanks in advance for the answer. Sorry for my bad English.

The explanation Porcus gave is spot on but this may help also.

[Goratrix]

What does it mean?

Short answer: That your rip is OK.

It matches all of the CTDB's nine rips. CUETools finds no AccurateRip submission to compare with. The last section of the log is checksums.

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

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 reason being that it is possible to submit data to CTDB directly from CUETools, after verification, without even ripping a CD. Which means that it is extremely easy to fake CTDB submissions for a rip that is, cough, available somewhere.

[Porcus]

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

Isn't that the usual case for those CDs with non-standard length pregap length, that CUETools doesn't have the sufficient information to generate the AccurateRip ID?

[greynol]

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