I've had another wierd one happne last night.

Captured about 20 mins of DV and tried to copy video from track two to track 1 to use as a mask. I cannot get the two events to line up with Quatize to Frames turned on. I would seem as though the two events start at different fields and as I don't have a Quantize to Fields option I cannot line them up. But it kind of begs the question of how did things get into this state in the first place.

No doubt with the original event I could have turned off QTF and gotten it out of alignment except with it turned on I cannot align the frames in the event to the frame boundaries. Apart from this the whole thing looks fine and the mask thing wasn't going to work anyway BUT....

I have all the snapping turned on.

I've looked at the problem in more detail, and it is a rounding problem after all. I found an old message from Sony that said the internal precision is kept at 100 nsec resolution. However, many calculations in scripts (in Sony code as well ??) aren't kept in this precision. I am able to work around the problem.

John,

Actually, my suggestion was to turn OFF "snap to grid" and "snap to markers," not to turn them on.

Here's what I found was happening to me: I would drop something on the timeline and assume it was snapping to the edge of the media file, when in fact it was snapping to the grid. This is especially difficult to see right away if you have the grid set to something smaller than a second, and you're working with a zoomed-out timeline.

By turning "snap to grid" and "snap to markers" OFF, the events snap ONLY to the event edges, and I find it much easier to drag 'n' drop clips on the timeline.

Of course, if you're working with scripts, none of this may really apply. But, it worked for me.

By turning "snap to grid" and "snap to markers" OFF, the events snap ONLY to the event edges ...

Great idea. I will do this. I determined that the problem has to do with the way Vegas rounds numbers internally. I suspect that this rounding is responsible for all sorts of little problems and glitches that have been reported here over the past year, especially with slight gaps and overlaps between events; some events' refusal to let you create a fade in/out until you shorten the event by one frame; and many more.

I put a rounding algorithm into my script and got it to work. I can now spot all those annoying gaps and overlaps (found two just this morning).

JM - I aint no programmer, that's a given . . but . . . Do you think Vegas coming from an audio background, where time sigs and so on are very important, these tiny adjustments "roundings" can be related back to that? Only a thought . . . .

Grazie

>>>Do you think Vegas coming from an audio background, where time sigs and so on are very important, these tiny adjustments "roundings" can be related back to that?<<<

THat was my thought when were talking about the black frame/gap issues. I got to thinking that maybe the fact that Vegas was also acting as a DAW there wasn't any way to prevent going past the frame level and that might be creating some of the issues. In theory this sounds very logical to me because you need to have that ability to work with audio. With video you don't really need to go past a frame - so putting both on a timeline and giving priority to the audio over the video could create all these little gaps, overlaps and extended edges I think.

One other thing to consider numerically if you're working with drop-frame timecode is that not every frame number actually exists. Some frame numbers are dropped to keep 29.97 NTSC video rate aligned with real time.

I'm sure you're all correct about the source of the problem having something to do with having a variety of different timcodes (audio, video, drop frame, 29.97 (etc) vs. 30) to reconcile. Sony's solution is to use incredible internal precision (100 nanosecond, apparently). This is great, but it doesn't solve the problem of having the program do the right thing when the program must make a decision as to what to do with two events that are supposed to line up at a boundary. If they are off by even an imperceptable amount, the program may make the wrong decision. I have found, using scripts, that when the end of one event and the beginning of the next event are "snapped" to each other, the timecode for the end of the previous event usually matches precisely with the beginning of the next event. However, once very 20-30 events, the two times are off by as much as 20-30 microseconds. This small time difference makes absolutely no difference when watching the movie, but I could see how it might account for various reports in this forum over the past year of people having problems with one frame blank gaps showing up between events that appear to be joined; problems not being able to activate the fader control on the audio or video of one or both abutted events; and many more little glitches.

<snip>

This post originally was an accidental duplicate of my previous post. I've deleted this duplicate to avoid confusion.

....er . . John was your Double post an example of what is happenning - "Snap to Post" - very ironic! - sorry Pals couldn't resist - G . . .I'll go away now . . .

Not sure how that happened. I just went back and deleted the content of the second post, and left a message there explaining what happened. Why it happened, I don't know. Cockpit error, I guess.