Changing default encode settings in virtualdubmod?

[Force-Attuned_Krogoth]

Is there a good way to change the defaults in virtualdubmod? Spelunking the webs, I learned how to make a shortcut that auto-loads a config file. But that's a limited option because windows won't let me set that shortcut (as opposed to virtualdubmod.exe) as the file type reference. I could open up the shortcut manually and drag the .avs into it, but DVDFab's folder structure has prompted me to use shortcuts to the .avs files themselves. And in case you haven't run across this, VD doesn't read .lnk files.

In summary, I could work around the issue, but I'd have to sacrifice organization somewhere. Anyone know a way to either set defaults in registry, tell the .exe to autoload config files, convince windows to route file types through a shortcut, or teach virtualdub to read shortcuts?

[Qyot27]

What are you trying to do in the first place? I really don't see the need to use shortcuts to do anything, and AviSynth can daisy-chain its own scripts with the Import command. The only foreseeable reason I could think of to use shortcuts is that the input and/or output folders were located on the Desktop, which can cause all sorts of problems anyway.

VDubMod can be called from the command-line, and you can batch script it to do so (i.e. BAT files, which script against Windows itself). If AviSynth scripts are no sweat, then that wouldn't be either. You just have to be aware of how Windows' PATH variable is set.

Code: Select all

virtualdubmod.exe /s"ScriptFile.jobs" /x

Considering the only place I saw a reference to *.vcf files was in the Run script... dialog where you can also find the *.jobs, *.syl, etc. filetypes in the dropdown, I'd think you could just swap that out. And it's fully possible to edit *.vcf/*.jobs/*.syl files in Wordpad before giving them to VDubMod.

If all these configuration files do is set the codec to encode with and the output folder, then it would probably be worth looking at other solutions than using VDubMod like this, as I've always found calling it like that to be cumbersome. mencoder is one option for an alternative, or if it's Xvid you're trying to use, you could use xvid_encraw directly (although it won't process sound). If you've found the particular configuration you're comfortable with, then just save it to a text file as a reference and whip it out whenever you need to do some encoding* - then just copy it over to the .bat script, tweak it for the particular files, and let it fly.

*if you decide on mencoder, then you can actually use mencoder.conf to edit the assumed defaults, which can make your standard mencoder call be in the form of mencoder input.avs -o output.avi - and that be it.

[Force-Attuned_Krogoth]

I use Vdub mostly for cutting clips. This means when I'm looking for a scene, I'm bouncing between a bunch of episodes. The shortcuts come into play because I used DVDFab to rip. When you do this, it makes a chain of four subfolders before actually laying the files down. I find this cumbersome, but leaving the folders where they are prevents slip-ups later. For instance, if I have to re-rip an episode (for example, to catch an intro before the opening credits) I have to remember to move the files somewhere else and then match the filenames in avs script. Because of this, I set up a series of shortcuts to the avs files so I can have an index of sorts that doesn't need to be redone every time I change something. I could move the avs files themselves to this index folder and have them pick the files from necessary subfolders, and that's probably going to be my fallback if I can't change Vdub defaults. But that has potential for headaches too, as the only difference between the scripts would be a folder name in the middle of the line. Easy to get mixed up and call the wrong episode.

The reason I'd prefer to set Vdub defaults is because clipping doesn't lend itself well to batch encodes. When I need a clip, I dig through the source, find it, cut it out, and drop it into my timeline before I forget. Thus I'm opening and closing instances of Vdub and each time I have to change the encoding from uncompressed to LAGS, and change from full processing to fast recompress. Yes, I could keep doing that manually, but what good is a labor-saving device that doesn't save labor?

I'm not very well-versed in avisynth scripting. If there's some way to have it feed configuration data to Vdub, that'd be an optimal solution. Even if it disrupts stability with other programs, I don't open my source in any other programs. I could make my index a series of shortcuts to Vdub that autoload config and avs files. But then I'd lose my direct association to the avs files when I want to edit those.

I hope I've clarified my situation here. Yeah, it's a minor problem. But even a tiny friction point can produce a painful blister. It's worth checking to see if there's a way to have the software accommodate the user, rather than the other way around.

[Qyot27]

I use Vdub mostly for cutting clips. This means when I'm looking for a scene, I'm bouncing between a bunch of episodes. The shortcuts come into play because I used DVDFab to rip. When you do this, it makes a chain of four subfolders before actually laying the files down. I find this cumbersome, but leaving the folders where they are prevents slip-ups later. For instance, if I have to re-rip an episode (for example, to catch an intro before the opening credits) I have to remember to move the files somewhere else and then match the filenames in avs script. Because of this, I set up a series of shortcuts to the avs files so I can have an index of sorts that doesn't need to be redone every time I change something.

This is the part I don't really understand. If your directory structure is so variable that it could easily break, then the best option is to make sure the scripts and videos are in the same folder, or at least easily within striking distance, and use relative paths. That information always seems to be missing or outright ignored by the guides, but AviSynth doesn't require you to use the full C:\yadda\yadda\yadda file path. If the scripts are in the same folder as the videos, just the filenames themselves will work, as would something like yadda\filename.ext, if the script was in the next folder up. That way you can move files around without fear of them breaking because things aren't in just the right place (and DGIndex can be set to use relative paths if you turn the Full Paths option off, and since DGIndex can autogenerate scripts, then you wouldn't have to worry about modifying them yourself). You just have to make sure the scripts are always either with the videos or in the same position in relation to them. It doesn't affect me because I just throw everything in one folder anyway.

The reason I'd prefer to set Vdub defaults is because clipping doesn't lend itself well to batch encodes. When I need a clip, I dig through the source, find it, cut it out, and drop it into my timeline before I forget. Thus I'm opening and closing instances of Vdub and each time I have to change the encoding from uncompressed to LAGS, and change from full processing to fast recompress. Yes, I could keep doing that manually, but what good is a labor-saving device that doesn't save labor?

I'm not very well-versed in avisynth scripting. If there's some way to have it feed configuration data to Vdub, that'd be an optimal solution. Even if it disrupts stability with other programs, I don't open my source in any other programs. I could make my index a series of shortcuts to Vdub that autoload config and avs files. But then I'd lose my direct association to the avs files when I want to edit those.

No, it's not possible for AviSynth to make VDub load its own config files. That's where using VDub's command-line interface comes in, as it's fully possible there. I'll explain something about this later.*

Also, it might be worth looking at the newest version of VDub proper (currently 1.9.5) rather than VDubMod, which hasn't been updated in 2-3 years, depending on which version you're looking at - I'm not totally up on the associated colorspace handling changes, but from a cursory readover it seems as though it's now possible to retain colorspace no matter which mode you have it set on. Whether it still incurs a conversion to RGB in the middle if set on Full processing mode I don't know, though. The newest version(s) also include a batch encoding wizard.



*Let's try something. Have the *.vcf file (myconfig.vcf, for example) set only Fast recompress mode and the Compression option. Then, make a new text file with this command in it (I'm assuming VirtualDub itself, not Mod; also take note I'm assuming where VDub and the config file are located in the file system):

Code: Select all

"C:\Program Files\VirtualDub\virtualdub.exe" /s"C:\Program Files\VirtualDub\myconfig.vcf"

Save the text file as vdublink.bat and close Notepad. Now, double-click on the .bat file. When VirtualDub comes up, is it configured and ready to go? That's about as much as you can probably hope for here. You could add that .bat file to your menu and just use it to load VDub when you need it instead of using the normal menu link to the program.