IPB

Welcome Guest ( Log In | Register )

101 Pages V  « < 76 77 78 79 80 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
Dynamic
post Jun 30 2012, 09:26
Post #1926





Group: Members
Posts: 796
Joined: 17-September 06
Member No.: 35307



QUOTE (korth @ Jun 30 2012, 01:01) *
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


--------------------
Dynamic the artist formerly known as DickD
Go to the top of the page
+Quote Post
n0v!ze
post Jul 3 2012, 09:54
Post #1927





Group: Members
Posts: 31
Joined: 9-June 07
Member No.: 44197



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 ohmy.gif the tag shown is APEv2 (APEv2) for all tracks blink.gif . 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
Go to the top of the page
+Quote Post
korth
post Jul 3 2012, 14:19
Post #1928





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



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 ohmy.gif 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
Go to the top of the page
+Quote Post
n0v!ze
post Jul 3 2012, 17:52
Post #1929





Group: Members
Posts: 31
Joined: 9-June 07
Member No.: 44197



Thanks, korth. Must have overlooked that period in the options pane.
Go to the top of the page
+Quote Post
korth
post Jul 5 2012, 00:07
Post #1930





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



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
Go to the top of the page
+Quote Post
korth
post Jul 5 2012, 13:31
Post #1931





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



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


--------------------
korth
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Jul 12 2012, 01:40
Post #1932





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



QUOTE (korth @ Jul 4 2012, 19:07) *
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
Go to the top of the page
+Quote Post
NetRanger
post Jul 17 2012, 12:47
Post #1933





Group: Members
Posts: 56
Joined: 2-November 03
Member No.: 9605



QUOTE (Gregory S. Chudov @ Jul 12 2012, 02:40) *
QUOTE (korth @ Jul 4 2012, 19:07) *
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?
Go to the top of the page
+Quote Post
NetRanger
post Jul 17 2012, 13:57
Post #1934





Group: Members
Posts: 56
Joined: 2-November 03
Member No.: 9605



@ Gregory

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

It would be gr8 it if could be added.
Go to the top of the page
+Quote Post
korth
post Jul 17 2012, 15:32
Post #1935





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



QUOTE (NetRanger @ Jul 17 2012, 12:47) *
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
Go to the top of the page
+Quote Post
NetRanger
post Jul 20 2012, 11:29
Post #1936





Group: Members
Posts: 56
Joined: 2-November 03
Member No.: 9605



QUOTE (korth @ Jul 17 2012, 16:32) *
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.
Go to the top of the page
+Quote Post
bilbo
post Jul 20 2012, 15:17
Post #1937





Group: Members
Posts: 190
Joined: 16-April 07
Member No.: 42593



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!
Go to the top of the page
+Quote Post
ChronoSphere
post Aug 4 2012, 17:40
Post #1938





Group: Members
Posts: 461
Joined: 11-March 07
Member No.: 41384



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?
Go to the top of the page
+Quote Post
jensend
post Aug 5 2012, 01:54
Post #1939





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



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.
Go to the top of the page
+Quote Post
jensend
post Aug 5 2012, 22:18
Post #1940





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



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.
Go to the top of the page
+Quote Post
korth
post Aug 6 2012, 04:15
Post #1941





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



This won't help much (I'm not the developer).
QUOTE (jensend @ Aug 5 2012, 22:18) *
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
Go to the top of the page
+Quote Post
jensend
post Aug 19 2012, 04:17
Post #1942





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



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?
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Aug 19 2012, 12:43
Post #1943





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



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 smile.gif I do read everything that's posted here, even if i'm sometimes too busy/lazy to answer.


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
jensend
post Aug 19 2012, 15:41
Post #1944





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



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.
Go to the top of the page
+Quote Post
nvrbckdwn
post Aug 22 2012, 14:00
Post #1945





Group: Members
Posts: 1
Joined: 14-June 11
Member No.: 91492



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





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



QUOTE (nvrbckdwn @ Aug 22 2012, 15:00) *
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.


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
korth
post Aug 22 2012, 14:57
Post #1947





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



QUOTE (nvrbckdwn @ Aug 22 2012, 14:00) *
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
Go to the top of the page
+Quote Post
Goratrix
post Aug 22 2012, 16:37
Post #1948





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



QUOTE (Porcus @ Aug 22 2012, 15:19) *
QUOTE (nvrbckdwn @ Aug 22 2012, 15:00) *
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 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 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.
Go to the top of the page
+Quote Post
Porcus
post Aug 22 2012, 16:40
Post #1949





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



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


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
greynol
post Aug 22 2012, 17:02
Post #1950





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



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


--------------------
Placebophiles: put up or shut up!
Go to the top of the page
+Quote Post

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

 



RSS Lo-Fi Version Time is now: 29th July 2014 - 18:40