No, I haven't rendered, but you can see the black frame flash when playing in the preview window. When I get home at night I will render and see if it's there too.

Sounds like dropped frames... did you make note of any dropped frames in the capture? I have my Vegas set to stop capturing on dropped frames in the capture prefs.

If the files haven't been rendered yet, then Vegas likely isn't the culprit.

>>>Sounds like dropped frames...<<<
>>>If the files haven't been rendered yet, then Vegas likely isn't the culprit.<<<

This is the exact same behaviour that has been around for a long while. Dropped frames might have some issue however in my case dropped frames were not the issue. Matter of fact in Version 4 when I had a black frame issue doing this same thing the question was asked "Exact steps on how to repro?" and my comment was to simply drop media onto the timeline...ironic that what cacher just described doing in Vegas 6 (...dragged all of the clips to the timeline.) is exactly how I said to repro the black frames/gaps in Vegas 4. As I highly doubt cacher and I are using the exact same media, the exact same media computer and clearly not using the same version of Vegas I suspect this has *everything* to do with the Vegas engine.

I can see this heading down the same path as before - Sony team unable to repro therefore the issue does not really exist. Loyalists who have never had the problem will say it is not the fault of Vegas but the fault of the users who have this issue.

Now this black frame/gap is *not* the same as the "flash frame" issue - anyone found it in Vegas 6 yet? And Spot - many of us are still waiting on your answer to the flash frame issue that turned up in one of the Vasst DVD's when Vegas 5 came out. http://mediasoftware.sonypictures.com/forums/ShowMessage.asp?MessageID=291670&Page=0 from June 2004) Thus far your only comment since June 15, 2004 was, in part, this: It was reported to me after the VASST tour had started, so I'll be having to wait til the tour is off after Toronto to look. (I'm sure it's there if two people have reported it, but this will be the first I've seen of it).

I haven't seen a flash frame in 6 yet...but then I haven't seen ANY in over a year since I changed my workflow....save and close the veg file...re-open and render.

Golly, I had hoped they would have fixed this. Here is my long, recent post on what appears to be the same subject:

Black frames on timeline

I provided Sony with a repeatable demonstration of this problem via a VEG project and associated media files, last fall. It makes me VERY discouraged to have my time wasted like this, especially when the problem is so universal (MANY people have reported this), the result so completely unprofessional, and the problem seemingly so impossible to predict in advance and therefore avoid.

Nice thread John! I missed all of that for family reasons. But I think it does at least bring up an issue not fully brought up before - Vegas and mixing media on the timeline.

Sort of like the EDL discussion where SoFo/Sony has used the term "EDL" in it's marketing but not fully disclosed what they define by the term verses how the industry defines it. Now we have all seen the words "mixed media", "not format dependant" and/or "mix file types" in the marketing of Vegas - yet it was never mentioned before this thread as a possible source of causing blank frames/gaps to appear. It does make sense now that is was plaid out however.

Too bad in many (most) cases where I have found it it has nothing to do with mixed media on the timeline. The last feature I edited was all NTSC DV based footage...all shot and captured at the same frame rate on a matching timeline. I found at least 5 black frames/gaps after it was all finished and doing pre-final render checks - the worst was at the final mixing stage were in 2 locations - in the RENDER - one frame black frames were discovered. I went back to the actual edit and sure enough there were little one frame gaps at these cuts. Makes me look bad for turing over a "locked" version with flaws but also it really makes SoFo/Sony look bad for having a product that creates/leaves these one frame gaps in the first place. Even worse is that I was using Version 4 and now with Version 6 this same "bug" is in the code.

No, not a single dropped frame. And this issue is not the same as the flash frame one. These black frames come from video events not completely being flush with each other (the audio part being a tad longer than the video one). You can see if you zoom ALL the way in that the audio part is a very tiny bit longer than the corresponding video.

In the thread that John Meyer referenced, I opined that this had something to do with Vegas' snapping behavior. I think, at the time, that I had confused the "flash-frame" with the "black-frame" problem. I don't think snapping has anything to do with "flash-frame," but it very well might with "black-frame."

I'm not sure if I've experienced the "flash-frame" problem, but I have definitely experienced small gaps or black frames when dragging something on the timeline with "snap to grid" enabled. I have my grid set to seconds, and the gaps seem to appear when an event ends within a few frames of a grid-line. It's as if Vegas assumes I want to snap to the gridline, not the end of the event.

Try turning off all the "snap-to" options in (I think) the "Tools" "Options" menu. This means that Vegas will snap ONLY to event edges. Then, make sure "quantize to frames" is turned on. Do you still get black frames?

Too bad in many (most) cases where I have found it it has nothing to do with mixed media on the timeline.

I think what Sony meant was that the underlying structure of Vegas must accomodate all those different media types so that even when you are using just one type (e.g., NTSC DV), the inherent timeframe is generic, rather than specific to 29.976 NTSC, and therefore roundoff errors can accumulate, and problems can surface.

As to blank frame vs. flash frame, I too didn't quite pick up on that important distinction in that thread a month ago. However, I think cacher's problem is indeed the blank frame (where it happens on the timeline from events that seem to be touching, but somehow are not). I have even tried the "Quantize to Frame" script which is supposed to remove any errors from moving things around with "Quantize to Frame" turned off, but that doesn't help. Also, sometimes you can trim each event away from the point at which they touch, release the mouse, and then trim it back, and the problem will go away, but not always.

Thus, I don't think there is a reliable workaround. Sony must fix this one.

Flash frame / black frame / messed up frame... who cares. I'll I know is I've been having these problems since version 4 and it seems to be ripple related at least part of the time. The silence from Sony is making me seriously consider switching programs if they can't fix this issue. It must be something they are unable to fix without a complete rewrite so they say they've never seen it.

Marc

I can see this heading down the same path as before - Sony team unable to repro therefore the issue does not really exist. Loyalists who have never had the problem will say it is not the fault of Vegas but the fault of the users who have this issue.

Well...

I'm not trying to throw blame around, but in all the posts releated to this problem, people who have issues have messed with the default quantize and snapping settings. There's a lot of mixed advice on what's best -- quantize on, snapping off.... or quantize on, snapping on but snapping to grid off, or...

I've left them alone, and have only seen black frame issues rendering 29.97 DV out to 30fps progressive MPEG2. I have repro'd that issue, too.

Any chance launching Vegas with the defults whipes out the problem?

- jim

Jim,
The default settings were recommended in versions 2,3, and 4 and that's what most people used. There don't seem to be any predictable settings that would or would not generate these anomalies. I personally have dealt with flash frames more than black frames, but I have seen both regardless of settings.

John

In my case I can't see ripple have anything to do with it. My settings are quantize to frames ON, snap not enabled (except to other events). Fresh captured clips thrown to the timeline will show blank/black frames among some of them (about 1 in every 10), there's no editing involved yet.
Yesterday I was trying to do some event triming when I noticed that a couple of events had the opposite problem: the audio part was a tiny bit shorter than the video, so instead of black frames you get blank audio (sort of a clicking sound if you have ambience audio on both tracks). I agree that most of the time you would be trimming events, but I really think the quantizing logic should kick in from the very capture app:

l = lenght of captured clip;

if quantize_on {

   new_video_length = quantize( l );

   new_audio_length = new_video_length;

   apply_changes();

   save_clip();

}

Some changes to V6 worth knowing about:

1) "Flash frames" - Although we have never ever repro'd this in house and have tried many times to do so, quite a few users have over the years reported an ERRANT, INCORRECT frame of video magically showing up in the middle of a rendered file. This is something that apparently (we're told) did not re-occur if you rebooted and rendered again...or it might surface in a different place. After drilling way down on this during Vegas 6 development, we believe this issue is solved...no reports of it so far, fingers crossed. Just to be really clear, this is NOT a rogue edit on the timeline.

and we also hope we've cut down on the possibility of rogue edits via the next item...

2) Prior to Vegas 6, if you captured DV and threw a bunch of these clips on the timeline, the audio and video event ends of the a/v pair would not precisely match up, might be a few samples off. In Vegas 6, we "trust" the video length of an a/v pair and pad or trim the audio a few samples so that the a and v end-edges match. Edge snapping to either end of the a/v pair puts the cursor in the exact same spot now, less chance of parking on an audio event end and splitting off a tiny video sliver (which would be very hard to see unless you zoomed way in and were looking for it).

Some changes to V6 worth knowing about:

1) "Flash frames" - Although we have never ever repro'd this in house and have tried many times to do so, quite a few users have over the years reported an ERRANT, INCORRECT frame of video magically showing up in the middle of a rendered file. This is something that apparently (we're told) did not re-occur if you rebooted and rendered again...or it might surface in a different place. After drilling way down on this during Vegas 6 development, we believe this issue is solved...no reports of it so far, fingers crossed. Just to be really clear, this is NOT a rogue edit on the timeline.

and we also hope we've cut down on the possibility of rogue edits via the next item...

2) Prior to Vegas 6, if you captured DV and threw a bunch of these clips on the timeline, the audio and video event ends of the a/v pair would not precisely match up, might be a few samples off. In Vegas 6, we "trust" the video length of an a/v pair and pad or trim the audio a few samples so that the a and v end-edges match. Edge snapping to either end of the a/v pair puts the cursor in the exact same spot now, less chance of parking on an audio event end and splitting off a tiny video sliver (which would be very hard to see unless you zoomed way in and were looking for it).
==============
Thank you.

I have been one of the most critical of these two phenomenon surviving 4 generations of Vegas.
I wish you had posted sooner that you haven't forgotten this issue ,and that you were still working on it. It has restored some of my faith in your committment to our "long term" concerns.
Much appreciated response.
Thanks again.
John

"In Vegas 6, we "trust" the video length of an a/v pair and pad or trim the audio a few samples so that the a and v end-edges match."
I'm sorry to tell you this, but that's *NOT* happening in my V6 (build 99) trial installation, and is the whole issue of this thread.
I've already found a couple of clips with either shorter/longer video than audio and I've only captured about 25 min of video yet.

Cacher: I just tried this with build 99, the ends of a/v event pairs on captured clips are exactly aligned in Vegas 6, unlike previous versions where we did not pad or trim the audio to match the video stream. I have hundreds of captured clips in my timeline, of different lengths, all end-edges align.

What length of difference are you seeing between the a/v pair ends in V6 build 99?

Also: Are you capturing with our capture app?

SonyEPM: Yes, I captured the trouble clips with V6 VidCap. To be honest there's been a great deal less length discrepancies between a/v than before (I used to get a lot of those), but I still got about 3 or four clips with dif. a/v lengths in about 35 short clips captured.

It's hard to tell the length difference but a good guess would be about 10 pixels when zooming *ALL* the way in and the difs are either way (sometimes shorter audio, sometimes shorter video).

Perhaps there's some kind of threshold in the code? For example: if dif. is less than x samples, then do not pad?

Sony,

Thanks for the post. It's good to hear these problems have been addressed. If there is any residual, I hope cacher can give you what you need to drill down and root out the last vestiges of this.

cacher:

Threshold, yes but = 10 frames.

We'd love to repro this but so far cannot. Is anybody else seeing it?

Steps: Capture a bunch of DV clips in Vegas 6. Add to timeline. Zoom way in and check event edges. All video and audio edges should be vertically aligned, no tiny gaps between audio or video. No repro here.

Don't see it here -- however, I am noticing for the first time the lack of "blue triangles" issue cacher mentioned.

Just a note.

If you temporarily set the ruler to absolute frames then you can see if this phenomena exists by scanning through edit details. If things aren't a whole number of frames long it'll be obvious there.

The caveate would be that edit details only displays times out to something like three decimal places so I suppose it could be displaying a rounded off number.

You can also set the ruler to read in samples...

(Checking some clips captured in V5 I find one audio stream that is 927.001 frames long while the video stream is 927.000 frames. Looking at it in terms of samples, both are 1,364,053 samples long. So absolute frames is a better way to find these things.)

Rob Mack