Well it's not the normal effects of interlacing.. although the effects may
be manifesting within a field. But this looks more like large bands (at
least 30 scanlines high) that are lagging. It's almost similar to when
you scan ahead on a DV camera (at least mine) it shows distinct bands
or long rectangular chunks that are of a frame not matching the other
parts on the screen.

what was the source material used to create these problem DV files? Was that DV as well?

I am still having problems with this 'horizontal shimmying' I spoke of a while ago..

Basically I took a lot of 3/4" U-Matic footage and captured it through firewire by looping it through my camcorder - so it is coming in as a DV stream. I then used Vegas to edit it down to multiple vignettes between 30 seconds and 10 minutes in length, origially intended for RealMedia on the web. The problem was not really noticeable in these RealMedia files, I surmise because they are low-res and progressive scan. I then rendered the same projects to DV AVIs to print onto DV tape for a hi-res archive of the final projects. It was then that I noticed this 'shimmying'.

I know it was suggested that this was the natural effects of NTSC interlace, but I should stress that this is not the case for two reasons 1) the effect is not there when I preview the original source clips through my DV camera looped to an NTSC monitor, using VideoCapture 2) I know what the standard comb-effect of two fields during high-motion look like..

So this is getting introduced during render in VV. It's not really prominent when viewed on an SVGA monitor.. It's when I watch it on a true interlaced NTSC video monitor that it becomes completely noticeable. If I frame by frame it on the SVGA, in retrospect I can see the places where there are 'echoes' of the subject matter from a few fields or frames before.. and when comparing with the source, there are no such 'echoes'.

I have tried playing with Resample and Interlaced Filter switches to no avail - and I should note that none of the events are slowed down or sped up. The properties for the whole project are set to NTSC DV, so it should be the same size and framerate as the original source DV footage. In the advanced settings, I have Motiion Blur turned off; I switched the Deinterlace method to none and tried rerendering.. but to no avail. I wouldn't think this would matter anyway, as nothing is really getting deinterlaced in this case in my understanding.

I had originally created and rendered the projects in VV2.0 and re-rendered them in 3, with no difference. I have tried previewing them to DV with VidCap 2.0, 2.5 and 3.0 - although at this point I believe that is moot anyway because I am pretty certain it is an effect hard-rendered into the actual output file.

My one theory left.. which I will try after this post.. is that it has to do with the 'Quantize Frames' feature brought up in one of my other posts. Since these projects were created in VV2.0, before this feature was implimented, I am noticing that when I load the project into VV3, zoom down to the frame level, if I slide an event right and left it does snap to the frame quantization, but I can see from the thumbnails along the event that the frames in the event are off-sync with the workspace's frame quantization.. (were you able to follow that run-on??) I am thinking maybe I should shut off Frame Quantization, slide it freely so they match up, then re-render. The idea behind my theory is that the program will, in this type of situation, sample its frames for render where the frame quantization grid marks are - and in this case that lies between two frames in the source, so it renders a crossfaded composite of the two adjacent frames? I will try it and report back.

In the meantime.. since this problem is very difficult to describe in words.. if some really nice person with a fast connection (maybe someone at SF?) is so inclined to take a look at the clips in question, I have made them available through the 'Get Files' feature of AOL Instant Messenger. My username is 'fongaboo'. Please forgive the bizarre footage. The clips of my buddies having too much fun with a chroma key just happened to have both the hard contrast and motion to really accentuate the problem. TONGUE.AVI is the source footage, which has no problem when viewed on the NTSC monitor. TONGUETEST01.AVI was rendered in VV and the part where the guy in the red poncho walks across the screen is a glaring example of the problem. Again I should stress that the clips need to be watched through DV preview at a full-frame rate on an NTSC monitor for the effect to be noticeable.

I apologize that TONGUETEST01.AVI is so large (300+meg) but to pare it down would mean to re-render and therefore introduce the problem into the file. I am not sure how functional incomplete fragments of DV AVIs are, but if you know them to work then I would suggest only downloading the first 40meg or so to get the point.

Thanks in advance..

Follow-up:

My theory is pointing closer towards the frame quantization issue.. the frames in the events are offset from the 'frames' of the project workspace. So far I was able to start a new project, import the source file (tongue.avi) and snap it right at the very beginning of the project, render the first few seconds, output it to
DVpreview->NTSC as I described, and it looks fine. But my attempt to open the original project and remedy things by carefully sliding events have failed.

So at this point, if by any chance anyone is indulging me by looking at the files, download only tonguetest01.avi and tonguetest03.avi ("only" about 40meg a piece), compare the two on a DV->NTSC preview and you will see the difference.

I also included a JPEG cap of the Vegas screen, pointing out my theory about the quantization offset.

So at this point is there any way to get Vegas to snap event frames properly to project/quantize frames? Or better yet, tell it not to try to composite two adjacent frames when it is sampling at a point in between two event frames?

Did this footage pass through a TBC on its way to the DV camera? Both playback and record decks genlocked? Seems like there could be a problem in the transfer method, but there may not be too much you can do about it.

Your best bet is probably to bring the DV transfer footage into Vegas 3, (keep quantize on), and render as DV from there.

Side note: I've worked with 3/4 source material for over 20 years- there's ALWAYS some kind of headache with that format.