QT Sync and Pro Tools weirdness!

[subwoof]

A Final Cut Pro editor has sent me QT's of a 24 min show in which he has used QT Sync to embed a burn-in window. He exported it as an H.264 output. When the video is played in Quick Time Pro, it is fine. When it is imported into Pro Tools 7.3 cs7 and played back within the session, it plays out fine for about 14 minute, then the image starts over again from the beginning of the show. It happens on the same frame each time. It does the same thing through MOJO, or just playing back in a small window within Pro Tools. The video track in Frames Mode plays plays back correctly though. It keeps playing the right image to the end of the show, but the video output has gone back to the first frame and started over again!!!

Anyone hear of this anomoly? I have tried re-exporting and resaving the video to no avail.

Any ideas? (By the way, why can't a big company like Apple make Final Cut Pro have the ability to export a Quick Time with a burn in window?!!! That is Post Production 101 stuff!!)

Thanks

Mike

[Starcrash]

Originally Posted by subwoof

Any ideas? (By the way, why can't a big company like Apple make Final Cut Pro have the ability to export a Quick Time with a burn in window?!!! That is Post Production 101 stuff!!)

Sorry I can't help with your main issue, but I just wanted to point out that FCP can easily do burned in time code. Here's how:

http://pascalgarneau.com/finalcut.html

(scroll down to about halfway down the page - TIMECODE BURN)

[subwoof]

Hey! Thanks so much for that link. You know, it's hard enough doing post sound without having to tell video editors how to do their job too! This is a great document, which will now go out to all the Final Cut editors I know.

Thanks a bunch.

Mike

[Sonsey]

BTW.... I HAVE seen this exact weirdness when using QTSync to output TC Burn in... Not H.264 but DVCProHD... Seems ok with MJPEG...

[mix109]

Hi Pascal
Excelent guide!!
My sincere thanks also.
Digi Admins please do consider this as a sticky thread

[subwoof]

Originally Posted by Sonsey

BTW.... I HAVE seen this exact weirdness when using QTSync to output TC Burn in... Not H.264 but DVCProHD... Seems ok with MJPEG...

Thanks Howard. I will have the editor output a MJPG-A and see if it works with QT Sync. I guess for a freeware program, we shouldn't complain if it has some bugs...
but I will see if I can report this problem to the software creator.

Thanks

Mike

[subwoof]

I just found this link with some alternate methods of embedding a time code burn in window in FCP. Here is an excerpt from it:


From Nick Meyers

• Create an ordinary FCP Text object in the Viewer (CONTROL-X).
• Go into the Controls tab and erase the words "Sample Text".
• Now put the Text object into your timeline and apply Timecode Reader to it.

The Text object now acts like a layer for the timecode burn. When you don't want it, just select it and press CONTROL-B (Clip Disable). When you want it back, select and press CONTROL-B to enable it again. This saves the nesting step.

Like all generators in FCP, the basic text generator has a default length of 2 mins & 10 seconds (think that's right). To change it simply go to its duration field (top left, or hit TAB after opening it to go straight there) and type in the duration you want.

Tip : You can option-drag values between the timecode fields in FCPs viewer, canvas, and Log & Capture widow. In this case you could hold option, drag the TC from the duration field of the canvas (assuming no in/outs in the timeline) and drop it into into the duration field of the viewer. The text overlay will now have exactly the right duration for the sequence.

From Derek Mok
If you are using Modify - Timecode on the Text clip you must enter the entire timecode including 00s at the beginning, and must choose Source TC.
If Timecode Reader is already on the clip, Modify - Timecode will NOT update the filter. The timecode on the filter will continue to start at 01:00:00:00; it will not update to your modified timecode. If you cut the filter and paste it right back in, the numbers will be updated.

Also view the Quicktime movie over at Ripple Training : Timecode Burn


Mike

[hummerZ]

ins't h.264 a bad choice of codecs for frame-accurate posting? i thought MJPG and DV were really the only ways to go???

[Frank Kruse]

Originally Posted by subwoof

Thanks Howard. I will have the editor output a MJPG-A and see if it works with QT Sync. I guess for a freeware program, we shouldn't complain if it has some bugs...
but I will see if I can report this problem to the software creator.

Thanks

Mike

The programmer is a nice guy. Do send him the info. He´ll be interested in knowing about it.

frank.

[Noiz2]

Part of the reason that FCP's built in window burner is a pain is that it's a real time export, or was - haven't used it in awhile. It was also limited in things like offsets. QT Sync can do it MUCH faster and if your willing to work with reference videos almost instantly.
h.264 works OK for post if you force a keyframe every frame. If you just use the defaults (something like a keyframe every 80 frames) it's a dog scrubing around but plays forward fine.
I agree with the description of the developer, let him know about issues and he will fix them.