¶Incompatibility between VirtualDub 1.6 and Archos Multimedia MPG4 Translator
Disclaimer: Neither I nor VirtualDub is affiliated with Archos, and I cannot provide technical support for Archos products. Please contact Archos technical support for general problems with Archos devices or the MPG4 Translator.
Those of you who may have tried using the Archos MPG4 Translator with recent versions of VirtualDub (1.6+) may have encountered this error:
Cannot open file "jobs.avs":
The filename, directory name, or volume label syntax is incorrect.
This is due to an incompatibility with the Archos MPG4 Translator software due to a change in command-line parsing in VirtualDub 1.6. For a quick fix, use VirtualDub 1.5.10 with the Translator software instead. You can obtain 1.5.10 from the File List for the VirtualDub project on SourceForge. If you are willing to hex edit a copy of the Archos software, though, there is a workaround.
The Archos tool uses an unusual syntax to quote filenames in the command-line that it passes to VirtualDub. It quotes the switch as well as the filename that the switch references:
"VirtualDub.exe" "/sc:\path\jobs.avs" "/x"
VirtualDub 1.5.10's command-line parser is a bit unusual in that it accepts the above syntax, despite it being contrary to conventions — the NT DIR command, for example, does not accept quoted switches. It also requires that the filename be immediately adjacent to the switch, without an intervening space. In 1.6 I cleaned up the command-line parsing to accept more conventional formatting, including removing the dumb adjacency requirement, but the new parser doesn't allow switches to be quoted. The result is that the entire /s switch is interpreted as a filename, which then results in the invalid path error.
(As a side note, the jobs.avs file is actually a VirtualDub script, and cannot be loaded into Avisynth.)
The syntax that was originally intended for filenames that must be quoted, and which works with both VirtualDub 1.5 and 1.6, is this:
"VirtualDub.exe" /s"c:\path\jobs.avs" /x
If you are willing to do a little hex editing, it is possible to modify the Archos software to use this syntax. I won't take responsibility for issues that may arise for doing this, nor have I tested this extensively, but it seems to work. There are two strings that need to be edited in the data segment in version 3.0.9:
000803ad: 22 20 22 2f 73 |" "/s| 000803ad: 22 20 2f 73 22 |" /s"| 000803b3: 22 20 22 2f 78 22 |" "/x"| 000803b3: 22 20 2f 78 00 00 |" /x..|
I've contacted Archos about trying to get this resolved and have gotten an affirmative ACK from technical support, but not one from engineering staff yet. If anyone knows of other front-ends that were impacted by the change in command-line parsing, let me know; I'd like to disallow the quoted switch syntax going forward, but if it causes enough problems I might look into rewriting the parser to allow it again.