I've had quantize to frame enabled since I'd installed version 3.0 over a year ago. This changed today, when I couldn't get two clips to connect to eachother. I'd moved Clip B up against Clip A, and a small gap persisted between the end frames. I've heard of people having this problem -- where Vegas leaves random gaps between clips, sometimes creating noticable blips between edits, but having never experienced personally I dismissed it as pilot error.

Today changed that -- and the only remedy I found (after scrolling all the way in and trying to move the clips together manually) was to disable quantize to frames. Now, clips butt up together seamlessly.

Now I have to wonder: have I made a bad decision? By attempting to remedy one (perceived) problem, have I created others? What's the scoop?

- jim

I have always had "quantize to frames" enabled. Perhaps I should try it without.

Marc

Is there any chance that today you are using clips with a different frame rate than the project settings? Perhaps your project is 29.97fps and you are using some 30fps or 24fps clips. If this was the case then the clip's endpoints won't exactly line up with the project's frame boundries.

The quantize to frame works EXCEPT it only works on the beginning of a clip. I will get odd sub frames at the ends of clips. If I drag the end, I can usually make it shorter and it locks to the grid, and then drag the next frame forward until it locks.

This leads me to believe that the captures are not true to frames, but will have bits and pieces on the ends of the files.

Dave T2

I've seen the overlapped frames or the blank (black) frames only when trying to butt up 2 clips in MPEG-2 format. This was regardles of the "Quantitize to Frames" setting. When I did it with the same clips converted to AVI DV Type 2 the clips butted up correctly, but I think that I lost a little quality in the conversion.

I see this happen quite frequently but since the vast majority of what I do is to cull stills from footage for web use this hasn't bothered me. But it should be bothering anyone trying to edit.

I'm assuming that the problem relates to the length of the audio in the AVI file. Vegas often reports the audio as being a different length than the video. What I'm guessing is that there's some sort of improper rounding causing this or that clips are being snaped to the edges of the audio streams (which are being rounded to the nearest frame)

Just a guess.

Rob Mack

Rob, that makes sense, and is the best possible explanation I have seen. But I don't think it is being rounded to the frame, I think it might be being rounded to the sample.

Dave T2

How about looking at the camera and 1394 bus? I have never had this problem (only work in PAL 25fps on a Dell 8200 laptop w. built in 1394). Never seen the audio thing either. I use a Sony PD-150P. Maybe some cameras don't respond correctly to data from the 1394 bus. Or maybe the data chokes somewhere internally when capturing thus producing the extra audio or video data. Do you all use the Vegas capture software?
Just throwing in some thoughts...
Best/Tommy

To clarify, this is using the Vegas capture, but it I use Windows ME, so Vegas captures to multiple files of 4gig. It is at the end of each file that I see the problem. When I drag the last scenes from a file to the timeline. Not when dragging an excerpted scene to the timeline.

Dave T2

I had a similar problem with Audio files.. every once in a while I would have a blip when I rendered a crossfade.. I upgraded to version d and it went away... in fact it was a bug they noted as fixing in version d... perhaps it's the audo causing your video to glitch?

All this seems to just go in circles. A llot of people have a lot of theorys and SoFo/Sony have twice aked for specifics but there has never been any sort of "We can duplicate it and are working on it" or "This is caused by..." after that. As I have said before if it was a probelm that was easy to reproduce, if it was only cuased by one thing or on only one type of system, it would have been resolved. It just seems like a lot of people get the same results by doing various things - the only real consistancey seems to be it happens on the VV timeline and there is a "gap" placed after an insesrt *and* you can only see the gap if you zoom all the way in on the timeline. (Or you notice a little black frame/blip fly by during playback) The audio issue seems to be another issue of the same kind. Some people get it, some don't. Are these two things related? Maybe. But I have only had the audio thing happen a few times where as the video gap I seem to get a lot and they don't happen together.

To quantze or to not quantize. To ripple or to not ripple. To "insert across time" or "insert as take" or to...well, you get the idea. I guess one could ask how other NLE's work in reguards to placing items on the timeline and why thet don't get these "gaps". My guess might be that Vegas can edit audio thusly there is a built in "acceptablity" for going past the single frame level. If you are editing there is no real way to turn off, say, "audio editing mode" to allow only frame level cuts at the picure level. The quantize option doesn't seem to matter in solving the overall issue as people get it either way.

We all live with this - but are we really getting anywhere? Or should is say is Sony getting any closer to fixing this?

Perhaps because there is NOTHING actually WRONG? I'm not talking about any obvious variance between the video and audio length or some odd problem with capture.Otherwise I've tried and can't duplicate the problem.

I certainly chop up the timeline and move events all over the place. If I end up with a gap, the reason and only reason so far I'ven seen is good old human error.

IT is only when you drag a video to the timeline the first time, that it happens. Once it is on the timeline, and is actually quantized, the error won't occur.

Dave T2

I'm speculating here, but I wonder if this has anything to do with the fact that Vegas uses the more accurate 29.97002997 frames per second and the rest of the NLE world uses 29.970? (30000/1001, which is correct, as opposed to 2997/100) The length of the footage from another program which uses 29.970 would be some fraction of a frame shorter in Vegas and wouldn't end up exactly on a frame boundry.

29.97 vs. 29.97002997 was discussed in this thread.

If you used nothing but footage generated by Vegas, then there would be no "gaps." If you use footage from other apps which was generated at 29.970 and Vegas interpreted as 29.97002997, I would guess that there could be little gaps here and there if "quantize to frames" was turned on.

James

I just live with it by trolling thru the entire project and correcting the small glitches by turning "quantize" off then turning it back on again. There are some cuts and mergings that never look right on playback to the eye and I usually have to cut some "slices" off one clip or another to get a smooth transfer from one clip to another.(no transistions applied). At times there is a one frame fragment jammed into there overlapping causing a flicker. Sometimes you see it on playback but not on render. This happens on Win2k and XP pro. I am confident that it will eventually be fixed and if it is I will probably rank the performance and stability equal to the old "Bell Labs" "Western Electric" standards of excellence.

JJK

All I can say is I too have this problem and it drives me in-freakin sane.

I wonder if the ruler format could cause a conflict between real time event video or audio length and timeline display? I use the SMPTE nondrop 29.97fps Video format and have never experienced any of these symptoms. DGrob

The test of this theory would be to see if anyone in PAL land is having the problem. I'm a PAL man and haven't seen the problem but that doesn't mean that much.

farss,

I'm not sure if you're talking about the theory I posted earlier, however, if you are, I believe that PAL is exactly 25 fps and Vegas deals with it as such. Therefore, those using PAL wouldn't be affected by this problem, no matter what program generated the footage.

If the theory is correct, then the problem should only manifest itself on NTSC footage that has been generated or processed with another program, like Premiere, After Effects or Virtual Dub.

I just generated two 900 frame files, one at 29.970 using After Effects and the other at 29.97002997 using Vegas. I pulled them into the timeline in Vegas, zoomed all the way in and the 29.970 file does NOT line up on a frame boundary, the 29.97002997003 file DOES. The theory seems to be correct, any file captured or processed outside of Vegas will not line up on a frame boundary unless you zoom in an manually snap the end to the boundary. Also, on the 29.970 file, not only does it not line up, but the audio portion is not the same length of the video.

So, it appears that the problem in the thread link I posted in an earlier message where John Cline described a repeated frame problem at 2 seconds and 28 frames into a clip using externally generated media and this problem can both be attributed to the fact that Vegas deals with the 29.97 frame rate correctly while every other video program on the planet does not.

I'll put these two test files on my server tomorrow sometime if anyone wants to download them and see it for themselves. I'll post the URL here when I do.

Also, in all fairness to John Cline, I called him on the phone tonight and he was the one that came up with the theory I posted a few messages ago. He also suggested trying the test files.

James

I'm just curious -- do you type out "29.97002997003" from memory?

Yes, Vitamin_D, I do.

James

"If the theory is correct, then the problem should only manifest itself on NTSC footage that has been generated or processed with another program, like Premiere, After Effects or Virtual Dub. "

James, you may have something here. I have a Storm system and this last project where I had the problem was captured originally through secnalyzer using the Storm card. I'll keep an eye on some of my current projects that have been captured in Vegas to see if I have the problem.

Marc