virtualdub don't support the unicode filename in command line..?

[flying2ndsky]

is it right ?

yesterday i tried a vdscript in cmd line.
it worked good for the arguments of ascii(alphabetical) filenames, but didn't for unicode filenames', even for the same files in different filename types.

The following is an example of that problem. The command is intended for applying an wav extraction vdscript(wav.vdscript) file with two vdscript' arguments of input & output filename.
it's fine for ASCII(alphabetical) filenames, and works great.
but if filename changes to unicode type, then display that error message, Cannot open file "(":

>vdub64 /i wav.vdscript "fds fdkl lkksldfl.avi" b.wav
VirtualDub CLI Video Processor Version 1.10.4 (build 35491/release-AMD64) for AMD64
Copyright (C) Avery Lee 1998-2009. Licensed under GNU General Public License

AVI: Opening file "G:\virtual dub\VirtualDub64 1.10.4-AMD64\fds fdkl lkksldfl.avi"
Beginning dub operation.
Ending operation.

>vdub64 /i wav.vdscript "(アニメ BD) 銀河英雄伝説 外伝 黄金の翼 (1440x108
0 x264-flac 24fps).AVI" "C.WAV"
VirtualDub CLI Video Processor Version 1.10.4 (build 35491/release-AMD64) for AMD64
Copyright (C) Avery Lee 1998-2009. Licensed under GNU General Public License

Cannot open file "(":

therefore i'd investigated this stuff, and i found that the vdscript file is in ANSI type.
it seems in default that virtualdub produce a vdscript file in ANSI (ASCII) type.
so i changed the vdscript file' type to UNICODE type and retried that job for unicode filename argument, but failed until now.

Is there any solution for that unicode filename problem for virtualdub' CLI (vdub64) ?

thanks in advance.

[LigH.de]

A question probably best asked directly to Avery Lee, author of VirtualDub... in the meantime, you could try to let it load the ShortFileName (8.3 format) of this file. The FOR batch command supports this as %~s prefix. Another way to obtain short filenames where required is "dir /X".

[flying2ndsky]

A question probably best asked directly to Avery Lee, author of VirtualDub... in the meantime, you could try to let it load the ShortFileName (8.3 format) of this file. The FOR batch command supports this as %~s prefix. Another way to obtain short filenames where required is "dir /X".

thanks for replying, LigH.de.

i'll try it.

[flying2ndsky]

A question probably best asked directly to Avery Lee, author of VirtualDub... in the meantime, you could try to let it load the ShortFileName (8.3 format) of this file. The FOR batch command supports this as %~s prefix. Another way to obtain short filenames where required is "dir /X".

I've tried that method, but it fails in unicode file-path names

it works well for the alphabetical(ASCII) long file-path names.
but if just only a unicode character is included in the shortend file-path name, then the file fails to be opened to vdub process.
Cannot open file "(":

[El Heggunte]

I've tried that method, but it fails in unicode file-path names

it works well for the alphabetical(ASCII) long file-path names.
but if just only a unicode character is included in the shortend file-path name, then the file fails to be opened to vdub process.
Cannot open file "(":

But of course. The "8.3 filename rule" was invented in the pre-Unicode era. In fact, and speaking in general, the so-called Information-Technology still is designed around the limitations from the 7-bit era

[flying2ndsky]

But of course. The "8.3 filename rule" was invented in the pre-Unicode era. In fact, and speaking in general, the so-called Information-Technology still is designed around the limitations from the 7-bit era

You hit the nail on the head.
Now it works for many situation, and be needed for someone like me.
is it windows's cons? or DOS's pros?

[LigH.de]

Unicode file names should be supported since v1.10.3; but maybe only in the GUI version?

In the meantime, I will try to contact Avery Lee, it appears to be a little "inconvenient" these days.

By the way, what does your script do at all? And ... maybe it's so simple, you could use ffmpeg instead?

[flying2ndsky]

Unicode file names should be supported since v1.10.3; but maybe only in the GUI version?

yes, surely it is supported in GUI mode, but seems not in CLI mode.

what does your script do at all? And ... maybe it's so simple, you could use ffmpeg instead?

in fact, i'm a newbie to the video processing, so i don't know much about video processing, i.e. encoding, decoding, & filtering, ..etc.
but i know ffmpeg is a great aplication.
btw, sometimes virtualdub is needed for me to processing some video clips.
and plainly speaking, i like to use virtualdub.

[shekh]

It seems the problem is not command line itself but the script (wav.vdscript). Why dont you post it?
I dont know yet but it may be possible that arguments (filenames) get expanded instead of passed as variables.

[flying2ndsky]

It seems the problem is not command line itself but the script (wav.vdscript). Why dont you post it?
I dont know yet but it may be possible that arguments (filenames) get expanded instead of passed as variables.

sure, i guess it must be the script problem, as i mentioned it at the first posting in this thread.
windows' cmd.exe supports well the unicode file-path name handling.(perhaps, in default, windows may support UTF-16 LE).
but, virtualdub's job script method couldn't do well with unicode file-path names.
in default, virtualdub produces the virtualdub.jobs file in ANSI(ASCII) TYPE, and generates other script(.vdscript) files in same manner.
that's the point of this unicode file-path name's problem.
there are two points of the problem.
1. Since the job's script file is ANSI type, then unicode file-path name cannot be written on that ANSI file safely without any broken character.
2. what if we made the job' script files in UTF-8 or UTF-16 LE ?
--> i tried this several time for UTF-8 and UTF-16, and failed all. it seems vdub couldn't read the unicode file-path name from the script.
althought there exist several methods to avoid that problem in using the vdscript, just i've been wondering about the existence of the solution in virtualdub itself.

[LigH.de]

It's not the text format shekh wonders about, it's the script code.

Please post your script!

[flying2ndsky]

It's not the text format shekh wonders about, it's the script code.

Please post your script!

here it is, wav.vdscript

VirtualDub.Open(VirtualDub.params[0]);
VirtualDub.audio.SetMode(1);
VirtualDub.SaveWAV(VirtualDub.params[1]);

it works well with ascii file-path name' files

[shekh]

1. Since the job's script file is ANSI type, then unicode file-path name cannot be written on that ANSI file safely without any broken character.

The main structure is ANSI, but then individual parameters like file names are encoded using UTF-8 and then wrapped, looks like "\xd0\xb0\xd0\xbd\xd0\xba\xd0\xb8 (1973).avi" etc.
So it is not easy to edit but it does preserve characters that were passed in.

VirtualDub.Open(VirtualDub.params[0]);
VirtualDub.audio.SetMode(1);
VirtualDub.SaveWAV(VirtualDub.params[1]);

I will check it, for the sake of virtualdub love

[shekh]

The defect is in "VirtualDub.params" part, it makes strings encoded to default multibyte encoding instead of UTF-8.
And there seems no other way to get params.

[LigH.de]

I wonder why short filenames don't work, I believed they are ASCII only. Are they not as unambiguous as hoped?

[shekh]

Afaik 8.3 names are restricted to ascii. If long name is all japanese then 8.3 will consist of some random numbers..

[flying2ndsky]

The main structure is ANSI, but then individual parameters like file names are encoded using UTF-8 and then wrapped, looks like "\xd0\xb0\xd0\xbd\xd0\xba\xd0\xb8 (1973).avi" etc.
So it is not easy to edit but it does preserve characters that were passed in.

that' right. here's at you. my mistake.
in GUI(veedub, veedub64), the unicode file-path name wrapping process works well. but in CLI(vdub, vdub64), this wrapping process didn't work properly. i thought that's the problem !!!

I will check it, for the sake of virtualdub love

thanks for checking the code. cheers for virtualdub love !!!

I wonder why short filenames don't work, I believed they are ASCII only. Are they not as unambiguous as hoped?

even though the filename is unicode, windows cmd's short filenames feature works well. but in the case of unicode file-path name, the cmd's shortened file-path name for it has the possibility of including some unicode characters. that's the problem !!!
if there were some user configurable options for the short filename in windows' cmd, that would really hit the spot.

please refer to the following.
this batch code is for displaying the difference between the cmd's shortened file-path name and the original input file-path name.
EXAMPLE4WIN8.3short.bat

@ECHO Off
setlocal
echo( & echo( & echo( Here is original file-path name : "%~1"
echo( & echo( & echo( Here is short file-path name(in windows features) : "%~sdpnx1" 
pause
endlocal

here is the output for the batch file's execution with a parameter of input file name.

>EXAMPLE4WIN8.3short "G:\ENCODER\virtual dub\VirtualDub64 1.10.4-AMD64\(アニメ BD) 銀河英雄伝説 外伝 黄金の翼 (1440x1080 x264-flac 24fps).avi"


 Here is original file-path name : "G:\ENCODER\virtual dub\VirtualDub64 1.10.4-AMD64\(アニメ BD) 銀河英雄伝説 外伝 黄金の翼 (1440x1080 x264-flac 24fps).avi"


 Here is shortened file-path name(in windows features) : "G:\ENCODER\VIRTUA~1\VIRTUA~1.4-A\(アニ~1.AVI"

btw, there are still survived unicode characters in the shortened file name.

Afaik 8.3 names are restricted to ascii. If long name is all japanese then 8.3 will consist of some random numbers..

No, it seems not.
as you have noticed, the 8.3 name feature in windows is applied for the unicode file-path names.
and it seems that the using random number for wrapping the unicode file name is only for the virtualdub's unicode handling method and windows cmd's 8.3 feature is somewhat different to it.

[shekh]

As I said, the failure is during script processing. You may try to change system 8-bit encoding to UTF-8 if you can live with it.

[flying2ndsky]

You may try to change system 8-bit encoding to UTF-8 if you can live with it.

Sure, i can't !!!
already i solved out such problems for my cases, there's no more need to live with it.
but i'm just curious about the existence of the solution in virtualdub itself

[LigH.de]

Well, I wrote a mail to Avery Lee. No reply yet.

[flying2ndsky]

Well, I wrote a mail to Avery Lee. No reply yet.

i hope you get the good news soon.

[rjwolfe]

Found in http://www.virtualdub.org/docs/vdscript.txt

Undecorated strings (VirtualDub 1.6.1+)
---------------------------------------
Because string paths with escaped backslashes are difficult to create from
batch files, and some languages may not have UTF-8 conversion support,
Sylia supports an alternative syntax for strings: strings prefixed with u
or U are treated as undecorated, ANSI encoded strings. An example:

VirtualDub.Open(U"e:\test\test.avi");

The string is automatically converted from the system ANSI code page to
UTF-8 in the script system before being handed to the command system. This
allows file paths to be directly inserted in scripts without the need
for escaping or text conversion.