Jaap Verdenius
Forum Replies Created
-
Jaap Verdenius
July 8, 2010 at 9:47 am in reply to: timecode differences between long and short clips made from the same recordingYes only the TC is jumping, not the video. Really. I can see it clearly on the XDCAM deck.
But this jump is not noticed as a TC break by FCP.
I just took the recordings to a colleague with a Media Composer – exactly the same thing there!I think what happens is the master camera is running faster than the other ones, who (in order to stay locked) skip one frame of TC. So one camera produces 15,000 frames in 10 minutes, the other one 14,998 – but after these 10 minutes they run exactly the same TC, thanks to the TC jump.
And the fix for this is not that easy, because these camera’s don’t produce the same amount of frames within one time interval. You can’t solve that with a new TC track, you can only compensate making various multiclips with different sync points, that are sync only during a part of the recording.
-
Jaap Verdenius
July 8, 2010 at 7:54 am in reply to: timecode differences between long and short clips made from the same recording“Bitrot”?
Anyway, I turned on the character generator on the XDCAM player and I can see now that at certain points the TC on the xdcam is jumping one frame ahead.
So, probably not a FCP issue, but rather a camera that has a problem keeping track of the timecode forced upon it?
-
For me it didn’t fix it. It is still there when I play a timeline with a multclip and the viewer playhead sync open. I had to go back again to the 1.2.5 version of the install disk.
-
It’s in the manual – search for “Subframe Synchronization of Audio and Video”
-
Can you describes the glitches, what is the length, does the waveform tell you anything? Can you relate them to certain clips or tracks? Are they on one channel or on both simultaneously?
And just to be sure that it is really in the aiff – if you open this aiff in Quicktime Player (or reimport it into FCP) do you get the same glitches as in Soundtrack Pro? -
Same problem here – started after the 7.0.2 update, for certain never saw it happen in 7.0.1.
-
I haven’t seen it, but
– were you able to play your sequence correctly from FCP to a PAL monitor? Just to exclude that the sequence is the problem.
– did you set the DSR11’s audio settings from 32kHz back to 48kHz? I remember that it tended to switch back to 32kKz which always caused some kind of problems. -
You have to start with the question if the problem occurs in FCP or afterwards. If it is already there in FCP it probably has something to dot with the way you import your tiffs. If it happens afterwards it is an encoding problem.
In many cases the video is OK and what you are looking at is a display problem. So when in FCP, if possible look at a 1:1 display of your video on a broadcast monitor.
I would prefer an uncompressed timeline over DV. I have no idea why Animation would make things any better. Same for the Slug. Keyframes are fine.I guess DVDStudioPro is more pro than iDVD – but I am just looking at the name! Anyway the essential thing is that you need to be able to tweak the encoding. Therefore I would export the timeline to Compressor and encode in Compressor, using the best settings (variable and two-pass or the “best encode” setting that comes with Compressor). This will give you encoded mpeg video and aac audio that you can take into DVDStudioPro – the process inside DVDStudioPro will be pretty straightforward.
If the fades are really long it may make sense to put a few compression markers on the timeline in FCP (these are forcing Compressor to do an extra effort on that spot).
Jaap
-
The uncompressed version is probably to much for your media disk. Try ProRes.
Jaap
-
Maybe you could use “copy” instead of “use existing” and throw away the original media afterwards?
Jaap