-
FCP altering the duration of original files
We are currently working on a VFX project that requires us to deliver to client Pro Re LT at 23.976. The quicktimes we create are made via shake. These playback perfectly in quicktime and display all the frames. Every now and again some of the files throw up a warning when importing in to FCP saying ” The Following media files are not optimized for Final Cut Pro” it then recommends to recapture or create new copies of the media to improve performance. I ignore this at this stage, however after importing the files display 1 frame shorter in FCP and when going back to original file in quicktime it has altered the file so it too loses the last frame. I did a number of tests on another shot which had this probelm and ou RND team have looked at the files header and noticed that FCP has rewritten it. Why is FCP altering the original source surely no application should be meddling this way with original source material. I have had FCP not display the last frame of clip before but the original QT has always been untouched and displays correctly, this we worked out could be fixed be conforming the files in cinema tools to 23.98. This solution does not work for this new issue though as you cannot conform LT files in Cinema tools and it is also too late after you pull it in to FCP as it has altered the file to be the shorter duration.
Anybody else heard of this type of thing or expereinced it. If so any advice would be really handy.
This happens on both our versions of fcp we are running being 6.0.1 and 7.0.2, also on Snow Leopard and Leopard machines.
-
15 Replies
-
[Simon Arnold] “The quicktimes we create are made via shake. “
Just to be sure, you’re set Shake to render 23.976 and not 23.98, correct?
Jeremy
-
Its not that crazy counting thing is it? Where one program starts counting at frame 0, while another program starts counting at 1?
Tech-T Productions
http://www.technical-t.com -
Shake can only render at 23.98 and not 23.976, this can make FCP miss out the last frame but never actually alters the original file as you can always view the missing frame in QT. However in this instance it actually alters the file. I think it is actually down to how we are making the quicktimes as normally you can use Cinema tools to conform pro res but it is greyed out with our files.
I have spoken to our dev team and it might be down to the fact we are using ffmpeg after shake to add audio to the output as Shake can only do it manually and we need it fully automated.
-
[Simon Arnold] “I think it is actually down to how we are making the quicktimes as normally you can use Cinema tools to conform pro res but it is greyed out with our files.
“Cinema Tools is greyed out? What’s greyed out?
[Simon Arnold] “I have spoken to our dev team and it might be down to the fact we are using ffmpeg after shake to add audio to the output as Shake can only do it manually and we need it fully automated.”
What happens if you test a movie before ffmpeg?
Sorry, I am not familiar enough with Shake, but you can’t specify a frame rate? Or is a drop down type of interface? What’s weird is if you conform in CT, then it works which seems to me that somewhere, something is rendering @ 23.98 instead of 23.976. To make it even more confusing, CT says to conform to 23.98, but really it is conforming to 23.976. I think this is a very small and easily fixable problem in the workflow, we just have to find it.
Jeremy
-
Hi Jeremy,
you cannot choose 23.976 only 23.98 in shake. As for Cinema tools the conform button is greyed out so we cannot change the framerate to 23.976 which is what we normally do to fix the framerate and get back the frame we are missing. We have just tested a new workflow not using ffmpeg and using quicktime as the last stage an we still get a problem with FCP giving a performance error and altering the file so it drops the last frame. We did test making an uncompressed 8 bit file instead and all was ok so it seems to be an issue with the LT codec, which is odd.
-
Got ya. If it greyed out that means its already 23.976.
There was talk of other problems with LT. Have you tried regular prores just to see?
What about your audio? 48k 24 bit PCM?
-
No we are just making 48k 16 bit. We are getting somewhere. We have changed the workflow now so we use our in house tool to stitch an uncompressd 23.98 video stream created from shake with the correct audio for the shot. We then use quicktime then to re-export as 23.976 Pro Res LT. These still have the same issue although you can now conform them in CT. Having compared a conformed clip next to the file created from quicktime we have found the problem to lie with how quicktime makes the files and writes the duration in the file header. CT uses a higher integer counter so it gets more accuarate reading of the duration. FCP must use this frame counter, were quickitme itself gets the duration from the video stream length. Why FCP physically alters the original file is still an unknown factor.
-
[Simon Arnold] “Why FCP physically alters the original file is still an unknown factor.”
Have you tried ProRes instead of LT yet? Just curious.
-
Yes it does it on all codecs. It is to do with the framerate integers. If its a rounded frame rate of 24, 30, 25 all is ok but it seems to be an issue with 23.976 only on any codec.
-
Except UC 8 bit was working, right?
Have you tried to just copy and paste the audio in QT Instead of reexporting? Why not add audio in FCP and export a new self contained?
Reply to this Discussion! Login or Sign Up