Hi. Im importing big amounts of media from a Sony FS7 for a documentary. All the shooting was done in 4k. I import the mxf files from the original cards estructure, wich are already in a hard drive, and let fcpx copy to the selected external location for the library and rewrap the media to .mov. Usual workflow, no problem.
But I discover some strange behavior. In some of the cards, the camera operator had recorded some kind of simultaneous proxy files in HD. Those files are .mp4 (In some cards this files are HD and 4k in others) and are located inside the same XDROOT/Clip folder than the mxf 4k files. There is also a .xmp file for each clip. This .xmp file is only present whenever there is a mp4 file.
The thing is that when I import the files from this cards, FCPX copies the mxf file to the original media folder, but doesn't rewrap the files to .mov. It just copies the mxf file. The same happens if I import the mp4 hd files. It doesn't rewrap the files and copy those file as mp4. However, I did a little test. If I manually move the mp4 and xmp files out of the card folders, FCPX will copy and rewrap the mxf to mov. Last, but also strange, the date metadata for the mxf and mp4s are completely different. I still don't know if this strange situation will become a problem down the road, but I am curious to know if anyone here have experienced something similar, or could share some ideas on how to work with this situation.
rdgz.emiliano wrote: ...The thing is that when I import the files from this cards, FCPX copies the mxf file to the original media folder, but doesn't rewrap the files to .mov. It just copies the mxf file. The same happens if I import the mp4 hd files. It doesn't rewrap the files and copy those file as mp4. However, I did a little test. If I manually move the mp4 and xmp files out of the card folders, FCPX will copy and rewrap the mxf to mov....
We don't have the FS7 and on our FS5 we only shoot ProRes RAW. However I have a few FS7 test clips. On FCPX 10.4.10 I confirm the same thing you see. I don't know why it does that or what the implications are.
In general for this type of tree-oriented material, I recommend externally re-wrapping it with EditReady2, renaming the files as needed for your organizational scheme (try to have totally unique camera filenames), then import using "leave files in place". EditReady2 folds in all required metadata to a single .mov file and this also enables proper "in place" import. www.divergentmedia.com/editready
The FS7 4k Long GOP material I have is quite sluggish to edit (on a Vega 64 10-core iMac Pro), so proxies might be required for smooth performance. The FS7 All-Intra material is a lot smoother.
Re the in-camera proxies, FCPX currently has no support for that, so I'd be tempted to just discard those. In theory under specific conditions you can import the camera-generated proxies, edit, then relink to the full-res media. I would only attempt that on media files externally re-wrapped by EditReady2. Even in that case it should be tested extensively before committing major work. FCPX relink constraints:
- Files must have the same audio config (same number of channels), but sample rate can differ.
- Pixel aspect ratio should be the same, but it may relink even if different. This could result in a squeezed or stretched frame.
- Clip duration must be the same or longer. If longer, then later relinking to the original clip won't work because the new target will then be shorter.
- File suffix must be the same.
- Codec need not be the same, e.g. you can create 720p H264 proxies and relink to those as original media.
- After relinking to a different resolution file, the viewer may show a window-boxed screen. This is typically a cache issue and can sometimes be resolved by deleting the FCPX cache, which is either stored in the library or outside as defined by the library inspector. The cache is a file bundle named LibraryName.fcpcache.
If relink fails it is often beneficial to try and relink a single file. In that case (but not the multi-file case), FCPX will state why the relink failed.
I finally opened one of the .xmp files on textedit and found that all those files were generated in Adobe Media Encoder. Clearly someone had been messing around with the files, trying to do proxies or something like that. But its pretty clear now that those files were not generated in camera. Solution, take the mp4 and amp files out of the cards folders. All going well now.
I never really thought that could be the case, because when I saw the mp4 I asked the guy who gave me the media and he told that may be the DP was doing dual recording to have some small files to share easily.
Now, what seems strange is that you saw the same behavior with your FS7 test clips.
rdgz.emiliano wrote: ...I finally opened one of the .xmp files on textedit and found that all those files were generated in Adobe Media Encoder. Clearly someone had been messing around with the files,..I never really thought that could be the case, because when I saw the mp4 I asked the guy who gave me the media and he told that may be the DP was doing dual recording to have some small files to share easily...Now, what seems strange is that you saw the same behavior with your FS7 test clips.
In general my recommendation is offload the folder tree "as is" from the card to disk, then externally rewrap with EditReady2, then import with "leave files in place". Rewrap is super-fast because it doesn't transcode, and doing it externally enables a "lean library" where media and cache are external. To have external cache you must define that folder in FCPX with the library inspector, Storage Locations>Modify Settings>Cache. With a small library you can quickly duplicate it periodically in Finder by right click>Duplicate. That provides an easy rollback method separate from the built-in FCPX library backups in /Movies/Final Cut Backups.
If the other guy put something in the folder tree that's probably not a good idea. If used that should remain an identical copy of the card. However once rewrapped with EditReady you can probably delete the original tree.
To create smaller files to distribute remotely, now that FCPX has variable-size H264 proxies, that's the best way. For 4k originals, 25% H264 proxies are still usable for editing and a tiny fraction of the original size. They can be uploaded even using slow internet.
I don't know why the MXF wasn't rewrapped. I checked FCPX 10.4.6 and it also has that behavior, so it's not a recent change. I checked the original and imported files with a binary compare tool and the files are identical. FCPX did nothing to the file.
See the Ripple Training video at 16:18 about creating a proxy-only library using the new 10.4.9 features: