Forum Replies Created

Page 4 of 15
  • Sam Lee

    May 18, 2017 at 6:41 pm in reply to: Can I reverse telecine a scene I have already edited?

    Use Compressor to reverse telecine the 29.97 fps footage back to 23.976. Then take that to your 23.976 edit sequence. This does not always work because if the telecine 29.97 fps clip (fr 23.976 with full 3:2 pull is not done correctly), it will not work.

  • Sam Lee

    May 14, 2017 at 9:23 pm in reply to: ShotPut Pro MD5 Checksum remarkably slow

    Shot Put Pro for Mac & Windows are unfortunately written separately by different people. Both platforms have difference variations. If you look closely, the feature & functionality between the two are actually different. Windows has always behind in favor of the Mac. Any chance you’re using Windows? Check their feature list for xxHash 64 w/ Windows. I don’t use Windows for offloading so don’t know whether the latest ver has the same features as the Mac.

    My Mac versions (5&6) all have xxHash-64 as the default checksum.

  • exFAT (free). The only big gripe about exFAT is the severely limited volume name (11-char max). But other than that, it can handle large file size (>4 Gb) easily.

    Test it thoroughly. Not sure if it can handle larger projects. So far it’s functioning fine on small-medium scale project. That’s not a lot of multicam complexities, layers of audio and so forth.

  • Sam Lee

    May 12, 2017 at 12:30 am in reply to: ShotPut Pro MD5 Checksum remarkably slow

    I use Shot Put Pro 5 and 6 often. They have the new xxHash-64 checksum. That’s now the new default standard. It’s much faster than MD5. Give it a try.

  • If you want the broadest compatibility with other apps and repurposing the content a decade later, keep the file names <64 chars.

    Any Adobe apps – especially AE CC will have a hard time with anything more than 64 chars. The directory name on top of file name will make it not able to relink. It appears that the dir name is contributing to the file limit. So if I have a 64 chars dir name + 32 chars file name (96 chars total), it will not work. But if I shorten both around 32 chars (64 total), it’s fine on CS5->CC2017. Happened to me several times. I’ll keep it within 32-64 max chars for file names.

  • Sam Lee

    May 4, 2017 at 4:23 pm in reply to: Migrating FCPx 10.0.7 to 10.3.3

    Sugar FX Subtitles are still not 100% functional. They upgraded to 4 recently. Installed 4 w/ 10.3.3 and nothing but problems. I don’t have the spare time to figure out why it’s not outputting properly. It could be I’m working on 10.3.2 and updated to 10.3.3 while still using Subtitles 3.0 instead of 4. So I recreate it from scratch with Subtitles 3.01 on10.3.2 and it worked like it should.

    Latest version of Magic Bullet Looks is working fine on 10.3.3 and the previous 10.3.2.

    I’m sticking to 10.3.2 and couldn’t be happier overall. Will wait for 10.3.4 though. I’m sure Apple will iron out the issues found on 10.3.3.

  • Sam Lee

    May 4, 2017 at 12:52 pm in reply to: Migrating FCPx 10.0.7 to 10.3.3

    Jeff,

    10.3.3 is OK as long as every system is upgraded to 10.3.3. I made a mistake of opening the library mix and matching 10.3.2, 10.3 on other Macs.

    The most recent issue is that a 8 multicam edit was flawlessly edited and exported on 10.3.3 . Little did I know when I use the 10.3.2 (because of plug in compatibility needs) and then reopened in 10.3.3, it started to act up. Apple should prevent the library from being opened by earlier version such as 10.3 to 10.3.2. I assume that it’s 100% compatible.

    I’m still dependent on 10.3.2 because of the plug ins used on edits made before Apr 13, 2017. I didn’t understand why until late yesterday when I saws the reoccuring pattern with several more libraries. Performing XML export and import didn’t help. What saved the day was the auto save feature on 10.3.3. I was able to use that and open in 10.3.2 and all of the multicam edits didn’t turn black. This itself would saved me 3 days of rework if I used this method instead of starting it all over again in 10.3.3.

    The ability to simply recopy 10.3.2, Compressor 4.3.1 and Motion from my internal system disk image backup helped tremendously as well. Otherwise this will take half a day or more to reinstall the OS and all of the apps from scratch.

  • Sam Lee

    May 3, 2017 at 11:00 pm in reply to: Migrating FCPx 10.0.7 to 10.3.3

    10.3.3 is quite buggy in real world production scenarios. Large project and multicam would all turn black. When I downgraded back to 10.3.2, it’s error free. This happened on 4 different libraries. It’s very hard for it to be an isolated problem. What a relief!

    I’d wait for 10.3.4 to come out or use 10.3.2. Use 10.3.3 at your own risk.

  • It worked so far (deleted all FCP 10.3.3, Compressor, Motion) and recopied the 10.3.2 along w/ anything before Apr. 13, 2017 update. No more black multi angle clips and other odd bugs. Everything is working as it should. Thanks goodness. Close call on this. Spent 2 weeks cutting all the cam angles and audio tracks.

    Lesson learned here is that you can never be too complacent. Arguably 10.3.3 is FCP X’s buggiest release to date. I would not recommend for anybody else to update when in a real production environment. It’ll be a very costly upgrade because of the bugs caused.

  • I’d bulk select all of the clips and name it as “B” cam (or whatever name you want) under the info tab Camera Name metadata field. It should all line up nicely in a single angle vs 17 different angles.

    Recently w/ 10.3.3, it would behave very odd even specifically adding Camera Name to “B”. It would add another 3rd angle somewhere at the bottom. But no where beyond 3 at max.

    I edit lots of multicam clips (12-16 cams) and FCP 10.3.3 has gotten more buggier than 10.3.

Page 4 of 15

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy