VirtualDub capture log

[ajp_anton]

Trying to digitalize some old VHS tapes, and I'm recording them multiple times so they can repair each other's dropped frames and then average away some noise.

Can VirtualDub output some sort of list of dropped/inserted frames, so that I can more easily find those later to fix them?

[ChiDragon]

As far as I recall, no. Virtual VCR can create a list of dropped frames (confusingly, two lists actually) but the newest version is almost 9 years old.

[jmac698]

Wouldn't trust virtualdub, I've seen dropped/duped frame patterns with no indication of dropped frames.
The problem is there's two kinds of dropped frames;
the kind vdub reports is if it couldn't save the frame to disk quickly enough, this is going to be pretty rare on a modern system.
The next kind is when the timing of the input is different than expected; the hardware updates the frame as it comes in, but the framebuffer is sampled at a regular interval (as far as I understand), thus if the frame is late, the capture will read out the current, but old buffer; this means a dupped frame. This could be followed by a dropped frame later.
What we need is some kind of interrupt to read each frame, it has to be saved with the timing info, at the end we should resample the audio smoothly according to the timing, and force the video frames to exactly 29.97 fps.
I asked Avery about this and he said something that the Windows interface requires you to set the framerate before starting capture, so there's no easy workaround to this.

Using the average real framerate to reset the capture rate will bring fewer dropped frames, but they are still possible.

But yes you should be able to use the timing capture log to detect this somehow, it may not be simple though because you have to account for how vdub adjusts it's timing? Use my glitch analyzer to find the real dropped frames and compare to the timing log to see if there's an obvious correlation.

[ajp_anton]

Yes I found the timing log and it seems to give an even better output than a simple dropped/inserted list. I also set VDub to not drop or insert any frames, so the timing list should correspond exactly to every frame that was actually captured. From this I should be able to build an Avisynth script that fixes the stream accurately enough. Hey, it's VHS, some errors are to be expected =). As long as all the clips I average are synced for the vast majority of the time, it will be fine.
I've been busy with school and will be for a while still, but when I have time I'll see how well this all works...

[Asmodian]

This is very interesting. I am currently taking the median of five VHS captures but I have been manually aligning the video. I also don't let VirtualDub drop or insert frames.

I suggest doing a median instead of an average as it is much sharper and any defects that are only in one capture should be automatically dropped. You can multiply artifacts by number of captures (but faided by 1/#ofcaptures) with averaging.

I would love to know if you work out a good method to help automate this ajp_anton (or even just a good method).

I usually only see one or two dropped or duped frames per capture but it can still take a while to align all five captures.
My current method:

a=SeparateFields(cap1)
b=SeparateFields(cap2)
Interleave(subtitle(a,”1”),subtitle(b,”2”))
#Median_yuv2(a,b,c,d,e)

[ajp_anton]

Well I was planning on just dropping the min and max values and take the average of the rest, so some kind of mix between mean and median =).

I'm super busy at school right now, don't know when I'll have time to look at the 8 copies that I have already recorded on my computer...
What I know is that the dropped frame number for a 3h tape is in the hundreds. Nothing I want to go through manually for multiple copies.

[jmac698]

This is a big problem, I've been working on a way to match frames. My particular tape is so noisy, however, you can't reliably match frames except when they change dramatically. So I can use heuristics and look for patterns in the dropped frames, to guess or at least list out questionable sections to be aligned by hand. Probably will need two passes.

[NTCT]

I'm also a fan of averaging multiple captures. And yes, there is no realistic way to avoid manual alignment of the captures as of right now. What I want to point out is that VirtualDub actually does everything properly on its side. And VirtualDub is not the only source of frame drops/duplicates in the entire setup. VirtualDub does exactly what you tell it to do: capture frames at a certain rate, which is based on the clock rate of your PC. The trouble is that your VCR, TBC and PC all have slightly different clock rates. If the TBC doesn't get a new frame in time from your VCR, it will duplicate the frame. Or it will drop one if the frames come too close to each other. The main trouble is not VirtualDub itself. The main trouble is that you're trying to capture the data stream at a fixed frame rate. And your data stream, unfortunately, doesn't really come at a fixed frame rate. So, yes, it is best to use the average framerate of the actual video stream in the capture settings of VirtualDub. And still, this doesn't guarantee perfect frame accuracy, unfortunately.

[jmac698]

Right, I agree. However I did mention this problem to Avery, he wasn't too interested in fixiing it. We should capture a frame when it's ready, and artificially give it an accurate timestamp, meanwhile dynamically resampling the audio portion to match. He said there was a problem in how windows handles the frame rate.
the same problems also exist on Mac. Our only hope is Linux, where you can fix this even at the driver level. Certain some of the chips must support variable framerate?

[NTCT]

Well, I don't even know whether there is any way to avoid this, and whether Avery can do anything about it. The fixed framerate requirement is a part of many device interface specifications, and it is the operating system that chops the incoming crude data stream into frames. And it does so at regular intervals. I noticed that the output framerate of my TBC isn't exactly 25fps (PAL) according to my PC, but is ~24.995 fps. I don't know where exactly the discrepancy comes from, neither TBC nor PC clocks are perfect. I can adjust the capture framerate on the PC to minimize the number of dropped/doubled frames, but these glitches cannot be entirely avoided. It seems to me that the residual number of dropped/inserted frames is due to TBC itself. The TBC must meet the framerate requirement, and if it doesn't have a new frame on time, it will duplicate the previous frame. Or it could drop one just as easily.

[jmac698]

I would agree that the problem is devices trying to create a steady 25fps framerate. If they supported variable frame rates there wouldn't be this problem.
I calculated the difference in two quartz crystals would account for up to 25.001 fps.