Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: CUETools versions 1.9.5 through 2.1.6 (Read 1889284 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #425
I have a problem verifying some releases. As I understand it, it should automatically pick up the log-file from the same dir and determine pregap from it. Well it doesn't seem to pick up the log and neigher it seem to work when I write in the pregap manually - Still it's not detected in the AR database, although the rip-log says Accurately Ripped.

In batch mode it will pick up the log only if it's filename is exactly the same as cue sheet's (xyz.cue -> xyz.log). Log seems fine, so no idea what's wrong.

But I don't have a cue-sheet, just a set of ripped files.

Actually I wonder, why some albums verify accurately with a very high confidence number, many with just 1 og 2 in confidence and a lot not at all (assuming the missing pregap). I wonder because I thought that redbook standard needs at least 0:02 sec pregap.

In theory, could pre-gap not be detected just as offset can?
Can't wait for a HD-AAC encoder :P

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #426
No pregap for the first track in a cue means it is 2 seconds.

Pregaps cannot be detected like offsets, not even in theory.  Have a look at the part of the code used to generate Disc IDs combined with the way AR lookup works and you'll understand.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #427
Quote
Actually I wonder, why some albums verify accurately with a very high confidence number, many with just 1 og 2 in confidence and a lot not at all (assuming the missing pregap). I wonder because I thought that redbook standard needs at least 0:02 sec pregap.


It is possible to find a match at a pregap 0 with confidence 1 or 2 and a match with pregap 32 (or 33,37) with a much higher confidence.
In such a case the low confidence match with 0 pregap is probably (IMHO) from a cdr rip.
If I'm not certain of the source I always check 0,32,33,37 pregap. Those are the most common pregaps.


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #428
I'm new to Cuetools but I'm really quite amazed at this versatile little tool.

But is there a way to also cut the music images into their seperate songs?
(when converting, you can see it's processing each track... it should be easy to just cut it at the end and start the next track).

Me personally I'd like to convert my single file Ape image to seperate Flac tracks.
I could use three or four tools consecutively to do that, but I'd rather use just a single one... this one...

It's especially handy since some of my Ape files have no identification or cue files at all and with this tool I could get fully named Flac files.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #429
Did you try setting "CUE Style" to "Gaps Appended"?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #430
Love the program, but I just started getting an error when trying to convert an album from APE to FLAC.  It is "Exception: Object reference not set to an instant of an object."  It happens after I have selected my log file and it is looking up the album from freedb then MusicBrainz.  Any help would be appreciated!  Thanks!  (happens in 1.9.5 and 2.0.2)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #431
Does it only happen with this album, is there something specific about it or it happens with all albums, or with all your albums in APE? Can you please try to research the problem a bit?
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #432
It doesn't happen with every album I use CueTools with, and it's not happening just with APE files.  It has done it with WavPack and WAV.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #433
I'd like to propose following 2 additions to this wonderful tool:

1) drop-down list with user's custom naming schemes (for example, I use %0\cdimage.cue for single image and %C (flac) for tracks and I have to type them each time I swith from one mode to another);

2) a naming scheme for verify log (I'd sometimes use %C.accurip and sometimes accuraterip.log).

What does Gregory S. Chudov think about it?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #434
Makes sense. We'll see if i have time for this when i'll start preparing next version.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #435
Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #436
OK, in fact, it works fine in 1.9.5a. It's a bug of the instable version.
Anyway, some additional details about how to use the command line would be helpful.
For example, which settings are used when I use the /fix flag ? Is it possible to specify other settings as additional parameters ?

Thanks a lot !



Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga


CUETools versions 1.9.5 through 2.1.5 (current)

Reply #437
When fixing offset values, after it verifies with Accurate Rip, is it possible to choose which offset to apply?

Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #438
Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".


You should choose encode and verify and then choose fix offset from the pull down menu. It will fix the offset to the one which is closest to your rip.
This way the least samples are discarded.
Choosing the fix the offset to the pressing with the highest confidence level makes imho no sense at all. You're just discarding more samples then necessary.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #439
OK, I continue to reply to myself :-)
I understand that when CUETools is invoked from the command line, the settings contained in the settings.txt file are applied, and I assume that they can't be modified by additional parameters.

In fact, I would like to split some CDImage.ape by some CDImage.cue with applying simultaneously an offset correction (not depending on accurip, but set manually according to the drive model appearing in the log file).
This works using the GUI, but with the /convert command, the split is done without the offset correction. Is it a bug or a feature ? Is there something to change in the settings.txt ?

Thank you in advance.

OK, in fact, it works fine in 1.9.5a. It's a bug of the instable version.
Anyway, some additional details about how to use the command line would be helpful.
For example, which settings are used when I use the /fix flag ? Is it possible to specify other settings as additional parameters ?

Thanks a lot !



Hi,

First, thank you very much for this very useful tool !
I would like to know if there is some manual page somewhere, because the readme file is kind of bare :-)
In particular, I would like to know how to use the /fix parameter of the command line. For me, it opens CUETools but do nothing more...

Thanks again,

Pimaga



CUETools versions 1.9.5 through 2.1.5 (current)

Reply #440
I still can't manage to make it work as expected.

I ripped a CD with a pregap of 00:08:00 and a data track of 00:08:00, with Confidence 3 in EAC to separate tracks and created a cue-file with current settings. Verifying in CUETools to write AR tags, but it doesn't recognize it, even when it asks for the log-file. Neigher can I make it recognize it when I enter the values manually.
Can't wait for a HD-AAC encoder :P

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #441
I still can't manage to make it work as expected.

I ripped a CD with a pregap of 00:08:00 and a data track of 00:08:00, with Confidence 3 in EAC to separate tracks and created a cue-file with current settings. Verifying in CUETools to write AR tags, but it doesn't recognize it, even when it asks for the log-file. Neigher can I make it recognize it when I enter the values manually.

I tried to verify this using dummy files with same lengths as in a log that you sent me. There were no problems:

Code: [Select]
[Verification date: 18.06.2009 21:31:09]
[Disc ID: 002a53cf-01dc7ff5-ec12aa10]
Pregap length 00:08:00.
CD-Extra data track length 00:08:00.
Track Status
 01 (00/03) No matches
 02 (00/03) No matches
 03 (00/03) No matches
 04 (00/03) No matches
 05 (00/03) No matches
 06 (00/03) No matches
 07 (00/03) No matches
 08 (00/03) No matches
 09 (00/03) No matches
 10 (00/03) No matches
 11 (00/03) No matches
 12 (00/03) No matches
 13 (00/03) No matches
 14 (00/03) No matches
 15 (00/03) No matches

Track [ CRC32  ] [W/O NULL] [  LOG  ]
 -- [420F3D4E] [00000000] W/O NULL
 01 [A1985E48] [00000000] [68B186E3]
 02 [EE896089] [00000000] [88E98B88]
 03 [57954675] [00000000] [AACB27CD]
 04 [070B9517] [00000000] [F515831E]
 05 [B7E0B086] [00000000] [7A5E2521]
 06 [7CED5E61] [00000000] [E8D30054]
 07 [1E83BC5D] [00000000] [9657E354]
 08 [E13DDE0D] [00000000] [234B0B5E]
 09 [B8003064] [00000000] [7188AB89]
 10 [257CA442] [00000000] [0A9E261D]
 11 [EE309B70] [00000000] [28A5C491]
 12 [75A0DDB5] [00000000] [159B3C57]
 13 [FF89AFE7] [00000000] [1383FD33]
 14 [EF48FB28] [00000000] [109FBFB4]
 15 [B2F6DF81] [00000000] [969C92FE]

Can you please compare your files length with the log? Foobar2000 can show you the file's length in samples. The length from log is calculated like this: (End sector + 1 - Start sector) * 588.
e.g. the first track should have length (34486+1-600)*588==19925556 samples.

My current hypothesis is that EAC made some tracks shorter, when it failed to rip them.

I will add a check for that in the next version i guess.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #442
Right now, I have to "Verify AR" on the first run, remember the confidence level for the pressing I want, then adjust the Accurate Rip "with confidence" in the Advanced Settings to choose which offset to apply, then run "Verify, then encode".


You should choose encode and verify and then choose fix offset from the pull down menu. It will fix the offset to the one which is closest to your rip.
This way the least samples are discarded.
Choosing the fix the offset to the pressing with the highest confidence level makes imho no sense at all. You're just discarding more samples then necessary.


I just tried doing that, but all that happens is that it encodes and shows the Accurate Rip pressing info. No Fix offset option. I'm using 1.9.5 btw. Is this a feature in the newer 2.0.2 version?

 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #443
OK, I continue to reply to myself :-)
I understand that when CUETools is invoked from the command line, the settings contained in the settings.txt file are applied, and I assume that they can't be modified by additional parameters.

In fact, I would like to split some CDImage.ape by some CDImage.cue with applying simultaneously an offset correction (not depending on accurip, but set manually according to the drive model appearing in the log file).
This works using the GUI, but with the /convert command, the split is done without the offset correction. Is it a bug or a feature ? Is there something to change in the settings.txt ?

Thank you in advance.


Command line support is very limited currently. Additional parameters, such as /offset, might appear in the future.

I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation,
which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.
We only needed it in the past to be able to use AccurateRip, but now we can do it without offset correction.
I will continue to support offset correction in CUETools, because there are probably a lot of people with different views,
but i'm not making it a priority.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #444
I just tried doing that, but all that happens is that it encodes and shows the Accurate Rip pressing info. No Fix offset option. I'm using 1.9.5 btw. Is this a feature in the newer 2.0.2 version?

Yep, that's how it works in 2.0.2. There's an option 'to nearest' in AccurateRip Fix offset settings. If it's turned on, the closest offset is chosen. If it's turned off, the most popular offset is chosen. You can also write a custom script which selects an offset for you.

Although my opinion on the whole offset correction thing is in the above message.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #445
I personally am not very fond of the whole idea of offset correction, because to me this seems like a totally useless operation,
which doesn't make a rip better. It only makes it worse by cutting some samples from the beginning or the end.


I only use offset correction in case of a repair: I sometimes combine two sources to make 1 accurate album. In such cases I use it to get all files on the same offset.
I know it's not making it sounding better, but it's just looks better in the log 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #446
Thanks a lot for your reply, I can understand your position (even if it is reassuring, for us neurotic geeks, to know that we have the exact same tracks as on the original CD).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #447
Obviously CUETools fail at decoding .ape files. Just tried to encode a CUE'd APE file to .ogg. Got broken files with a cracking noise instead.
eD2K link to the particular file, if needed, by PM...
audiophile // flac & wavpack, mostly // using too many audio players

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #448
Obviously CUETools fail at decoding .ape files. Just tried to encode a CUE'd APE file to .ogg. Got broken files with a cracking noise instead.
eD2K link to the particular file, if needed, by PM...


There's nothing obvious about you statement. CUETools converted my 1500+ .ape (v3.97) files to .flac without problems.

N.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #449
Well, in this particular case it is obvious to me. 
audiophile // flac & wavpack, mostly // using too many audio players