ffmpegsource

[StarMasayume]

Thanks Qyot I have vista at home so I should just be able to copy the path by the way you mention? I do have the files in separate locations so I could put the avs file in the same folder and try the relative path.

I guess I could try using the files from the 2.13 version. I downloaded all three things not sure which one I really wanted. ^^;

I'll see what I can do tonight and then give an update.

[Mister Hatt]

Use the latest SVN revision build (r292) or if you can find them somewhere, any builds r308 or newer. The DLL's go in your avs plugins dir for autoloading, the exe's go in your system path (%PATH%\windows\system32), however unless you're indexing large things you don't need the exe. Ignore the documentation and avsi file. One is available online, the other is stupid.

As for paths, go relative.

[Kariudo]

As far as VDub vs VDubMod, the mod version is years out of date

Using updated stuff is nice/generally a good idea, but being old alone isn't enough to discount vdubmod

lacks speed optimisations

Bummer, but I'm guessing that the speed optimizations amount to relatively little in reality. Don't get me wrong, optimizations are good...but shaving 1 second off of a 1 minute encode is hardly something to get excited about.

outright does some audio things wrong

I'd be more concerned if:
-you provided an explanation of how it messes up audio
-editors used audio from their source along with their video clips (though it does happen, it's not a common occurrence)

fucks with your colourimetry

And what if you don't use full processing mode? (like say, fast recompress)
Does it really even matter? (are changes clearly visible? )

and includes the ability to open ogm files (but not ogv or ogg) internally.

Although this was one of the main points of vdubmod, it's not a feature used by most.

The point is that it's outdated. VDub and avisynth development is somewhat done hand in hand, the latest vdub always supports the latest avisynth with internal optimisations for various things and vice versa. Using a current avs with an old vdub, especially one as flawed as vdubmod is just stupid.

I completely agree that vdubmod is very outdated, but again I will say that for the purpose of making clips there is nothing wrong with continuing to use vdubmod. Optimizations are nice, but they probably aren't necessary.
You might have a point if you're using vdubmod to encode a finished amv with xvid (and muxing an audio stream in) for distribution, but we can't make that call quite yet.

The bottom line is this: please stop passing your opinion as absolute truth, and the best/only way to do things, it's annoying.

[Mister Hatt]

VDubMod cannot handle VBR mp3 properly. Almost all music sources the editors I know tell me they use are VBR or ABR, which messes up sync and timecoding, and is especially noticable on playing back from a point or trimming. Regular VDub fucks up VBR still but it generally gets ABR correct.

While full processing in regular vdub converts to RGB32 with <arbitrary matrix>, all compression types in vdubmod convert to RGB of some sort. There is no way around it, but using fast recompress uses Rec.601 always.

VDubMod doesn't have SBC. Which is kind of essential for any ASP formats (xvid, divx, microsoft mpeg4...) Admitedly VDub doesn't exactly have it either but it can at least allow codecs that have it to use it. I guess if you need full SBC and are using lavc (because xvid is terrible) then it's time to break out NanDub.

Optimisations don't necessarily mean speed. For example, colour quantisation optimisation: how the display shows colours for various non-BGRA clips on your BGRA monitor. VDubMod will always do it wrong (uses smtpe matrices no matter what IIRC) while regular VDub allows you to choose. The speedups are more than noticable though. Decent iDCT is kind of essential for decoding things at a reasonable pace.

[Kariudo]

Forgot about VBR mp3 there (had my share of headaches with that one a few years back)

I did a cursory search on premiere pro and sony vegas to see what color spaces they support (from the guides here, I had it in my head that editing programs worked with RGB24 or RGB32). I don't have the time to dig much deeper, but it does seem that this would be the case given the circumstances most people here are working with. Color space conversion(s) are going to happen somewhere (preferably through avisynth, though I'd trust vdubmod over whatever editing program you have).

I thought the entire point of fast recompress was to just shove the video information to the codec without touching the colorspace (ref)

Either way, losses from colorspace conversions are generally unnoticeable to people unless you do it something like 30 times. We're not looking for mathematically perfect conversions, and as long as any deviation from that is [relatively] small and consistent then people won't notice.

All in all, I think my statement still stands. That is, Vdubmod is old and outdated but fine for the purpose of generating clips for use in <insert nle here>.

[mirkosp]

I thought the entire point of fast recompress was to just shove the video information to the codec without touching the colorspace (ref)

Colorspace and colormatrix are two different things. What Mister Hatt is saying is that using fast recompress in virtualdubmod with HD footage will result in the colormatrix of the footage to be swapped unproperly, as HD footage has a Rec.709 colormatrix, but vdubmod will force the Rec.601 colormatrix. And, even in the case that it did somehow convert colormatrix properly, it would still be messed up in the final encode, since, unless you specify it, playback devices assume the colormatrix based on the resolution, and HD footage gets recognized as Rec.709.
The avtech never really covered colormatrix though... at one point I wanted zarx to cover it but he was like "meh, it's too complicated and people won't care."

[Kariudo]

gotcha.
Are the errors introduced by using rec.601 instead of rec.709 noticeable in anime? (and noticeable when the same error is present throughout the entire video?)

[mirkosp]

gotcha.
Are the errors introduced by using rec.601 instead of rec.709 noticeable in anime? (and noticeable when the same error is present throughout the entire video?)

Well, having a wrong colormatrix will misrepresent colors. If you improperly change colormatrix efficients once throught the process somehow, the difference can be still considered slight and colors are still somewhat natural, at least for anime... so it probably won't be noticeable unless one knows, especially if this difference is consistent. But if you wind up using vdubmod once or twice during your editing process, and then add the x264 step that assumes the colormatrix through resolution unless you specify... what you get if you have an HD input that you decide to edit at 848x480 would be along these lines (left is proper colormatrix, right is getting colormatrix wrong three times in the process, x264 included):

Color do get odd at this point. You can already notice how green starts to become blue.
Note how the red channel gets bad upsampling, too...

[Mister Hatt]

I'd trust vdubmod over whatever editing program you have.

I sure wouldn't. VDubMod doesn't even attempt to guess, it just uses Rec.601 EVERY time regardless. Colour spaces are different to colour matrices, as mirko said. I don't know what programs you assume I use but they are correct in what they use.

I thought the entire point of fast recompress was to just shove the video information to the codec without touching the colorspace (ref)

You seem to be under the assumption that AVTech guide is correct. It isn't.