The cause of the wierd frame overlap problem...

StormMarc wrote on 11/16/2003, 8:38 PM

I know people have talked about this before. It's when two clips butted up against each other get overlapped on a sub frame level and create a flicker of the two clips at the edit point. Easily fixed by pulling the offending clip back into proper place.

I just noticed that some clips that were fine got the problem after I did a ripple edit. So perhaps it's related to the ripple tool. I'll pass it on to Sony. I do have quantize to frames checked.

Marc

Back to post

Comments

RichR wrote on 11/19/2003, 7:54 AM

I capture in Vegas and I just had this problem yesterday. To add to the confusion, this is what I got...
I hope I can explain this.
I have clip A and clip B butted together. I got the "half frames" glitch.
One half frame (field right?) was from the end of clip "A" and the other was from the END of clip "B". The last field from clip "B" was brought to the beginning of clip "B" at the edit. I'm not at that machine now but It makes me think that the audio is longer than the video and Vegas is "stretching" the video to meet it. But that doesn't explain the "gap" issue does it?

filmy wrote on 11/19/2003, 8:18 AM

Current project I am using material captured with VV 4.0d and get the gap issue so it isn't somehting that only happens with other source material. yes it does happen with dragging material over and placing it "in order" on the timeline - this was the easiest way to try and reproduce the "bug" - but I get it from doing "insert" edits as well. It does have some to do with the ripple in this case because, and I have tried to explain this in more detail in other threads, I can insert a piece of media and it will insert fine but than a few edits down there will be a gap where there wasn't one before. Why this happens I do not know - has the Sony team been able to repro any of this? Dunno.

Oh - I am NTSC. And I agree it would be interesting to see if anyone in PAL land had ever had this issue. If not that the problem does become an VV NTSC issue.

rmack350 wrote on 11/19/2003, 6:44 PM

I was guessing that if you are quantizing to frames and the audio doesn't end on a frame then it might be rounded to the nearest.

Vegas does a quick-fade to zero on audio streams. If the media file were to be truncated to the nearest video frame then an overlong audio stream might just get clipped off. Then you'd hear a little noise at the cuts. I suppose Vegas should just handle it though.

So what I'm saying is that the snap point is rounded to the nearest frame, presumably based on the audio samples. But we're talking about the same thing, anyway.

Rob

rmack350 wrote on 11/19/2003, 6:47 PM

Nah, that's not it. You're just missing out on all the fun, BB.

Rob Mack

rmack350 wrote on 11/19/2003, 6:48 PM

Nope. Occurs with footage captured by the Veags vidcap utility.

Rob Mack

rmack350 wrote on 11/19/2003, 6:59 PM

Yeah, I'd say James' hypothesis about external progams or any guesses about 4.0c vs 4.0d just don't pan out. And James doesn't really have enough data to call the idea a theory.

So, we know that this does happen under any of these circumstances:

--4.0d, 4.0c, maybe earlier revs
--NTSC projects
--Footage captured using Vegas' vidcap tool
--When footage is dropped on the timeline
--When footage is rippled due to other footage being dropped on the timeline

Evidently this has not yet happened in PAL projects and we can assume for now that this is a factor (Until we hear otherwise. "No evidence" doesn't really count as evidence)

So, the questions:

-Does this reliably happen with certain media clips?
-Is there a difference between dragging a clip onto a video track vs an audio track?
-Is there a difference if the audio stream is grabbed to move rather than the video stream?
-Is there a difference if you ch-ange the ruler settings?
-Can the problem be fixed by "Ignoring" event grouping and then dragging the audio in or out to the last video frame?
-Is there a hardware component to this? Is it only on DVCAM or a certain make or model of camera or deck? (mine is captured using a DSR11 deck, fwiw)

Rob Mack

Johannes_H wrote on 11/20/2003, 1:28 AM

Hi,
just found this interesting thread and maybe I can add something to it.

I started with Vegas (VV3) back in July 2002 and with my first projects I also ran into the same problem and reported it here on this forum.

At that time after intensive research I found how to reproduce it. But this was VV3 and currently I have no access to my VV4 (4.0d) to check if it is still the same with VV4. I will do this ASAP.
I use PAL - so it maybe also happen with PAL projects. With my first projects I did not change any of the defaults of VV. So when I started a new project VV came up with its NTSC project preset. First task then was to change the project setting to use the PAL DV preset. When starting a project exactly this way I always could see the problem with the small gaps and the clips ending between frame boundaries.

Next step was that I once made the PAL DV preset the new default for all new projects. After this, when starting a new project the "gap" problem did not come up any more. So the conclusion at this time was that there must be a difference between the situation when starting VV with the default NTSC project preset and then switching to PAL preset versus the situation when directly starting VV with the PAL project preset.

Does that finding make any sense for someone?
Could I describe it in an understandable manner (my language is german)?

All I described here is already in the following thread:
http://mediasoftware.sonypictures.com/forums/ShowMessage.asp?MessageID=115566&Page=0

Regards
Johannes