FORUMS: list search recent posts

Workflow Issues with FCPX Importing Media

COW Forums : Apple Final Cut Pro X

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Alex Johnson
Workflow Issues with FCPX Importing Media
on Jun 17, 2014 at 3:25:19 pm

Hi, I have a question concerning my inability to to choose the option “leave files in place” when attempting to import media into FCPX. I know this has to do with the files being in a card structure, but I wanted to know if there is away to avoid copying files with the workflow my video team is attempting to utilize.

This is ideally the workflow for FCPX collaboration we have in mind:

1. We are shooting media on various camera formats and cards including Canon 5D, Canon C300, Sony XDCAM, and GoPro.

2. We copy the raw media from their cards in their respective card structures (Ex: BPAV, DCIM, CONTENTS) into a shared network drive where we archive all our media and so the media can be accessed by all different editors. Also like to keep the raw media in their card structures so they can be opened by other programs like FCP7, XDCAM Clip Browser, or Canon XF Utility.

3. In FCPX, we import the media into our libraries and events with the option of leaving files in place so we don’t take up unnecessary data space copying footage, and so that editors can easily share the same source media.

However, this option of leaving files in place is not available. I know there are some workarounds. One, we can just copy the files, but we want to avoid that. As mentioned before, we don’t want to take up more space and add multiple copies of a file. Furthermore, when copying files, FCPX creates new names for the files instead of keeping the original name of the file which I feel would case problems down the line if you want look for the source media where those copies came from. Is there a preference to keep the same file name? The second option would be to transcode all the media first into a shared space, and then import into FCPX where I will have the option to ‘leave files in place’ - However, this option negates one of the most valuable features of FCPX- being able to import any media without transcoding in bulk and only worry about transcoding the edit at export.

Are these the only two options if I want to keep the raw footage in the card structure and import into FCPX. Or is there another solution?

On a separate issue that may be related or unrelated, when I have imported media into an event, whether it be copying files or leaving files not in a card structure in place, I notice that in the viewer, the clips momentarily appear normal but then all turn read with a message that says “missing link”. When I right click on the file and say reveal in finder, it is able to find the file in the appropriate folder just fine. But for whatever reason, FCPX can’t link the file. Does anyone know the cause for this?

If anyone has any additional questions about our workflow, please let me know. Thank you for the help. It’s greatly appreciated.

Cheers,

Alex


Return to posts index

Andy Neil
Re: Workflow Issues with FCPX Importing Media
on Jun 17, 2014 at 5:17:31 pm

The C300 and XDCam cameras shoot .mxf files which need to be rewrapped as Quicktime .mov in order to used in FCPX. The 5D and Go Pro both shoot H264 if I'm not mistaken and for those clips you could choose to "leave files in place" if you want.

But for the C300 and XDCam the fact that you have to get them out of .mxf is the reason you can't "leave in place". For a workflow where you want all the editors to have access to clips in a central location, I'd use the "choose folder" option when importing and place all the footage in a central location. This will double your C300 and XDCam footage but you can always delete the card files after you've finished importing (provided you have an archive backup of the cards elsewhere).

This may not be the answer you're looking for, but realistically, you NEED to have at least one copy of your cards that remains untouched (most productions have two). You do NOT want to edit with your only copy of footage in card form. One misplaced read/write and you've lost your media for good. Keeping footage in card form just so you can open it in XF Utility or FCP7 is fine, just don't edit with those card files.

Andy

https://plus.google.com/u/0/107277729326633563425/videos


Return to posts index

Alex Johnson
Re: Workflow Issues with FCPX Importing Media
on Jun 17, 2014 at 8:07:40 pm

Hi Andy,

Thanks so much for the help. Yeah that seems like the workflow I will have to do. Even for 5D and GoPro, I can't leave the files in place because of the DCIM card structure, unless I just save them outside the card structure.

Thanks for the advice about footage in card from and backing it up. We have a pretty good archive system here where everything is back up onto an Edit Share backup system and also physically on blu-rays. What we have been doing when we were using FCP7 is that for 5D, XDCAM, and C300 footage, we would just use Log and Transfer and those camera's FCP plugins to read the cards that were copied onto our media repository on our editshare, and then just capture the footage in ProRes on a Capture Scratch in another shared space. And then for GoPros, 5D that wasn't in card form, or any other files that weren't ProRes, we would just use Compression or MPEG stream clip to transcode those and import them into FCP7. And then we wouldn't worry about the raw footage anymore while editing. Anyways, now as we are slowly beginning to transition to FCPX, I've been trying to figure out the best workflow now...So I had thought that one of the best things about FCPX would be that the middle step of transcoding wouldn't be needed anymore and you could just import any file despite its codec or format directly into FCPX. So not being able to leave the files in place is not ideal, but copying the files will not be a huge issue and just be similar to our older workflow I guess.

But what concerns me now about copying the files is the the naming of the copied files, which FCPX changes. For example, I chose a file to copy and it changed the name from BT0045 to "2013-11-02 06_43_17 (id).mov". Is this a preference issue where I can choose the copy file to retain the original name of the raw clip or is this something I can't change? It's annoying that these copied files won't be named in numerical order or with a common prefix that indicates the project. At least for the 5D and GoPro footage I can simply just copy those mp4s or movs through finder into where all the footage is being saved and then import and 'leave those in place' and then the clips will have the original name.

My last concern is the issue I also mentioned in the previous post about the files going missing directly after importing. Would you happen to know the cause behind that?

Thanks again for all the help.

Cheers,

Alex


Return to posts index


Andy Neil
Re: Workflow Issues with FCPX Importing Media
on Jun 17, 2014 at 9:03:30 pm

[Alex Johnson] "I can't leave the files in place because of the DCIM card structure, unless I just save them outside the card structure."

True, if you're using the DCIM structure, but as you mention below, since the 5D and GoPro shoot H.264, you can pull them out of their card structure and import them as standalone files. Although that could be problematic with spanned clips (if the Go Pro does spanned clips).

[Alex Johnson] "So I had thought that one of the best things about FCPX would be that the middle step of transcoding wouldn't be needed anymore and you could just import any file despite its codec or format directly into FCPX. So not being able to leave the files in place is not ideal, but copying the files will not be a huge issue and just be similar to our older workflow I guess."

X can handle most codecs, but formats are still constrained somewhat. Your FCPX workflow should be similar to your FCP7 workflow except that the files will transcode in the background while you work.

[Alex Johnson] "But what concerns me now about copying the files is the the naming of the copied files, which FCPX changes. For example, I chose a file to copy and it changed the name from BT0045 to "2013-11-02 06_43_17 (id).mov". Is this a preference issue where I can choose the copy file to retain the original name of the raw clip or is this something I can't change? "

Ok, so this how it works. FCPX gives a unique file name to imported footage. The "2013-11-02 06_43_17 (id).mov" you mention. The file name on the card is maintained in metadata. Inside FCPX, you can create a custom name structure that you can apply to your imported clips to satisfy whatever format you use at your facility. This includes renaming the clips *inside* FCPX with the camera file name. It's accomplished in the inspector. There's a dropdown at the bottom that allows you to set up your custom name.

[Alex Johnson] "My last concern is the issue I also mentioned in the previous post about the files going missing directly after importing. Would you happen to know the cause behind that?"

Regarding your missing files problem, I can only speculate. This is my best guess. When you import clips from a camera source (even a copied structure), FCPX "sees" that source differently than it does regular files. Essentially, the camera has to be "mounted" in order for FCPX to see the clips. If you import clips from a camera and then eject the camera source before the transcoding has finished, X will no longer be able to see the clips and all that imported media will go offline. This can be a gotcha especially if you imported a lot of clips and they seem to come in instantly so then you quit FCPX. When you restart, all those clips minus the ones which had time to transcode, will be offline. All you have to do in those circumstances is go into your import dialogue, re-mount the camera sources, exit the dialogue, and go up to File / Import / Re-import from Camera. FCPX will continue transcoding (you can see the progress in that little wheel in the center by the TC). Just wait for it to finish transcoding before you shut X down.

Hope this helps.

Andy

https://plus.google.com/u/0/107277729326633563425/videos


Return to posts index

Alex Johnson
Re: Workflow Issues with FCPX Importing Media
on Jun 18, 2014 at 1:32:13 pm

Hi Andy,

Thank you very much for the last post. This was extremely helpful and it seems to have answered the questions I was looking for. I'm going to try this workflow now and all the tips that you provided and hopefully everything goes smoothly now.

It seems I was confused about the limitations of card structure and XMF files. I thought that FCPX could directly bring in those xmf files and then transcode only the small clips of video I end up using upon export instead of copying the entire file. But thanks for clarifying that and the need to rewrap those xmf files. And the ability to change the naming of the clips is a huge sigh of relief.

Thanks again for all the help and I will let you know if I come across any other issues.

Cheers,

Alex


Return to posts index

Dave Pickell
Re: Workflow Issues with FCPX Importing Media
on Oct 5, 2014 at 3:13:53 am

Similar question. Fcp x. My firewire camera shows up in the import window with Camera in record mode, with no mini dv tape. Camera's content appears in import window, with 'camera not controllable' showing in top left corner. Hit blue import button, time begins to tick up. All looks normal except clip is not found when i return to the main window.

Same thing in imovie. Strange. Anyone else? I do interviews and prefer to stream direct, not rec. to tape then import (which works, b.t.w.)

As a test, used the facetime camera the same way...all normal.

Cameras canon zr 20 and zr 800. Host computer runs mavericks.

Dave


Return to posts index


Jeff Kirkland
Re: Workflow Issues with FCPX Importing Media
on Jun 17, 2014 at 8:40:50 pm
Last Edited By Jeff Kirkland on Jun 17, 2014 at 8:43:01 pm

As Andy says, there are some codecs that have to be rewrapped to use. I don't think I've ever come across anyone else wanting to work directly from the initial card structure in any NLE.

Is there a particular reason for having to do it that way? Storage is cheap and the risk of losing your media seems way too high

My personal workflow is to clone the original media to an archive drive then copy / rewrap / convert the media from the clone to shared storage. That way I have control over the folder structure, file naming, etc. That's the minimum number of copies I'd feel comfortable keeping as far as having backups is concerned.

Jeff Kirkland | Video Producer | Southern Creative Media | Melbourne Australia
http://www.southerncreative.com.au | G+: http://gplus.to/jeffkirkland | Twitter: @jeffkirkland


Return to posts index

Alex Johnson
Re: Workflow Issues with FCPX Importing Media
on Jun 18, 2014 at 1:42:36 pm

Hi Jeff,

Thanks for the reply. It seems I was confused about the capabilities of FCPX and limitations of card structures and I thought FCPX could directly work from those XMF files and then transcode only the bits I end up using upon export rather than transcoding the entire clips beforehand like how we did with FCP7.

But now I seem to understand the workflow based on the capabilities.

Thanks for the help,

Alex


Return to posts index

Bill Davis
Re: Workflow Issues with FCPX Importing Media
on Jun 19, 2014 at 10:04:19 pm

[Jeff Kirkland] "As Andy says, there are some codecs that have to be rewrapped to use. I don't think I've ever come across anyone else wanting to work directly from the initial card structure in any NLE.

Is there a particular reason for having to do it that way? "


ABSOLUTELY.

It's all bout metadata. The reason you want to maintain the card structure - NOT just at the DCIM folder level but at the WHOLE DRIVE FINDER level - is so that X can "see" the card loading as if it's a fully functioning drive with it's embedded drive metadata intact. And DCIM folders are NOT drives. They are folders.

Divorcing the folders from the virtual drive is precisely what in some cases can break the metadata string near the top of the flow.

This is also why we use sparse disk bundles. It's a DRIVE clone. Not a folder clone. It contains ALL the top down metadata.

And Jeff, preserving the camera metadata at the card root level may or may not be important to you now since I don't know your workflow, but I do suspect that as metadata becomes ever more critical a driver od efficiency - breaking these links has bigger and bigger implications.

With a functioning "card clone" I can look upstream and see all sorts of useful metadata. Who owned the camera, the size of the storage media used, what the lens settings were, etc. etc.

Its up to each of us to determine how much or how little of the metadata stream we want to understand and interact with. But to essentially circumvent the process by willfully cutting off the upstream info flow is something that strikes me as generally poor practices. I may not ever look at the upstream metadata. But what about the next user downstream? The colorist or perhaps a secondary editor who notices that there are, say, a bunch of DSLR shots that might well have embedded lens metadata and would prefer to allow automatic lens distortion correction for those stills or video files - well they SHOULD have the information intact so that they can best do their work.

Many of us have said it here before, FCP X is BUILT on metadata management.

And because one editor may or may not elect to use said metadata fully, just isn't a good reason in my view to dumb down the incoming files at import.

Again, Apple built sparse disk bundling DIRECTLY into X via the Create Archive function on the import screen. That has to be an indication that they expected users to need and want a system that preserves upstream metadata at the "card clone" level as a matter of course.

So I can't think of any good reason for any workflow that circumvents that reality.

Thats how I think of it anyway.

Know someone who teaches video editing in elementary school, high school or college? Tell them to check out http://www.StartEditingNow.com - video editing curriculum complete with licensed practice content.


Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2017 CreativeCOW.net All Rights Reserved
[TOP]