Aaron Isotton

Undocumented Features and Limitations of Helix Producer for Windows

Command Line Parsing

The command line arguments (such as the title, author etc) are parsed as follows:

  • Strings containing spaces can be quoted using double quotes. Single quotes don't work!
  • Inside a quoted string, double quotes must be escaped with a backslash. Notice that no other characters (including the backslash) are escaped.

Output

All output seems to be written to stdout. It uses some utterly stupid trick for some stupid console magic which makes the output very hard to parse.

First, it outputs the program name and version normally. Then, it (generally) does the following.

  1. It outputs some "initializer" text, such as "Initializing...", without CRs or LFs.
  2. Then it output a CR, 80 spaces, followed by another CR to "clear" the line.
  3. Then it outputs the "real" action, such as "Reading file". It uses the same CR-80 Spaces-CR sequence again whenever it needs to update the line.
  4. When it is done, it outputs a CR LF sequence.

Field Limitations

All fields except the keywords field are limited to 255 characters. I don't know about any limitation for the keywords field.

Error Reporting

Helix Producer has a totally messy way to report errors. As far as I found out, there are the following ways to detect errors:

  • The Exit Code. When the process' exit code is non-zero, something went badly wrong, and it doesn't write the output file. Such errors include an unparseable command line and similar things.
  • When the exit code is 0, this does not mean that the process was successful; in fact, Helix Producer returns 0 in most cases even if it failed.
  • The Output. Helix Producer outputs (among others) lines starting with "Info:", "Warning:", and "Error:". Before exiting (and at some other points during the encoding process) it also outputs an error and warning count. Unfortunately, these are nothing to go by: there are cases when it outputs errors even if the encoding worked.
  • The existence of the output file. Unfortunately, you cannot say "if it wrote the output file, it worked, otherwise it didn't". Sometimes, for example, if it doesn't find a suitable decoder for the video data, it will write an output file with all black frames and with an audio stream.

As you can see, there's basically no way to detect whether the encoding worked or not except looking at the output carefully and examining the generated file. This is of course very negative if you want to automate the process.