when I go into that clip's FX event timeline, I discover that the diamond at the extreme left side of the timeline doesn't represent the first frame of my clip. Rather, it represents the last frame of the previous clip!
----------------------
Same here, drives me nuts.

Craig H.

rextillion:
Yes, Quantize to Frames is checked. SF, am I doing something wrong here? If not, why isn't everyone else reporting this obvious glitch?

SF, this appears to be an obvious glitch. But if that's the case, why isn't everyone else reporting it? Am I not supposed to be setting the extreme left keyframe diamond? And why does it represent the last frame of the previous clip?

Please send a project file to drdropout@sonicfoundry.com and reference this thread. I'll look into it and post info here.

I have experienced that same thing with VV 3.0c (sometimes the 1st keyframe shows the last frame of the last event). Can't remember if I've discovered a pattern to this.

G

Okay, I will make an abbreviated veg file with the quirk and send it over to Dr. Dropout. Thanks.

I've had a chance to play a bit more with the two problems I mentioned earlier. Here's what I've seen so far:

I can't get VV3 to replicate the "corrupted first frame" condition. As I indicated, this is where the first frame of an edited clip is from the clip, but from a time further down the timeline. I have gone back to my veg files, trying to find any one of the half-dozen instances where this was occurring, and I can't locate a single one. Perhaps I hit upon a tender spot in VV3 that self-healed as soon as I began a new session. I will let you know down the road when this happens again, and whether re-starting will fix it. (Honest, it WAS happening; I first noticed it when I did a render to tape, and saw it on the tape.)

The second issue is more puzzling. I have discovered that if you zoom in on the timeline and examine the junction of two clips, the normal condition is that putting the cursor exactly on the junction will show the following clip's first frame. But in lots of instances in my veg files, the frame displayed at the junction is the last frame of the PRECEEDING clip. Sure enough, if I go into an FX, the diamond at the extreme left end of the timeline represents that last frame. Oddly, the effect executes properly for the succeeding clip, even though technically it shouldn't. I apologize if my description is confusing everyone.

If I grab either clip, slide them away from and then back to the junction, the erroneous presentation persists, but if I trim both clips away and then back to the junction, the first frame of the succeeding clip now suddenly becomes dominant, and everything behaves normally from that point.

This is a pain, though I can live with it. The only real hassle is that I can't see the result of applying FX, since the preview window is showing the preceeding clip. I can get around it by going into the middle of my clip, applying an FX while watching the preview window, then copying that diamond's setting and pasting it into the diamond at the extreme left end.

----------15 minutes pass...--------------

Okay, I'm back. I figured I'd just append to this message rather than start a new one.

Very strange. You know those tiny blue triangles in the upper corners at the clip ends? When I butt two clips together, normally those tiny triangles merge, forming a slightly larger blue triangle. But with this rogue preceeding clip, when I butt it up against the succeeding clip the preceeding clip's tiny blue triangle disappears, and the succceeding clips triangle turns bright green. This must mean something to somebody.

Another thing: The preceeding clip shows tiny hash marks indicating frame timing; the succeeding clip only shows hash marks indicating the location of the particular frames displayed.

I've had this same problem too, actually (although I'm only using Vegas 2)...
I've always assumed it to be an error on my part-- that I ended up stretching the front end of a clip (causing it to loop the last frame to the front) when moving it, but the single frame doesn't show on the timeline, in my experience.

This, however, has only popped up a few times, and only when I was importing .avi files from Ulead Cool 3D. I've never had it happen otherwise, but I'm betting that's not the issue...

David.

riredale:

Dark blue triangles mean the clip has no fade on that end. Light blue / teal means there is a small fade (small at the current zoom level; at larger zooms when you can see the fade, the triangle disappears).

So, when you moved the clip closer, with QTF on, it slightly overlapped the adjacent event and created a very small auto-crossfade. If this is a problem, trim the "out" point of the left event so you get the dark blue triangles back.

///d@

This is a pain, though I can live with it. The only real hassle is that I can't see the result of applying FX, since the preview window is showing the preceeding clip. I can get around it by going into the middle of my clip, applying an FX while watching the preview window, then copying that diamond's setting and pasting it into the diamond at the extreme left end.
-----------------
I find just left click sliding the 1st keyframe to someplace I can see the effect adjustments (past fades or transitions), make adjustments then slide it back to far left works well.
Interesting results when you trimmed both clips??

Craig H.

SonicDennis:
Thanks for the feedback. "Quantize to Frames" is always on, still get the problem. In fact, it's happening right now on an entirely new project. I can zoom in to the degree that the entire width of the visible timeline is no more than a half-dozen individual frames; the light-blue triangle still shows, and the frame just to the left of the cursor shows in the preview window, not the frame just to the right. Something is causing the software to think the preceeding clip is dominating the succeeding clip at that particular edit point.

Looking back on the editing I just did in the past few hours, I can see that there are about 5 light-blue triangles out of perhaps 50 or 60 cuts showing currently. These are all just straight cuts, and there is nothing fancy about the clips on either side (no rerenderings). Furthermore, I notice that when I zoom in to the extent that every frame has a picon, maybe a third of all the edit points show the left frame dominating the preview window at the edit point, even though the picon on the timeline shows that it is the succeeding frame that should be showing up on the preview window! Curious...

Hi Richard,

What is the origin of the footage?
What bitrate is the audio (has it audio)?
Are the rogue clips previously trimmed, or are they end-to-end clips with no unused portions?
What time-format is your ruler set to?

Lookin fer cloos,

MPH

The clips are DV avis, captured by ScenalyzerLive (because I love the timecode stamp).

The audio is conventional 48k.

Pretty much every clip I work with has been trimmed. After all, I'm an artist.

The timeline is SMPTE drop frame, 29.97.


This is very puzzling, and I'm sure it's due to some combination of settings. I may next try to set VV3 to default settings, to see if the timeline then behaves normally. I guess the next step after that would be to reinstall the software.

Hmmmmm... thought so. Based partly on the other comment about imported footage.

You might try a brief test capturing with Vegas, rather than Scenalyzer, before you tear the house down.

Also: can you expand on this: "Another thing: The preceeding clip shows tiny hash marks indicating frame timing; the succeeding clip only shows hash marks indicating the location of the particular frames displayed."


Regards, MPH

Yeah, weird, huh?

When I really zoom into the timeline, the horizontal timing expands until the point is reached that tiny hash marks are able to be displayed at the bottom of the video clip, showing the exact location in time for each frame. As you zoom in further, these hash marks spread out until there is room for VV3 to show a picon representing that particular frame. The picon is tied to an individual hash mark.

Or that's the way it is supposed to work. With my clips, sometimes the hash marks appear showing EVERY frame (normal), and sometimes only those hash marks showing the location of just those picons currently on the clip appear. In other words, only a few hash marks appear, rather than hash marks representing every frame.

I will take a few minutes this morning to capture via VV3 and see if this strange situation is somehow related to ScenalyzerLive. Frankly, I doubt it; a DV avi is a DV avi, right?

There is an updated beta version (mine is dated 10/09/02) of scenalyzer that you can request from the author. One of the updates reads as follows:

fixed: A problem with NTSC video in vegas: sclive now writes NTSC files at a framerate of 30000/1001 fps instead of the 29970/1000 fps used previously.

I don't know if this will fix your problem but it just might.

Hi Richard,

I have a hunch this is related to a topic earlier this year regarding rounding the framerate to 29.97 exactly:

http://www.sonicfoundry.com/forums/ShowMessage.asp?ForumID=4&MessageID=109530

"NTSC video runs at a frame rate of 30,000 / 1,001, or 29.97002997002997... (repeating decimal). Some programs incorrectly use a frame rate of 29.97 (exactly) instead, for whatever reason. If such a clip is placed on the timeline, the two rates slip over time, and a frame gets repeated. The actual frame varies with clip placement and other factors, but apparently with Quantize to Frames on, it's often frame 4 according to Gammaburst. If you override QtF and slip the media or move the clip a little (like 30mS to the left), the duplicated frame gets moved out past the end of the media and everything is fine.

///d@"

I don't know how Scenalyzer does their math, but I'll wager if they use 29.97 exactly, we'll see some interesting ripple effects.

I looked at some other media... generated, WMV, and how Vegas displays those ticks in the TL. Generated media shows picons and ticks down to the sample level, WMV is 30fps, so you will see the picons and ticks start to creep forward as you move downline.

So, I'm gonna go out on a limb and suggest that the frame-breaks in a Scenalyzer clip might not jibe with the TC flags that Vegas is assuming are at the correct framrate... or something like that.

Eager to know what's really happening here,

MOments later... I just saw Jetdv's post (I was compoosing while he was posting)... too funny.

MPH

Hey guys, thanks for the feedback, but I don't think it's Scenalyzer. I have GOT to get back to real work here shortly, but here's what I've discovered over the past two hours:

(1.) Did a brief, 12 minute capture using the Vegas capture program. When I began to play with the avis captured, same results. That leaves Scenalyzer off the hook. Plus, the most recent beta of Scenalyzer that I have been using takes into account the (1000/1001)*30 discrepancy that earlier versions overlooked (from what I understand). Darn.

(2.) I first did a repair of VV3c. Still the same results.

(3.) I removed VV3 completely, installed VV3b. Same results.

(4.) Now I'm back to VV3c. Still the same effect.

On the positive side, though, I think I've found a way to replicate the problem:

(a) Pull any avi file into the timeline.

(b) Split that avi at a couple of different places.

(c) Move those split pieces that are inside (not the end pieces) around in various ways, kind of like a shell game. Since they are bounded by the end pieces and were cut from within them, no matter how you move them around they should fit precisely, right?

(d) Eventually, you'll put a piece into a hole where it should fit exactly, but instead you'll note that the blue triangle at the end of the piece you're moving disappears, and the blue triangle at the beginning of the following piece turns green. It thinks there's an overlap, but there shouldn't be. If you zoom in to individual frames and look at that border, most often you'll find that VV3 is confused and displays the frame to the left of the border in the preview window rather than the frame to the right, which it should be showing.

I suspect that the timecodes that represent the exact beginning and end of individual clips are getting corrupted somehow. What's maddening is that you might get the green triangle right away, or it might take a couple of minutes of moving pieces around. Yes, I know about snapping; it happens anyway. Funny thing is, once the green triangle corruption has started, you can turn snapping off, zoom in, and manually move one clip over to butt up against the other clip, and the green triangle will appear even with no overlap.

If you grab the piece that has the green triangle in the upper left corner and move it around and then back into place, the green triangle effect moves to the right one clip's worth. Keep moving succeeding pieces, and the green triangle eventually makes its way to the end of the captures and disappears.

SF, if you can reproduce this fault, can I get a beta copy of VV4? Please?

GG, no, I am not doing anything with sliding a clip around within an event (I hope I'm using the official terminology here). If you mean where you take an event to the timeline, shorten both ends, and then grab the shortened clip with the ALT key pressed and "slide" the event within the constraints of the clip. No, none of that.

I mean to take an event to the timeline, cut it up, and move the pieces around so they still fit within the constraints of the first and last pieces, but are now in a completely different order. Eventually, I get a green triangle. It's saying there's an overlap, but there shouldn't be.

Good work, Richard... I can replicate the issue. But I'm not using Vegas captured DV.

I'll try that next.

Now, to get busy.

More later, MPH

I am not able to reproduce this after many attempts, but I'd sure like to. Using Vegas 3.0c-captured DV in Vegas 3.0c, is there an exact set of steps that makes this happen every time? If somebody can provide the shortest possible route for us to repro in house, we can fix it.