Forum Replies Created

Page 4 of 6
  • Mathew Farrell

    February 23, 2017 at 8:55 pm in reply to: keywording strategy

    Thanks Craig, that’s another very appealing workflow. The benefit of favourites, as you say, is it’s SOOOO much simpler to remove the favourites tag. The obvious downside is that one can no longer use the ‘favourite’ as a rating. Personally, I haven’t tagged many favourites yet in this project, but my intent is to be tagging some in these early passes.
    A workaround that just occurred to me is to use favourites as you suggest, for my ‘no keywords manually added’ tag, and actually add a keyword called ‘favourite’ as a positive rating.
    That ‘favourite’ keyword could remain forever, or, when the logging has been completed (i.e. no clips are tagged ‘favourite’ any longer), select all clips with the keyword ‘favourite’, tag them as favourites then kill the keyword.
    The Bob and Mat No_Meta family of keywords, by contrast, has more control (e.g. No_Location versus No_ShotType), but is a bit slower to manage. Hmmm.

    As yet another alternative, is there a good way to replicate my actual directory structure within FCPX? If so, then I could trash all the automated directory structure keywords and would be free to use the existing Keywords: Do Not Exist filter as Apple intended. Even if this is possible, Bob and Craig’s solutions are great tricks in the bag that can be used in parallel for metadata filtering and control within the confines of the toolset.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 23, 2017 at 8:45 pm in reply to: FCPX horrendously slow to import clips or XML

    Thanks again Joe.

    Yup, that was Larry Jordan. We get similar advice for Lightroom libraries, although for obvious reasons the file count is a lot higher (quarter or half a million frames, if I remember correctly?) I suspect the database architecture works quite differently. In fact, if video playback wasn’t horrendous, I’d use Lightroom for all my media management, then kick out selections to Premy, Resolve or FCPX if it grabs me.

    And to be clear, I was ‘easily’ able to relink to my rewrappered files, but I could only link one at a time – FCPX was clearly content that it was “the same”, but it seems to me it couldn’t automatically line them up due to the file extension.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 23, 2017 at 4:13 am in reply to: keywording strategy

    Yup.

    I’ve already got this implemented now. FWIW, I added “AA ” before all of my utility keywords so they appear at the start of the keyword string. This makes it easy to delete them when no longer required.

    “ZZ ” would have worked equally.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 23, 2017 at 1:33 am in reply to: keywording strategy

    You do yourself a discredit sir – that is a most elegant solution given that the software doesn’t work in the way I want.

    By way of homage, I’ll use the exact keyword “meta_add”.

    If I took your logic further, I could add several layers such as “no_shot_type”, which I later remove when I’ve populated shot types, which I wouldn’t bother to do on my first pass. “No_Location”, etc.

    I love it.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 22, 2017 at 10:56 pm in reply to: Push keywords to clips in Resolve?

    Oh I agree – changing the name of a file after it’s in your storage system is bad form.

    Rather, I’m trying the push the keywords into the file’s metadata. I haven’t looked a Better File Renamer (yet. Will check it out, cheers) – any idea if it can write metadata as well?

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 22, 2017 at 10:36 pm in reply to: FCPX horrendously slow to import clips or XML

    Thanks for the thoughts guys.

    Joe, I reckon you nailed it – Rewrapped all my MTS files and replaced them. Things are WAY smoother now. I think you’re on the money when you say FCPX tries to rewrap them on the fly.
    It seems odd to me that something like FCPX gets it knickers in a knot over the file wrapper, but can handle the codec passably. I would have though two or three lines of code would bypass whatever the wrapper is doing, but this is completely conjecture on my part – I don’t know how that side of the formats work.

    After rewrapping, the filenames remained the same, but the extension (.MTS to .MOV) was changed. I replaced the MTS files with the MOV files in the original media locations, hoping the break the links and reconnect to my rewrapped footage. I could select a single clip at a time and reconnect them no worries, but I couldn’t find any way to batch the relinking, presumably because FCPX couldn’t find and exact filename match.
    I would have preferred to relink, as I’d already done some keywording and media management, but in the end it proved easier to trash those clips from the library and just import the rewrapped ones afresh. As they were in the same directory structure, they slotted into that part of my media management fine.

    As a bonus question, does anyone know a batchable way to replace files with a different format or codec, like I was trying to do?

    In researching this problem, I came across advice to keep libraries under ~1000-2000 clips. This makes sense. The workaround for a “project” like this (7700 clips) is to split the clips over several libraries (no need to move or dupe the source files), and build out a timeline from several libraries. I might investigate splitting this library up down the line, but so far things a slow, but not the point of hampering my keywording mission.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 21, 2017 at 10:06 pm in reply to: FCPX horrendously slow to import clips or XML

    Much obliged Joe. Thank you for taking the time to make the MTS issue clear.

    Downloading Editready as we speak.

    It’s pretty amazing that the AVCHD issues aren’t documents and made clear by Apple – the difference between In Place and In Library are huge, and can really mess up a workflow fast if it’s not transparent.

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 19, 2017 at 9:56 am in reply to: FCPX horrendously slow to import clips or XML

    These are bare .MTS files extracted from the AVCHD wrapper, else you wouldn’t have the “leave files in place” option. The performance issues you describe are a known issue. MTS files should never be removed from the AVCHD wrapper, and if you do, FCPX does not handle it well.

    HI Joe.
    Removing from the wrapper is one thing, but I’m talking about leaving media on its source drive and not duplicating it all into the library file. Surely that’s a global option, and nothing to do with the file format/codec. Are you talking about something different?

    Cheers

    Mathew Farrell
    flowstate.com.au

  • Mathew Farrell

    February 19, 2017 at 9:50 am in reply to: FCPX horrendously slow to import clips or XML

    Thank you for the thoughts and ideas guys. I like your Marathon analogy, Bill. Fair point. I’m disappointed that FCPX is struggling so badly with this, whereas Resolve hasn’t batted an eye. Just because I’m disappointed doesn’t mean I’m naive though – I’m well aware that different code has favoured and feared codecs, and it’s also completely possible that some simple setup options would change matters.

    The MTS files are unwrapped. It’s how they arrived. I’ll look into rewrapping. Good tip.
    I’m not a fan of them, but they’re alas a fact of life with this and many other projects these days. The land of a thousand codecs…

    I’d have to check on the media drive’s speed. It’s connected via USB3.0

    RE the Resolve to FCPX question – no cutting has been done. I spent a day reviewing footage and logging keywords in Resolve before going “Urgh, maybe this is the project to investigate FCPX on” because it needs a lot of media management. Resolve is way better than Premiere on this front, FCPX is supposed to be better still. I haven’t got that far though…

    Again, I appreciate your analogy Bill, but what part about the project or workflow is unfit or poorly done? I can’t see too many errors one could make importing an XML into a blank project. Sure, there’s plenty to cock up later, but I haven’t even been granted that chance yet.

    Can anyone tell me what FCPX is doing when it is Processing Files For Import? That sounds mighty like making proxies or renders to me.

    I don’t mean to sound adversarial at all guys, I really do appreciate the help. Just trying to wrap my head around the unworkable performance.

    Mathew Farrell
    flowstate.com.au

  • Hi Eline.

    As a thought, there’s no reason you couldn’t use Lightroom as your database, just like you do for stills. My legacy is in stills and Lightroom, and I often use the same workflow for video projects. Once you’ve generated selects you want in your video project, select them out, and kick them out to your NLE of choice, either soft (my recommendation), or by copying them out to a different location (I don’t like this, but you may have your reasons).
    The only real downside to this workflow in my book is that LR is a dog for video preview playback.

    Mathew Farrell
    flowstate.com.au

Page 4 of 6

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