Frame accuracy at the edit point

[agv]

I thought I once saw a posting about this, but couldn't find it...forgive me if I missed the thread.

My problem is that when I play an edit, the in point on the clip is sometimes off by a frame. It's evident when an edit point is right at a frame that visually stands out (like a camera flash going off). When the edit is repeatedly played, sometimes the flash frame is there, sometimes it isn't. I have a sharp eye for this, so I know it's not me.

Has anyone else observed this with TeD? Is there something I can do to improve my settings for frame accuracy?

My guess is that I might be able to render out the entire edit as a solution.

I am running the latest version of VT, but not on the fastest machine (it's a dual 1Gig PIII). I am using an external Medea SCSI hard drive.

Thanks for any advice!

[vip3dran]

I've seen this problem too.
If you scrub on the timeline using the mouse and set your clip's inpoint, what you see and/or hear when playing it back may be different than if you scrub with the left/right arrow keys (frame-by-frame).

I believe this may have to do with being able to set an inpoint mid-way between frames when using the mouse -versus- being right on the beginning or end of a frame when using the arrow keys.

(At least that's my theory)

:D

[agv]

Thanks for that advice. I'll try it!

[tmon]

This is a known bug !

It has been confirmed and reconfirmed. Please help me squeak the wheel, as NewTek has not placed its squashing at the highest priority that I believe it deserves, IMNSHO (in my not-so-humble opinion). It is not a "features request" that's for sure.

I believe that the reason this has not been reported more widely, is that a lot of T[2] users are event videographers, and they don't notice this as clearly as those of us who are cutting :15's and :30's day in and day out, where often we are cutting pre-cut footage and depend upon frame accuracy.

Email me if you want more information.

[JReble]

Yup...I'll sqeak to that.....err I mean I can confirm that as well. Big problem and it needs to be fixed. I'm not crazy about the impending paid release of VT3 when something like this inaccurate frame edit issue is still uncorrected in the version we all bought.

It's almost as bad as the lousy recorded audio levels which is still going strong after much noise on the subject.

[agv]

Well here's a little extra motivation for Newtek.

I will upgrade to VT3 if it will fix this bug, but if it doesn't get fixed I'll eventually need to migrate to a frame accurate editor.

[mblade]

I agree with both of JRebles points. Can we at least get confirmation that these will be addressed in T3? All things considered they should have be fixed in T2...

[tmon]

Let us hope that the current army of VT[3] Beta testers are working hard to confirm that this bug has been killed. I would have loved to join the Beta Force, but I have too many deadlines to meet with my T[2] system....

I understand that many users are perhaps UNAWARE of this issue, but I can't see how anyone who cares about the quality of this product, or the future revenues of NewTek, would let this thing stay alive in the public release of VT[3]. If necessary, I would be willing to wait much longer for the release of VT[3] until it is squashed.

If there are any VT[3] Beta Force people out there who are unclear about how to test for this thing, I'm sure they would email me, right?

;)

Right? Hint-hint-hint....

[JReble]

(Lone cricket chirping.........)

.....chirp

.....chirp

...............chirp

[tmon]

Another, possibly related issue, or maybe not. Perplexing to me, nonetheless:

A Clip's outpoint can END or BEGIN midway between "frame" markers on the timeline.

Can someone tell me where the outpoint is (see attachment)?

[agv]

I too am foggy about this. I don't understand why the clip edge doesn't just snap to the exact frame line since you don't cut in between a frame anyway.

Perhaps there is an advantage to the audio being cut more precisely than 1/30th of a second, but not video. Having the video in/out point set inbetween two frames makes reading the time line a little vague and makes it more work to keep clips snapped together just right.

Does anyone know if there is some reason or advantage for this being so?

[Michael Englyst]

I believe the frame accuracy bug has been fixed in VT[3]. I saw a discussion about it, and Andrew Cross said it's now *extremely* precise. I'll try to find the post.

Found Andrew Cross' response at the VTNT forums:

http://www.videotoasternt.com/forums/read.cgi?25526

I'll look further since there's a more detailed post somewhere.

[Michael Englyst]

Here's the thread with Andrew Cross' confirmation of the bug being fixed:

http://vbulletin.newtek.com/showthread.php?s=&threadid=8121

[tmon]

Michael, I don't like to "double post," but since you made a reference to that very long thread, here is one of several unanswered [I] posts from it. I post here because this bug is worthy of it's own thread. Not a single VT[3] Beta Tester has responded to the original query regarding this CONFIRMED T[2] bug with any testimony. If it has been squashed, that's great, but as a potential buyer of both an upgrade and another system, I'm not going to be spending bucks on faith, particularly when I know that every other NLE on the market has the capability of "1/30th" of a frame accuracy.

************************

[I]Andrew,

quote:
--------------------------------------------------------------------------------
The problem occured where on any particular track the clip ended without a clip following it.
--------------------------------------------------------------------------------

Perhaps you are referring to early builds of VT[3]? In T[2], it occurs with regularity in tracks with adjacent clips and I have confirmed this with files and projects that I have previously submitted as "evidence." Both in instances of cuts between clips on the same track and in the case of 32-bit overlays as I noted above.

quote:
--------------------------------------------------------------------------------
we actually know about time now to better than 0.0000000000000000000000000000001 seconds of precision
--------------------------------------------------------------------------------

This is very impressive and I'm sure it's significant from an engineering standpoint (I don't even know how to describe what that number is), but the bottom line is that, as an editor, I'm only concerned about 1/30th a second accuracy. I haven't enjoyed this with T[2], so I'm hopeful that VT[3] can provide it. If so, I will be a happy camper and join the VT[3] release party. If not, I'll stick around to whine a bit more since I have an investment to protect both at work and at home.

I'd still like to hear actual testimony from users addressing BOTH of my posted scenarios above. Short of that, I'm hoping to get my hands on a VT[3] workstation myself to perform the above evaluation procedures. I will surely post my comments following the experimentation.

[Michael Englyst]

Oh, sorry. Gotta read everything properly the next time :)

I really believe NewTek would make sure this was fixed. So let's cross our fingers and wait for VT[3] and make judgement then.

[jcupp]

Originally posted by taiji
...Not a single VT[3] Beta Tester has responded to the original query regarding this CONFIRMED T[2] bug with any testimony[/I]

Uhh, until Monday Betatesters where prevented by the NDA from commenting on bugs in public so I'm not supprised none have responded. I have never noticed this issue in either VT[2] or VT[3] so I can't say whether or not it has trully been fixed but if the good doctor says it's fixed it probably is.

[tmon]

if the good doctor says it's fixed it probably is.

Not good enough, and not necessarily true. The proof is in the edit, and I haven't seen it yet. There are inconsistencies in the reportage of the "fix" relative to demonstrated instances of the bug, the "good doctor" never claimed to have confirmed the fix for 32-bit overlays, nor was there ever a statement made that VT[3]'s NLE is FRAME-ACCURATE, which is what editors care about.

It's not to say that there have not been a mountain of other bugs that have been annihlated quite handily by the talented NewTek crew, but this one has been a particularly clandestine one. Seemingly, the majority of Discussion Board users are event videographers less inclined to notice the pesky thing to begin with.

I do hope that with the "lifting" of the NDA, that others will attempt the tests that were outlined in the above-mentioned thread. Perhaps in the coming weeks, others willl post actual results here.

I've been conversing with Andrew and others about the bug for almost a year without getting a fix, so it's hard to say I'm in a hurry to get it fixed, but I cannot overstate the importance of doing so: No rush to judgement, no rush to $purchase.

[Paul Lara]

Taiji,
I grabbed an RTV clip, and in Aura, placed a solid frame of white in the middle of the clip.

I then made the frame immediately prior to the flash of white my outpoint. Scrubbing, playback of the cut to the next clip, and even dropping in a crossfade never showed any white flash on playback.

I hadn't responded, because I had not yet had time to test it on my machine:

hp workstation x4000
Dual 2.2Gig Xeon
1Gig RAM
Ultra 160 video drives.

I can now say I have tested it, and it performs with frame accuracy time after time, regardless of where I put this clip in my project.

[tmon]

Thanks Paul. That's good news.

If you get a chance, could you confirm it with the "32-bit Overlay" test too? IMHO, aside from NDF vs. DF discrepancies, this fix will put the product over the top. My ultimate test is when I have to do a project containing over 300 clips with over 50 32-bit overlays and all, using copy/paste and clip inherit maneuvers. These are the types of projects where the bug has really drove me crazy.

I can hardly wait to join the party!

[agv]

Paul, your test would not reveal the frame accuracy problem on my Toaster, but it does appear if tested this way:

Using the same clip that you created (black with one white frame in the middle), set the in point on the clip to include the white frame as the very first frame. Cut and paste a dozen or so of these together, then play. If your Toaster is having the same problem as mine, it would sometimes flash the white frame, sometimes not.

If I understand correctly, there might be a fix of this problem for VT3, but obviously I can't test it myself. Once Newtek gives the word to betatesters that they can post results, I would love to hear that the bug is squashed.

[Paul Lara]

AGV, the barn door's open; BetaForce is over.
Anyone who was testing VT[3] is free to speak, as we are now publicly shipping, and their non-disclosure agreement has expired.

[DonN]

This is fixed in VT[3].

Ahhhhhhhh, the light, fresh air..... VT[3] is shipping.
Don

[cholo]

What annoys me sometimes about the aforementioned bug is when I make seamless motion backdrops for videos and sometimes they play seamlessly back to back and sometimes I get stutters when the loop reaches it's own tail... When I force render these cuts the problem usually goes away though, hope this helps out folks out there still on T[2] like myself. :)

[Rich Deustachio]

I would also see that with purchased looping backgrounds in VT2. I tried several loops in VT3 and so far they work fine.

[tmon]

Rick/Paul/anyone with a VT[3],

Ever get a chance to try the 32-bit overlays test?

[tmon]

Speaking of .03336670003336670003336670003367
Frame-Accuracy ;) , and in addition to my query regarding the 32-bit overlay test, has anyone tried insert edits in the middle of a program already existing on a tape with the print to tape function?

E.g., let's say I've finished an edit of a long program, and have already printed it to tape. Now, three days later, the producer wants to change one shot. It would be quicker to make the change in the VTEdit timeline and insert that one shot onto the master tape than to have to re-output the whole timeline again.

Does it work just as well with a master videotape that is LTC-striped with either DF or NDF SMPTE?

Is there a list of tested video decks with which frame-accurate print to tape and batch capture has been confirmed to work?

[tmon]

(DonN., specifically what "fix" are you referring to?)

RE: 32-bit overlays, it sounds like I'll have to make a trip to a dealer's shop to test this myself.

RE: TC insert edit to tape, I guess I'll have to drag a BVW75, RS422 and coax cables over to the dealer's shop and do all the tests myself.

With regards to BC and frame-accurate print to tape, what RS422 decks do people on these boards use, and with what degree of success? Or maybe people here don't have a need for insert edits to timecoded tape reels?!?!?

:o

[wvp]

Originally posted by cholo
What annoys me sometimes about the aforementioned bug is when I make seamless motion backdrops for videos and sometimes they play seamlessly back to back and sometimes I get stutters when the loop reaches it's own tail... When I force render these cuts the problem usually goes away though, hope this helps out folks out there still on T[2] like myself. :)
One cause of this would be that T2 by default inserts clips with the in & out points 1 second into the video. This is to accomidate the pre/post roll needed for a 2 second transition. In T3 you can set in pref. for it not to do this.

Taji,
Sounds like the beta testers/VT3 users that have used the system in the way you have described have spoken. I have one VT3 up & running & 2 more to get set up. I have not had opportunity to test what you are describing. I say make the dealer show you why you should upgrade!

[tmon]

Last Friday, I finally took a trip to my NewTek vendor.

I did three "errant frame" tests with the Gold Master VT[3] initial release, using the same RTV clips that I used to confirm the bug earlier.

1. A clip with a "cut" built into it, trimmed back to the last frame before the "built-in cut." I butted this trimmed clip up against another clip. Previously, this would result in an "errant frame," whereby, upon playback, the frame after my trim point in the first clip would "flash."

Test Result: No Errant Frame upon playback.

2. A 32-bit overlay to key over a piece of video, trimmed to match the last frame of video at a "cut" in the underlying video. Previously, if I were to trim the overly to the last frame of video before the cut, the overlay would carry over for 1-2 frames after the cut, and be visible on top of the next shot. n T[2] he irritating workaround is that I have to trim all 32-bit overlays back an extra frame to prevent this from occurring.

Test Result: No Errant Frame on the 32-bit overlay, with the key ending appropriately at the "cut point."

3. Taking an RTV clip (created in Aura), consisting of exactly 1 frame of white at both the head and tail of an otherwise black clip, trimming the clip back one frame at each end (i.e. trimming the white frames), and butt-editing the trimmed clip next to another purely black clip. Previously, upon playback, this would have resulted in a "flash frame" with the white showing up even though you had just trimmed it back. Unfortunately, I only tested this a few times. I.e., I didn't paste consecutive instances of the trimmed clip back to back to see if I could get it to show an "errant frame".

Test Result: I did play it back 3-4 times, with no "flash frames" showing.

Because this bug was intermittent before, I'm a bit hesitant to pronounce it as "officially" dead prior to some more rigorous testing, but the preliminary results are positive enough to give me confidence to approve a purchase order for the T[2] to VT[3] upgrade.

Congratulations, NewTek!

[agv]

I also did the flash frame test just recently on a friend's T3 and I am pleased to say that after several dozen times of playback, there were no errent frame edits. Seems to be working great!

[tmon]

This is an unofficial notice for all users of VT[3]'s NLE.

I have gone through quite a bit of testing and hair-pulling on this particular bug for TWO AND A HALF YEARS. Recently I shared some results with the NewTek staff, and would like to share them with other users.

There have indeed been adjustments made to the VT[3] software to alleviate the "Errant Frame Bug." In other words, it is not as pervasive as it used to be. However, it is still possible to be editing with VT[3] and have "flash frames" appear.

As of now, the only way that I know of to prevent this is to use the cursor arrows to set your cut points. To set in/out points any other way is problematic. For example, if you attempt to set in/out points by grabbing and dragging the head or tail of a given clip in the timeline, your chances of achieving a frame error are as good as 50%.

This can be verified by zooming in all the way into the timeline and you can see that by dragging the timeline indicator with the mouse, it is currently possible to position it for a cut (or a "grab and drag" trim) so that it lies somewhere BETWEEN frames. Therein lies the problem. If your outpoint is less than 50% of the way to the next frame in-point, you won't get a flash frame. If it is AFTER the 50% mark, you will get a flash frame.

Intermittently, I have also had this problem occur when attempting to use the Edit Properties Panel to set out-points. This may, however, be a cache issue. I'm not sure yet.

I have suggested that NewTek rework the software so that all movements of the timeline indicator and "grab and drag" editing default to frame-increment movements, as the cursor arrow buttons do.

Until then, it appears that the only way to insure frame accuracy in your edits is to use the cursor arrows, press "C" and then select the unwanted parts of your clip (if it is prior to your new cut) and delete them. (If you are using this method to cut the clip at its out-point, you can perform the cut, then just press delete, as the unwanted tail of the clip is selected by default).

As a full-time editor working mostly on :15 and :30 spots, I must say that this is an extremely serious matter, and I hope that NewTek is able to resolve it soon. For any other feature to have a higher priority, in my mind, is ludicrous. Unless, perhaps, as might be the case, persons such as myself are not a part of NewTek's "priority market target."

[ted]

I hope NewTek doesn't consider you "Not part of their target market" as I also spend most of my day in TEd doing :15's, :30's and :60's.

I've asked for a return of the "snap" control which might help with this.
I guess you could say that being able to edit between frames could be a plus, but obviously, you gotta have the clips butt up to each other.

[tmon]

Ted,

The snap control would be nice, but with video I don't have any reason to cut at the subframe level, do you? Instead of being the option, I would prefer editing to be frame-based, like every other editing system that I've ever come across, linear or non-linear.

Audio is another issue, of course, wherein we want to be able to edit at the sample level.

I still say there might be something going on here with the video cache too. It seems to get worse on those rare occasions when I'm working on longer form projects...

[ScorpioProd]

Yeah, audio editing at the sample level would be great (Premiere Pro feature), but what do you see as a plus to editing between frames in video, Ted???

Unless you mean that being able to edit down to the field would be useful. Actually, I can attest to this being true. I had an old VHS tape I had to make some good video from, and it had some kind of field jitter going on in some existing slow motion segments. I manually corrected the jitter's vertical offsets with the positioner only to discover I'd only corrected ONE field of each frame, since the other field had jittered to a different amount, and this was like 100 corrections I'd made, and there was no way to alter the other field in VT-Edit.

So, I did the only logical thing, I deinterlaced to the field I'd corrected. Lost half my resolution, but made the video watchable with no jitter. :) (Used TMPGEnc to do this, there wasn't a way inside VT-Edit to do it.)

As for the problem in this thread, I have seen that zooming in on the TL sometimes sticks me between frames, but I figured that the actual edits would always round to a frame cleanly, but I guess not as cleanly as I thought.

[agv]

When the frame errant problem gets corrected is the day I upgrade to VT3. In the meantime, I seem to have better luck using Premiere with Bob Tasa's plug in, which hasn't shown any errant frame problems (at least not in the short time I've tested it).