Skip to main content


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: Auto exit with return code? (Read 767 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Auto exit with return code?

Can cuetools be sanely controlled from a script giving sending errors to stderr per track?

I have a very halfassed python script I've been using with EAC for encoding,  but now that I wan't to add more functionality EAC isn't easy to work with as it has no way of exiting after extraction,  let alone with return codes. So I've been looking at cuetools so I can get away from using pskill and parsing the logs.

Re: Auto exit with return code?

Reply #1
Well, I did find you can use 2 switches with EAC, -extractmp3 and -close (there is also -extractwave) to make EAC semi-functional in a script. Apparently there is still some dialogue boxes that can pop up on certain errors that require user input, so error handling is still a bit shaky with EAC. If you're pretty sure things will go right, or don't use certain options like AccurateRip, EAC might work O.K. If AccurateRip is implemented in a script you could leave the option off in EAC.

CUETools still looks handy, I'm just not sure about putting it forth into a batching environment.

Re: Auto exit with return code?

Reply #2

CUETools Console applications
CUETools.exe is not intended to be run from a batch file and would need help (pskill) to terminate. Encoders used by CUETools.exe have limited encoding option support.
CUETools.ConsoleRipper.exe extracts to WAV only.

Re: Auto exit with return code?

Reply #3
Right about the ripper but it appears doable because the ripper does perform a meta look up and stores that info. into the .cue and .log (barcode + AccurateRipID). With that info., it's down to accurately cutting up the single .wav file and figuring out my CUETools error... with hope in my eyes :-).

After opening and closing CUETools apparently it should of created a profile, according to the wiki at least. But with this command...

Code: [Select]
./cuetools /fix "C:\Users\%username%\Downloads\CUETools_2.1.6\test.cue"

I get this: "Error: Object reference not set to an instance of an object."

There is also /convert and /verify, but all give that error. I'm guessing /fix is what is desired, so I'm using that. Regardless though, something appears to be missing that the wiki isn't too clear on (I did open the program, change a few options and close it). Manually loading the .cue and verifying the 1 large .wav ripped, by the ripper, comes back with 5/5 clean tracks (except it says there is 1 file listed as "No Match", which I assume is the entire single .wav itself?)

So, cutting the .wav and figuring out that instantiation error seems to be my hurdles right now.

Re: Auto exit with return code?

Reply #4
O.K.... mistakes were made. I figured out the error and figured out CUETools can cut .wav files... but, the ONLY problem I have now is the UTF-8 conversion. I've checked all profiles and have unchecked force ANSI compliance and have even tried the Keep original name in cue option.

No matter what the filenames written to disk are garbled. I can script that in, but I'm having a hard time at this point accepting this problem of loosing UTF-8 as one of CUETools and not one of my own (I've made so many at this point... it has to be me).

I still wondering if the source for 2.1.6 is available (I found 1.9), that could help too. But all in all, I'm very happy so far.

Re: Auto exit with return code?

Reply #6
To clarify, I'm not currently testing this under python, but using powershell on Windows 10, but both are set to UTF-8 by default.

In that thread the .cue files were not written in UTF-8 from the start (not sure how or why), but that is not the case here with consoleripper which seems to properly inherit its encoding...

Code: [Select]
./CUETools.ConsoleRipper --secure --drive G --offset 6

... does indeed produce correct UTF-8  .cue files. Even after CUETools has finished, the new .cue is correct as well. So when the command is spawned, either CUETools is not using the correct encoding or ignoring the option to keep the names, or FLAC is dropping the ball or not being ran under UTF-8 encoding by CUETools.

Re: Auto exit with return code?

Reply #7
So you didn't even try converting the original UTF-8 CUE to UTF-8 BOM before running through CUETools.exe...

Additional reading:
Try a search in the CUETools subforum for the term codepage.


Re: Auto exit with return code?

Reply #8
I'm sorry, the results are unexpected from a user perspective so no I did not.

Re: Auto exit with return code?

Reply #9
In that case, can I make a suggestion to CUETools for UTF-8 support?

At least in my personal experience, I've developed codepage autodetection tools to automatically probe for ASCII first, then probe for valid UTF-8 second, before probing for any other encodings. ASCII is the simplest and saves time, and as far as I know, no other code page will decode as valid UTF-8, so if you test for that 8 bit encoding first, it's pretty much guaranteed that your text is UTF-8 and not something else.

Re: Auto exit with return code?

Reply #10
It does have UTF-8 support, or seemingly locale. The problem appears to be on submission to the DB, as the problem strings are stored in the DB itself. When I searched for "codepage" as korth suggested I found this page..... It could be detected like you mentioned on submission with the client reporting locale (undependable), but something must exist server side as I know many people in India use UTF-16, so unless all those submissions are dropped, there has to be something in place already for BOM.

I looked through a lot of the 2.1.7 source files and didn't see anything related to this, all the programs seem to unsurprisingly use locale EXCEPT when reading .xml, then UTF-8 is chosen.

Re: Auto exit with return code?

Reply #11
I found this page.....
That was addressed

I've tested (including 2.1.7), confirmed, and added a note on the wiki about wide characters interpreted as single-byte characters for UTF-8 input without BOM. This still needs to be added to the issue tracker.

filenames created using UTF-8 cue without BOM as input
11 Lakmé - Acte I - Flower Duet _ Dome Épais (Remasterisé En 2009).flac
12 Les Contes D'Hoffmann, Act Four_ Belle Nuit, Ô Nuit D'Amour (Nicklausse_Giulietta_Choeurs).flac
13 Les Pêcheurs de perles_ A cette voix quel trouble... Je crois entendre encore (Nadir).flac

filenames created using UTF-8 BOM cue as input
11. Lakmé - Acte I - Flower Duet _ Dome Épais (Remasterisé En 2009).flac
12. Les Contes D'Hoffmann, Act Four_ Belle Nuit, Ô Nuit D'Amour (Nicklausse_Giulietta_Choeurs).flac
13. Les Pêcheurs de perles_ A cette voix quel trouble... Je crois entendre encore (Nadir).flac

Note: The underscores are replacements for reserved characters ":", "/", etc.
Les Contes D'Hoffmann, Act Four: Belle Nuit, Ô Nuit D'Amour (Nicklausse/Giulietta/Choeurs)

Re: Auto exit with return code?

Reply #12
This still needs to be added to the issue tracker.

Should it be? Up front I'm not a career coder or paid programmer or anything like that, but if the "error" is in the DB, is fixing it in the client the way to go? I guess any fix is a fix really, and from what I've read decoding UTF-8 as UTF-8 BOM doesn't present problems. I'm currently using the first python answer from this SO page.

Again, not a career coder and I don't have MS Studio anything yet, but in "CUEToolsDB.cs" (2.1.7) on line ~108, there is variable "ctdbRespEntry" that _looks_ like a candidate for a decode() . No matter where the right spot is, obviously everything would have to be decoded before writing the .cue file, but I don't see a main entry point for that yet.

I'm not sure where people go today to learn specific things in specific languages. I know StackOverflow is kind of the right spot, but if you want something like, say.... how to add ripping individual tracks to "CUETools.Ripper.Console.exe"   :D  :D, where do you go? FWIW to anyone else interested in the same thing, it looks like all info. to rip per track is sitting in the source file, It just needs a little math in a loop to make it work as it already has the file writer, gap detection and sectors for each track. The things lost on me are which values for CDDA the math ops. require and how to verify them via AccurateRip.

Here's the part with "ctdbRespEntry" I mentioned, if I get MS studio or something I'll try it....

Code: [Select]
// In "CUEToolsDB.cs" for version 2.1.7, line ~108
foreach (var ctdbRespEntry in ctdbResp.entry) // but is ctdbResp.entry even the right individual thing?
if (ctdbRespEntry.toc == null)
continue; += ctdbRespEntry.confidence;
var entry = new DBEntry(ctdbRespEntry); // add a decode() here on ctdbRespEntry?

THANKS FOR THE HELP korth!! Those links helped put some other puzzles together, and sorry I missed the initial BOM issue (I'm old dude :-P);

Re: Auto exit with return code?

Reply #13
Based on the limited details provided I'm unable to follow step-by-step what you're doing so here's a few notes.
'Keep original filenames' would only be possible for 'Image' to 'Image' or 'Tracks' to 'Tracks'. You can't keep the original 'Image' filename to name 'Tracks' or keep the original 'Track' filenames to name an 'Image'.
You seem convinced of an issue with the online database (CTDB).
It is possible you're getting cached metadata stored in the local DB from a previous run.

When popup windows are suppressed in CUETools the top metadata source is used first and any missing data filled by other sources according to your settings. The local DB metadata would produce filenames and tags "the same as last time".

The Local Cache (local DB), CUE Data and Audio File Tags are local. MusicBrainz, Discogs and freedb are from the online database (CTDB).

On further testing of CUETools (using UTF-8 CUE without BOM as input) I confirm that although wide characters are not correct in the CUE data, track filenames and metadata, the output cue file does contain correct characters. However, the new cue file was UTF-8 without BOM and if used as input in CUETools, wide characters were again not correct in CUE data, track filenames and metadata.
ConsoleRipper also wrote the CUE UTF-8 without BOM.

SimplePortal 1.0.0 RC1 © 2008-2021