Field Reversing woes

[phozz]

Hi,

I'm in the process of converting old VHS tapes to DVDs. I am experimenting with two methods and having similar results with both:

1. VHS > GrabBee X+ USB2 converter > VirtualDub encoding using ffdshow's DV.
2. VHS > miniDV cam > Vegas capture.

From either method I end up with a DV AVI file, which I edit using Vegas (usually just cutting bits and syncing audio, nothing too fancy), render using MainConcept (within Vegas) and finally author using IFOEdit.

Anyway, my problem is that occasionally the result DVD has its field order reversed, so all motion is badly jerky. This can happen completely randomly, with no correlation to capture or encode settings (yes, there is a field order setting in the encoder, it's always set to bottom field first and that works 90% of the time). What I usually do in such a case is go back to the encoded mp2v file and use the PullDown utility to set tff to odd (without reencoding), reauthor and reburn, and the result is usually fine.

My problem is that I've just made a DVD that switches from good to bad in the middle. Changing the mp2v file's properties cannot, therefore, fix this - it only reverses the situation (good parts become bad). I have no other idea what to do and I'm getting kind of tired burning coasters. :(

So, here are my questions:

1. This issue is only noticeable when watching the final burned DVD on a standalone unit connected to a television. Is it possible to detect it earlier in the process, on the PC? I've tried watching the rendered DVD folder using VLC, Media Player Classic and other players, and it looks just fine even though it's bad. (Unfortunately, my standalone DVD won't read rewritables.)

2. My current theory is that this issue is caused by the way the old VHS tape was recorded, and not by the way I'm capturing it. Can anyone here explain why this happens?

3. Finally, suppose I find that only part of my program is reversed, how would I go about fixing it?

Thanks,

phozz

[phozz]

Well, as it turns out that I solved the problem on my own. Since the sources to PullDown are available, I simply replaced the GetTFF() function with the following:

int GetTFF (int pulldownPattern)
{
if (currentFrame < 46399)
return 1;
else
return 0;
}

This changed everything up to frame 46399 to odd TFF, while leaving the rest of the video (which was fine) as it was.

I still don't have a full solution for burning coasters (I have managed to burn parts of the rendered DVD as an SVCD on a CD-RW, which is usually sufficient for locating this problem), but at least there's a solution to my main problem.

[drcl]

only thing i can think of is that your capture device is throwing a wobbly because of vhs stability and adding or losing a field somewhere in the capture.

[Mug Funky]

DVD-RW baby :) huge timesaver. the loading time can be a little longer in some DVD players (and no doubt some don't support it at all, like my old toshiba), but if it works on your player all's well.

[phozz]

This is getting a bit off topic, but DVD-RW is problematic because (A) it needs to be recognized by my burner, (B) it needs to be recognized by my player, and (C) it should be available for purhase individually rather than a 3-pack or 10-pack. Actually it seems that the latter is the hardest problem - these discs are expensive and I only want one - and I can't find any singles.

I also wish these things would burn faster, but hey, can't have everything.

[Mug Funky]

hehe, fair enough.

i found the 3-pack handy, but that's because i live in a share house and discs go missing aaaall the time. i have to rip and backup everything i own, especially CDs, because it'll either get lost, destroyed or put in one of hundreds of different cases (like finding a piece of hay in a gigantic stack of needles).

as far as burning speed, try short samples and "high compatibility borders" turned off (that will burn a minimum of 1 gig no matter how big the disc is).

then pray your DVD player can manage it.

on the cost - if you burn it 1000 times it comes out a lot cheaper than 1000 50c coasters. much better for the environment too (we gotta do what we can...).

[phozz]

I use a little utility called Topsplit to copy the first 5% off each VOB file into a small file (about 50 megs). I then burn them as a non-compliant SVCD on a CD-RW. The player does play it. It gives me a good enough preview of whether I got the fields reversed.

(The bitrate is too fast to read off the disc so motion is not completely smooth, but still it's good enough to tell if I got the field order right.)

It's a bit of a tedious hack, but I get a quick preview without burning a write-once disc. The environment stays happy too ;)

-phozz

[bb]

You can verify the field order on a progressive display (pc monitor) using AviSynth:
AviSource("your_film.avi")
AssumeTFF().SeparateFields()
Open the script in VirtualDub, and step forward. If you get smooth motion, then the video is tff. If it jumps back and forth, then it is bff. You may change the AssumeTFF into AssumeBFF to check the other way round.

If your video is from a progressive source (such as Hollywood films), then you may use Telecide() to correct the field order automatically. This does not work for interlaced sources, though - in that case you can either fix it manually, or you can deinterlace the video (which is a good compromise, if you don't want to spend too much time).

So, if your video is progressive, the following script should do the trick (no more searching manually for field order changes):
LoadPlugin("decomb.dll")
AVISource("your_film.avi")
AssumeTFF()
Telecide()

bb