Right, but I was wondering about that one specifically because the MCTemporalDenoise takes place as part of the MergeChroma, rather than being a separate thing.

This line of code:

is a single operation, not two separate steps. If you want to break that into two separate steps, you have to do it this way:

Step1:
lum=last
chrom=MCTemopralDenoise(settings="Very High")

Step2:
MergeChroma(lum,chrom)

But you have to use both steps in the same script.

I thought you meant to put slow filters like QTGMC and a few quick filters in one script, save the results, then run MCTD on the results using a second script.

How does that differ from creating an AVI for 'lum', then a separate AVI for 'chrom', and then merging them in a different script?

You'll save little or no time by separating a MergeChroma operation into two files or two scripts. It's MCTemporalDenoise itself that takes time, whether it's used with MergeChroma or not. If you don't want to use MergeChroma, then instead of coding it as:
you can write it as:
That would eliminate the MergeChroma function. But it won't be the same operation, you won't get the same results, and you won't save any noticeable time. You can make a script that opens an AVI and has only the statement "MergeChroma(MCTemporalDenoise(settings="Very High")), and a second script that opens the same AVI but has only the statement MCTemporalDenoise(settings="Very High") to see how long each takes for each, but it would be a waste of effort.

MergeChroma() is s function that requires two parts inside the parentheses. The statement MergeChroma(MCTemporalDenoise(settings="Very High")) is the same thing as writing "MergeChroma(Last, MCTemporalDenoise(settings="Very High")). "Last" is the first input component required and is understood to be there if only one input component is stated. The second source of input is "(MCTemporalDenoise(settings="Very High"))". You can substitute something else as Last, such as creating a video called "lum", or a video called "input1", or a video called "Whatever". But the MergeChroma function still requires two input components inside the parentheses. You can't separate the internal operations or requirements of a filter across two different scripts.

Right, but what I ended up doing was:

Run the first half of the script, output as Studio1.avi.

Run MCTemporalDenoise on Studio1.avi, output as StudioMCTD.avi.

Run a script loading Studio1 and StudioMCTD, and running MergeChroma.

Which seems like it should be the same, and doesn't result in five-minute waits when I try to open scripts in VDub. Mind you, still couldn't get up over 5fps.

That would make sense if you ran only QTGMC in Script 1, and only MCTD in Script2. Any chroma noise filtered by QTGMC or other filters in Script1 would be merged back into the later script that uses MergeChroma, so your MCTD script would have to run MCTD and then any of the other chroma fixers such as FixChromaBleeding and ChromaShift, etc. , or run MCTD in Script 2, and then run the other chroma fixers and stabmod in the third script. So keep in mind what each of those filters is doing and what you would be replacing. what would you do about the fact that the output of the QTGMC script is deinterelaced, but the output from the MCTD script is interlaced? Or did you eliminate QTGMC but just use SeparateFields() in both scripts? At what point are you running stabmod to fix the frame instability in that clip (you would have to run stabmod as one of the last steps)?

I know that every Vista PC I've seen seems slower than any other PC, but running scripts 5X slower than an i5 PC seems strange. Do you have features like Aero, screen widgets, WindowsDefender, screen saver, etc., running inn the background? Hopefully you didn't download extras like the free Mcafee scanner that comes with FlashPlayer or Google updates, which are like a virus in themselves. If you have multiple RAM sticks, maybe one of them has a problem ? ? ?

I came up with some scripts that allow that, but the overall time spent on doing it this way hardly seems justified. For one thing, the results don't look quite as clean. For another, there are glitches such as the way ChromaShift and MCTD works with separate fields instead of deinterlaced frames. It's not very different from using two scripts as earlier, with slow QTGMC in one script and slow MCTD in the next step.

Here are three tested suggested scripts, named "Scropt1_Q, Script2_MCTD, and SCript3.

Script1_Q:
Script2_MCTD:
Sript3 will usually give SSE errors in VirtualDub from stabmod, but the script works anyway and output is correct.

Script3:

I'm running MCTD on the result of the first script, not the capture.

I wish I'd upgraded to 7. Unfortunately, Microsoft gave no advance warning that 8 was going to be garbage.

I have Aero - and can't function without it - but none of the others.

I have four sticks of RAM at 4GB each. No idea what Google updates is/are.

I also got a BSOD while running MeGUI a couple of days ago, saying a clock interrupt was not received on a secondary processor within the allocated time interval. No idea if it's related, or what it is - a quick Google search seems to indicate it's an issue with improperly installed hardware, but I haven't made any hardware changes in years.

If all 4 RAM sticks are 4GB and alike, try 2 sticks and switch them out stick by stick. You can run Vista with 8GB of RAM for almost anything. I've encountered RAM defects many times over the years. There is free software out there that tests for this sort of thing but you have to be a programmer to read the results and running them is more trouble than it's worth.

I guess we have a syntax problem. Your earlier posts stated that you want to run the first part of the script "on Studio.avi" and then run MCTD on "Studio.avi", which to me meant running two scripts on the same input. Splitting the process into two parts was suggested several posts ago. If you can do it with one sample clip, there's no reason why you can't do the same thing with others.

I'm disinclined to screw with the RAM, because the last time I had to remove any I had no end of issues trying to get it back in. It's in an awfully difficult spot to get to. Plus that requires rebooting a bunch of times, and that by itself takes 15 minutes.

Didn't the AVSMeter thing show it was running much faster than VDub? So is there something about VDub specifically that could be the issue here?

The AVSmeter tets don't run with VirtualDub. They were run in a DOS prompt using a .bat file. Virtualdub had nothing to do with the AVSmeter tests.

I should add that on my PC, running the same Script1 in AVSmeter and as an analysis pass in VirtualDub, Virtualdub runs the script at an average frame rate of 18.4 fps in 18 seconds, which is a few frames per sec faster and almost 1.5 sec faster than AVSmeter runs it. Of course, Virtualdub isn't taking time to output any text files with numbers.

Unusually long and laborious bootup times indicate hardware problems. I just timed my XP's i5 cold bootup from no power to the time when the last two icons appear in the taskbar (Intenet and antivirus loaded) at about 95 seconds, and a total 110 seconds before the cooling fan controller kicks in and Kaspersky gives me the "You Are Protected" message. It can vary about 10 seconds each way.

From clicking 'shut down' to the screen going dead can be a ten-minute wait for me.

Not sure what your first post is saying. I got a significantly faster result with AVSMeter than when running the same script through VDub.

That definitely points to hardware problems.

The differences mentioned didn't seem very significant to me. Obviously if you add VDub filters to the Avisynth output it will affect the running time. Don't run scripts in VrtualDub if you feel that VDub slows it down. Just use AvsPmod.

What sort of hardware problems? I know very little about this sort of thing.

I ran a script through AVSMeter in 50 seconds at one point, and it took 94 in VDub. No VDub filters or anything.

But then, you ran it in less than 20. So...

Sorry for the delay, I'm running a capture.
That kind of slowdown would make me expect either a virus or a bad memory stick. If it's RAM, the only way to find out is to remove one bank of RAM (2 sticks, in your PC) and see how the other two perform at 8GB. Vista can easily work with 8GB of RAM. If your machine is still slow, it could be one of those 2 installed chips. If Vista runs well with those two installed chips, one of the other two could be defective. None of the RAM in any of my PC's is easy to reach, I have to remove a hard drive for one of them, no room. But you shouldn't have to tolerate a PC that runs as slowly as yours. Something is amiss somewhere.

Delightful.

I ran the first script for the sideline camera, which obviously has to run on the entire two-hour video. Initial estimate was one day ten hours, just under 5fps.

It then extended out to over three days, at 2.61fps.

It's now out over five days, and still climbing, but still at 2.61fps.

So obviously it's a problem that gets progressively worse; I had that restoration earlier that just kept increasing in estimated to total time. But I don't understand how it can be the same frame rate while taking two days longer to complete.

Yes, a hardware problem causes countless difficulties, and no surprise that a long process encounters trouble as it moves along. I usually run restoration scripts on small batches of material, but your PC is having problems even with small samples. I don't think anything will get easier by simply repeating the process. You should first try to find out why your PC is having difficulty at this level. It's not not normal behavior, even for a "slow" or older machine.

The RAM is actually significantly newer than the rest of it. I bought it with 8GB, then upgraded to 16GB a few years later. All completely new, so it's not a mix of new and old RAM.

Up over six days estimated total time now, and still at 2.61fps. I don't understand how that works. Surely the frame rate should be dropping as the estimated total time rises?

(I'm not counting this as wasting my time, because I can still do other things with the computer while this renders and I don't have time to go through rebooting and testing with various RAM combos right now.)

When you bought the RAM doesn't matter. Any component can develop problems over time. Whether it's RAM that's gone bad or something else, you need someone who can take a look into that PC.

Avisynth scripts run one step and one phase at a time, not all at once. VirtualDub filters work the same way. An early phase might go faster, a later phase or step can go slower. If you have hardware problems like bad RAM doing a lot of memory swapping, processing rate and running time will change over time and get slower.

You didn't mention exactly which "first script" you're running, but in this case it doesn't really matter. Your PC runs everything slowly, according to earlier tests. You're also assuming that every segment of that 2-hour video requires exactly the same filters and settings. With VHS, that's seldom the case. VHS doesn't work that way. I worked on a batch of old tapes from the early 1990's capped off tapes from analog cable, and almost every shot in those 1-hoiur videos required a different approach. not to mention cutting out stuff like commercials and other material that wasn't desired and then processing the pieces separately. Those 1 hour tapes were cut down to 41 minutes or so and each took a week to process before rejoining and encoding the pieces. On top of that those programs were telecined, which was an extra step. Everyone works that way, especially with VHS. You're wasting time over segments you might not even use, and segments that might need more or less work. You can proceed along any schedule you wish, of course, but I should think you're making the work tougher than it should be, even with a slow machine that has problems.