Controlling when FCP copies media into the library
I'm confused about when FCP copies original media into the library. I was importing a bunch of media into a new library and made sure that I'd checked the "Leave files in place" option. I'm also choosing the "Create proxy media" option with the idea that I'll copy the entire library file onto my laptop for editing.
However, the library file ended up being huge and when I open it via "Show Package Contents", I see an "Original Media" folder. Some of the items are alias' to the original media but other files are original files. It seems to be dependent on the original media format.
Can someone enlighten me?
I figured out the problem. I had three folders of video clips. One of them was a copy of the entire memory card from the camera. That seems to confuse FCP: it thinks that the folder *is* a memory card and won't permit the "Leave files in place" option to be used. Once I deleted all the non-video files (e.g., MEDIAPRO.XML, STATUS.BIN) and just left the video, FCP imported the video fine, without copying the originals.
[Fergus Hammond] "That seems to confuse FCP: it thinks that the folder *is* a memory card and won't permit the "Leave files in place" option to be used."Actually, that is not confusion. That is the expected behavior and an extremely useful feature. It is a safeguard to make sure that you are not editing the only copy of the video that you have.
A common workflow is to use the Create Archive button in the Import window to make an exact copy of your "real" memory card on disk. FCP X will never let you edit these files in place because they represent the original copy. Then when you begin your project, you import those into your Library which becomes your 2nd copy. This way the archive of the memory card is a backup in case files get deleted or corrupt. If you want to keep the Library small by placing the original media somewhere else, I would copy these files to the other location but I would never delete the memory card metadata. The metadata that you just deleted is very important information like how to stitch long takes together when they exceed the capacity of the cards file system and break up into multiple files. For some formats, FCP X will not import them unless they are still in the original memory card location. So always have a copy of the complete memory card handy just in case. If for nothing else, as a backup.
What? You're suggesting that I'm the one that's confused?! 😉
Yes, you're right: confused is the wrong term for sure. Good point about keeping the metadata around. Do you know if that's important for consumer-level video cameras?
[Fergus Hammond] "Good point about keeping the metadata around. Do you know if that's important for consumer-level video cameras?"Absolutely. The problem is that most memory cards use the FAT32 filesystem which is limited to 4GB as the largest file size. Depending on the format that you are shooting, this could be as little as 5 or 10 minutes of video. Consumers are more likely to be recording a school play or other event where they are recording for a long time. When these broken up files are just dropped onto a timeline without any stitching, there is often video frames or audio missing. The metadata on the cards give instruction on where one file leaves off and the other begins allowing for a seamless concatenation of the two. It also provides for files that match the recorded takes that the consumer made. i.e., if I recorded a 30 minute ceremony, I expect to see one file when, in fact, there may be 4 files on the camera card. Having the metadata to stitch these back together during import and present one file to the consumer is more preferable.
This feature is squarely aimed at consumers who would happily edit the only copy of the video that they have right from the camera card if you let them because consumers usually don't think about backups and "safe copies". FCP X tries to keep them from forming these bad habits.
[John Rofrano] "...most memory cards use the FAT32 filesystem which is limited to 4GB as the largest file size. Depending on the format that you are shooting, this could be as little as 5 or 10 minutes of video..."
BTW, all SDXC cards 64GB and larger are automatically formatted exFAT by the camera itself -- it's part of the SDXC spec. With these there is no file size limit. This is increasingly the standard, especially as 4k becomes dominant. Almost all the cards in my doc team are 64GB or larger, whether in a camera, drone, GoPro, etc.
[John Rofrano] "..Consumers are more likely to be recording a school play or other event where they are recording for a long time. When these broken up files are just dropped onto a timeline without any stitching, there is often video frames or audio missing. The metadata on the cards give instruction on where one file leaves off and the other begins allowing for a seamless concatenation of the two."
For this very reason, the way FCPX handles "leave files in place" often creates a problem. It appears programmatically possible to distinguish between media on an SD-type card vs that same folder tree on a hard drive. You can even do it from terminal. Apple could do this within FCPX and only disallow in-place imports from actual SD-type cards, not from hard drive copies of the card. They could also provide an override or warning dialog which allows the user to make the decision. Or they could do both. They do neither, which encourages users to copy bare video files outside the folder tree and do in-place import from there. This in turn creates the possibility of missing metadata -- which is missing because users were forced to copy the video files out of the tree to get in-place import to work. Basically, FCPX behavior is encouraging users to do the wrong thing.
It is especially bad for AVCHD files which seems to cause I/O performance problems if imported in place from outside the original folder tree. It appears FCPX may be dynamically re-wrapping each AVCHD file upon each reference -- it performs a huge number of small I/Os when using the Event Browser in filmstrip mode. It even happens if only a tiny % of the media in the library is AVCHD imported in place. This behavior doesn't happen for XAVC-S or other files I've tested. However as currently designed FCPX doesn't handle AVCHD content properly for the in-place import case, which can "poison" the performance of a large library. Until this I/O situation is fixed, in-place import of AVCHD material probably shouldn't be allowed -- whether inside or outside the original tree structure. It works fine on Premiere.
Copying media files outside the folder tree is not generally a good practice, even when it seems to *currently* cause no problems. You never know when missing metadata will come back to bite you, but FCPX as currently designed actually encourages this poor practice. These behaviors are not documented by Apple, and I haven't seem them described in any FCPX tutorial or book, and I have most of them. It's no wonder users get confused.