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 1925700 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 #1525 –
Quote from: Gregory S. Chudov on
Quote from: korth on
Should I have a choice to repair in the example below?
The repair script stops after verify.

You should. I will look into it.

I have XP64 running right now if that helps.

Quote from: Gregory S. Chudov on
Quote from: korth on
I've been seeing results like this one
where the last track has no matches in AccurateRip yet shows Accurately ripped in the CTDB.
Sometimes even when the CTDB differs by a few samples and the rip can be repaired, after repair the results are similar to above.

AR and CTDB ignore slightly different amount of data at the start/end of the disc. CTDB entry also might have a substantial offset, adding to this blind-spot or reducing it.

Some of these had an incorrect 'Overread into Lead-In and Lead-Out' setting (switched drives and apparently ticked by mistake) so the error is likely genuine.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1526 –
Hi,

I have recently used CueTools to convert over 3000 single image and cue ape files to flac while embedding the Cue files into the flac files.  At the time the EAC extraction logs (circa 2002 -2004 vintage) were in the same directory with identical file names and log extensions.  I had the "Write extraction log to "LOG" tag" option under tagging ticked.  Cuetools did not embed the log file - did I miss something?

If I stuffed up or Cuetools cannot do this (and even if it can, I suppose it is a bit late now) is there an application than can easily mass embed these logs?  I  have tried a few different taggers but none of them seem to automate the process.  I have tried tag.exe with the -f option but cannot get it to do this without specifying a specific file name and specific log name (no wildcards).  I was never good at writing batch files either although if one already exists that can do this ...

As I see it, it only needs to do 2 things,

embed logsin flacs where the file names match up within a directory structure with and withoug recursion, and,
write its own log where it lists any flac without a matching log file (mostly typos).

Any help would be appreciated

Regards,
Bob

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1527 –
Quote from: Gregory S. Chudov on
Quote from: eyes adrift on
Does anybody know if the "Correct filenames" option is available from the command line ? 
I recently renamed a big part of my library and I would like to "correct the filenames" in batch. 

It is not (yet) supported from the command line, but you can process the whole folder from the GUI.

I didn't know that I could proceed a folder recursively from the GUI. I thought the proceeding could only by made folder by folder but I was wrong.
I just tried. It's perfect. 

Thanks a lot ! 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1528 –
Can you help me decipher a CUETools verify log?

I don't understand which CTDBID represent my files.

Specifically, does the first line ([160f07dd] (44/99) Has pregap length 00:00:02) represent my files? And would that mean that my files match up with 44/99 other submitters?

[CUETools log; Date: 8/27/2011 6:32:34 PM; Version: 2.1.2a]
[CTDB TOCID: YZfDYvG.T7.KMiza0h3ci7VCHBU-] found.
        [ CTDBID ] Status
        [160f07dd] (44/99) Has pregap length 00:00:02
        [7db454bb] (55/99) Has pregap length 00:00:32
[AccurateRip ID: 0016cd0d-010201fb-b509510f] found...

I guess I just don't understand what CUETools is trying to tell me.

Many thanks!

EDIT: Does it mean that my files match up properly with 44/99 other database submissions?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1529 –
The database knows two different versions of this CD, one has pregap 00:00:02, other has pregap 00:00:32.
Your rip probably doesn't have a pregap (because this information was lost), so CUETools can't compare it.
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1530 –
Thank you. Just one more question (I need to know this! HA!): If I see the words "Accurately ripped" on one of the CTDBID status lines, is CUETools telling me that my files/disc matches up with other people's?

In other words, is there something (a MAGIC word or phrase) that I should be looking for to tell if my files/disc are comparable to other people's?

Another example:

Code: [Select]
[CUETools log; Date: 8/28/2011 5:44:09 AM; Version: 2.1.2a]
Pregap length 00:00:01.
[CTDB TOCID: ujvjyuIIqdR61HbcM3huXrxTUi8-] found.
        [ CTDBID ] Status
        [4996818b] (002/224) Has pregap length 00:00:00
        [04b5dfbf] (222/224) CD-Extra data track length 18:37:21, Accurately ripped
...


EDIT: So if I do NOT have a cuesheet or log file, I need to be fiddling with the Extra "Pregap" options in CUETools to verify my files are accurate, right?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1531 –
a1020012:
AFAIU, the data stored in CTDB that can used to repair your rip matches which mean that you actually cannot use CTDB to fix it because it is already perfect/fixed for CTDB. This information is a clue that your rip overall is likely not scratched (as a large part of it is not scratched) but as CTDB cannot store the data to repair 100% of the CD, you shouldn't use this clue to tell if your CD is scratched or not, it only tells you that a part of your CD is not scratched. Only AR can tell you if the whole CD is scratched or not.

Edit:
Yes, you need the pregap length, sometimes it will "work" without but only because a pressing without it also exist in the AR database.

The "magic phrase" you're searching for is "Accurately ripped" for all tracks within the same offset under AccurateRip ID with a confidence 2 or higher. (1 if you physically own the CD & never submitted it, which is unlikely if you don't know the pregap ...)

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1532 –
Many, many THANKS, sauvage78! IMHO, someone should write a short (a paragraph or two) tutorial/wiki on how to interpret these results. Unless you know what you're looking for, it can be frustrating trying to interpret the Verify Results Log. =)

EDIT: The tutorial should be called, "How to verify that your files have been accurately ripped using CUETools because you stupidly deleted your EAC log files and/or CUE files when you originally ripped your CDs about five years ago. Dummy."

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1533 –
I'd like to download the 1.95a version of CUETools(or whichever is the last stable before 2.0). Can anyone help me with that?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1534 –
I'd like to use CUETools to do some Accuraterip validation of flacs I have on Linux.  I can get the UI to start under Mono, but trying to load any flac files leads to ``Error: Unsupported audio type: /foo/bar/whatever.flac''.  I can see some vague discussion about this maybe working under Linux so I am wondering if I might just be missing some libraries or whatnot.  Has anyone gotten this to work?  I'm using 2.1.2a and the latest mono from Debian unstable, if it matters.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1535 –
http://www.cuetools.net/wiki/CUETools

Quote
Supported platforms

CUETools is a .NET application, written in C#. Binaries are available for 32 bit (x86) and 64 bit (x64) Windows versions. .NET Framework 2.0 and Visual C++ 2005 SP1 runtime are required. Users report they have been able to use it under linux, using Mono, but in this scenario only WAV audio is supported, as other codecs are not yet ported to C#.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1536 –
Thanks.  Some previous posts had implied that later versions might include their own managed codecs which would allow it to work, but I guess that's not the case currently.  I'll commandeer a Windows machine to use it.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1537 –
Any news regarding Wavpack Hybrid + Correction support ?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1538 –
... and support for Lossy M4A with embedded cuesheet (as 'Mp4 chapters')?
 

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1539 –
Hello,

I have not been reading through all the 62 pages but I didn't find much elsewhere in the forum (searching definitely doesn't help for that case).

I would like to point out to you an "issue" that can appear when you want to create one single image CD & cuesheet with CUETools (I'm using 2.1.2a) from a non compliant cuesheet (with gaps appended to the previous track) and multiple files (EAC rips at least).

As for the audio part, there is nothing to worry about, thankfully!

As regards the cuesheet, you may encounter unexpected things as long as you keep your .log files in the same folders as your extracted files.

To cut a long story short: CUETools seems to assume (at least on my tested rips) that the pre-gap lenghts in the EAC logs are always using hundredth of seconds, and not frames, which may indeed be the case according to your EAC settings.

However, if you have chosen to display time with frames, all your log rips will have pre-gap lenghts in frames already (TOC is always written in frames in logs, no matter what display setting you have chosen, pre-gaps are the only things affected by this in the log apparently) . Since CUETools supposes your pre-gaps are not in frames, it converts those numbers (for instance 0:00:00.73 becames 0:00.55) before applying the gaps to the new cuesheet (the one that goes along the newly created CD image) using the INDEX 00 & INDEX 01 structure.

I noticed this by subtracting the former to the latter: the gap lenght in frames didn't match the log one (in frames already) nor the non compliant cuesheet one (checking using foobar for the previous track length, converting to frames, then subtracting INDEX 00 from the non compliant cuesheet to eventually assess the gap in frames) unless multipying by 4/3 (as if converting from frames to hundredth).

Nevertheless, you will encounter the issue only using the drag 'n drop mode in CUETools with one of your track (or all of them, it doesn't matter) to create the aforementioned CD image & cuesheet, even if there is a .cue in the same folder. If you do open the non compliant cuesheet with CUETools then it will generate the new cuesheet according to it and only to it, without checking the .log for the pre-gaps.

Why would you have to use the drag 'n drop mode with one file of each rip's folder if the non compliant cuesheets give flawless results? For instance if you have decided to switch back to the good old method which consits in archiving with one CD image & cuesheet (foobar prefers it!), but that you keep both your old rips and new ones in a big folder, then searching for "02" in windows gives you the albums your ripped with multiple files and leaves the CD images where they are. If your search all the" .cue"s, you will have to process uselessly your old rips (for instance, again).

That's also EAC "fault" in that it doesn't write anything in the log that could lead CUETools to know whether you have chosen to display time with frames.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1540 –
Quote from: Dakeryas on
Hello,

As regards the cuesheet, you may encounter unexpected things as long as you keep your .log files in the same folders as your extracted files.


AFAIK, CUETools only parses text from the log file to get the 'COPY CRC' results. Pregaps and TOC info in the log are ignored.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1541 –
If you give it a cuesheet, yes, it won't look, but if you drag 'n drop one track (file) then it will build the log according to the log that's in the folder, no matter if there is a cuesheet that bears the same name as the log or not in the same folder, I've checked this for tenth of folders now.

The new cuesheet 's gaps match the old non compliant ones only if that's the thing you've opened  in CUETools, otherwise it will compute the pregaps itselft when fed with one track, and it will do it based on the pre-gaps of the .log (there is the problem if there are in frames or hundredth).

That's still much better than creating a new cuesheet with only INDEX 01 since the error between frames and hundredth is not so huge (3/4, 4/3).

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1542 –
Sorry Dakeryas,

Tested EAC Tracks rip converted to Image+cue.
I have duplicated your 'adjusted gaps' results in all 3 modes (not just drag'n'drop) by simply removing the cue file from the folder and leaving files+log.
In drag'n'drop mode with files+cue+log in the folder, dragging just the cue or dragging the whole folder results in normal gaps and dragging just one of the files results in the 'adjusted' gaps. I'll defer to the program developer.

One question: If you have the original noncompliant (with gaps) cue file, why would you drag'n'drop one of the audio files instead of that cue file?
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1543 –
Quote from: korth on
One question: If you have the original noncompliant (with gaps) cue file, why would you drag'n'drop one of the audio files instead of that cue file?


I did answer myself already  .

Quote from: Dakeryas on
Why would you have to use the drag 'n drop mode with one file of each rip's folder if the non compliant cuesheets give flawless results? For instance if you have decided to switch back to the good old method which consits in archiving with one CD image & cuesheet (foobar prefers it!), but that you keep both your old rips and new ones in a big folder, then searching for "02" in Windows gives you the albums your ripped with multiple files and leaves the CD images where they are. If your search all the" .cue"s, you will have to process uselessly your old rips (for instance, again).


Maybe I should search for "02" using an advanced research to search through files (Windows 7 does not offer this by default unless indexing .cues or something) so as to process the non compliant cuesheets only.

I also noticed that deleting temporarily the .cue and leaving the files and the .log indeed lead CUETools to create the .cue assuming that the .log displays gaps in the hundredths. This may be useful for some that didn't bother creating cuesheets when ripping and have somewhat found a use for them (and are to lazy to insert the CD again), but it gives false results if you have ripped in frames.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1544 –
This result is a bit hard to interpret: In the CUETools window, it says
CTDB: could not be verified.


In the log file, it says

[CUETools log; Date: 09.09.2011 22:31:21; Version: 2.1.2a]
[CTDB TOCID: KmukQplLtnXLv0PmXDapTnEmYHM-] found.
        [ CTDBID ] Status
        [230dd736] (21/21) Has pregap length 00:00:32



So ... 21 of 21 or not verified?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1545 –
Yeah, could not be verified == not found. But a similar CD exists in the database, which has a pregap and a confidence level of 21/21
CUETools 2.1.6

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1546 –
Could be a bit more informative I think. But ... I just recorded a new personal high: 9861 errors corrected in one disc! (One track, actually.) That's a pretty nice tool

Edit: also, got a case with six tracks of 18 corrected.

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1547 –
I finally came across a CD with a non-silent pregap. I had decided to set Gaps handling to Gaps Appended because I'd rather use a PREGAP command for a silent pregap than have a silent HTOA file. I figured if I ever ran across a disc that actually needed the HTOA I would address it then.
I guess I could set it back to Gaps Appended + HTOA and scan the HTOA file (if written) every time to see if the [W/O NULL] CRC is 00000000. Then if it is I could delete the HTOA and edit the cue file adding a PREGAP command.
I just searched through the posts and found a similar option requested last year. Would be much easier if CUETools could do this for me. Say a checkbox under Gaps Appended + HTOA saying Use Pregap if HTOA is silent.
korth

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1548 –
Gregory, will you add support for XLD log format?

CUETools versions 1.9.5 through 2.1.5 (current)

Reply #1549 –
Probably. I got married and moved from Russia to Canada just three weeks ago, so i am a bit busy at the moment
CUETools 2.1.6