Skip to main content

Topic: CUETools versions 1.9.5 through 2.1.5 (current) (Read 1313648 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.
  • Dynamic
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1925
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.
  • Last Edit: 30 June, 2012, 04:34:27 AM by Dynamic
Dynamic – the artist formerly known as DickD

  • n0v!ze
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1926
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: [Select]
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
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1927
Quote
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='.
Quote
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.
Quote
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.
korth

  • n0v!ze
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1928
Thanks, korth.  Must have overlooked that period in the options pane.

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1929
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

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1930
Not limited to ALAC. Same problem with WV and TTA Input (multiple tries).
FLAC, APE & WAV repair OK. TAK not tested.
korth

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1931
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.
CUETools 2.1.4

  • NetRanger
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1932
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
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1933
@ Gregory

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

It would be gr8 it if could be added.

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1934
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.
Quote
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.
korth

  • NetRanger
  • [*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1935
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
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1936
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!
Glass half full!

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1937
I tried running this under linux mint 13, via mono /path/to/CUETools.exe but I'm getting
Code: [Select]
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
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1938
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
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1939
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
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1940
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.
Quote
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.
Quote
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.)
korth

  • jensend
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1941
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?

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1942
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.
CUETools 2.1.4

  • jensend
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1943
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
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1944
Here's my CUETools Log (Verify Mode)
Code: [Select]
[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
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1945
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
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1946
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.
korth

  • Goratrix
  • [*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1947
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
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1948
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
  • [*][*][*][*][*]
  • Global Moderator
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #1949
It should be specified in the cue sheet fed to CT, no?
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.