Using Finder Tags as Keywords and Using OS X Finder as a Digital Asset Manager.

As we wind up to WWDC 2014 and the dawn of OS X 10.10, I can’t shake the idea of using Tags as they were initially introduced in OS X 10.9 as a way to create a keyword library of FCP X Assets at the Finder level.

I know the “proper” thing to do if you want a D.A.M. or M.A.M–which ever term you prefer– is to buy one of the known recommended 3rd party software solutions that aim to solve the hole that Final Cut Server left behind. But in our post-production workflow, we only got so far as beta testing FCS and never got around to implement it. (thankfully). Why? Because we just didn’t have a natural motivation to want to use it. We just keep using Finder and Spotlight which did about 90% of what we needed.

Final Cut Server, and by my research, all the current DAM/MAM software solutions are too expensive, too complex, and to be honest, we only want one feature; Spotlight searching of off-lined (or shelved) media. Everything else current DAM/MAM software does is kind “meh” for what we need on a daily basis. We’re already on an Xsan network, so accessing media from any FCP X workstation is not a problem. We don't need proxys and etc... etc...

To this point we’ve been renaming our footage clips to contain the description of what they are. So a spotlight search usually give us exactly what we need, provided we’ve not archived said footage off the Xsan already. But our 43TB of combined Xsan storage is far too small to keep an online stock footage library of our past project media, So I must find a solution. But I simply don’t like anything I’ve seen.

Here I am, back to square one, even after having a Twitter debate with the good Phillips Hodgetts a few months ago about whether or not Apple will develop their own proper “new” solution for Final Cut Server, and I still can’t help but to think that Apple doesn’t need a proper DAM software solution anymore because OS X *is* that solution. It's called OS X Finder. Apple just needs to make tags readable and integrate-able with FCP X, and some smart developer somewhere needs to make a simple app that culls and logs all your OS X Tags (keywords) as some kind of offline indexing catalog that tells you which volume that tagged item which is now offline was last mounted from. Then you can go to the shelf, grab the needed Volume (RAID1 of course) and pop it into your Thunderbolt drive dock, import the needed footage to your FCP X Library and off you go… Just like pulling from a BETA tape of not quite a decade ago.

I hope OS X 10.10 and future FCP X versions bring even more robust support for Finder level Tags, and makes this idea even more possible.

I'm also hoping more Spotlight metadata gets incorporated into FCPX. As for doing Finder searches, be aware you can do searches for just about any metadata an FCPX file is exported with. Such as copyright. Did you know you can search for Copyright metadata in Spotlight? RGPphotog, sounds like you guys know much about Spotlight, but for those that don't.

When doing a Spotlight search in a Finder window, click the Kind menu and go down to Other. There are TONS of things you can search for. Plus, when you get a complex search done, click the Save button at the top left to add it to your Finder window sidebar, or as a clickable icon to the Desktop or elsewhere.

Very cool stuff I hope gets refined and integrated better into all the pro apps.

RGPphotog wrote: ...To this point we’ve been renaming our footage clips to contain the description of what they are. So a spotlight search usually give us exactly what we need, provided we’ve not archived said footage off the Xsan already. But our 43TB of combined Xsan storage is far too small to keep an online stock footage library of our past project media, So I must find a solution. But I simply don’t like anything I’ve seen.....OS X Finder. Apple just needs to make tags readable and integrate-able with FCP X, and some smart developer somewhere needs to make a simple app that culls and logs all your OS X Tags (keywords) as some kind of offline indexing catalog that tells you which volume that tagged item which is now offline was last mounted from....

I'm in the same situation and totally agree with you. Besides renaming media files, you can add additional metadata via the "Get Info" comments field. This could include camera type, location, scene/take, etc. There are various 3rd party apps to expedite this (Quicksilver, etc). That user-added metadata is Spotlight searchable. However -- that goes with the file, and once the file is off line you can't search the metadata. Even if on line, there is no integration between Finder-level tags/metadata and FCP X.

As you said, it would be nice to have additional integration between FCP X and OS X tags/metadata, plus offline searching of those.

RGP
Have you checked out Final Cut Library Manager (now 2)? I haven't used it myself yet, but think I'll spring the $12.00 for it. Seems to do everything you want including being able to search FCP notes. Catalogs offline drives and list them making it easy to find clips. Seems like a nice program and very reasonable $$.
Check out this recent posting here on FCP.co and see if it works for you…
www.fcp.co/final-cut-pro/news/1424-final...ed-with-new-features

If you use tags all the time, your tag list gets really long, and also you need to be very consistent on what you name them, and what files you attach to each tags. Then you still need to install the drive(s) to be able to review the clips. Being able to sort via "notes" contained in clips should be a very powerful organizer.

Hope this helps, Greg

Some comments and “talking-out-loud” brainstorming:

I’ve been looking at Library Manger, and it looks like an excellent tool and is on my short-radar to buy. However I don’t think it solves the specific problem that OS X Tags might aid with. And that’s searching for individual clips as a in-house stock footage library kind of way. And this in-house stock footage library must live offline.

I could, and probably will build a standard run of the mill File Server using one of our old ’07 Mac Pros that we can ingest from, but even then it can only be so big (internally) and our stock-footage library would exceed the storage capabilities. I could spend (read: convince the boss to spend) upwards of $4k on a Synology type solution, but then I still need a proper backup, and thats getting a bit beyond our budget for such a thing. (As it is, I’m looking at a Synology solution to be a Time Machine backup for our Xsan volumes since we don’t have any kind of backup for our Xsan as of now. Sure we have the master footage backed up, but not the working projects. YIKES!)

Our workflow is still based on 10.0.0.9 as half our workstations are still on Mountain Lion. But when we do upgrade, it would be the ideal time to migrate to a new workflow. Here’s my rough outline as of now, which has some holes and needs to be refined.


– Archive captured footage as Camera Archives to bare OEM HDDs (RAID 1)
– With a retired Mac Pro, Create a Camera Archive NAS volume for our most recent footage (less then 3yrs old)
– Ingest/Copy all footage into FCP X 10.1 Libraries.
– Archive/Offline Libraries (if we need to keep them) to bare OEM HDDs (RAID 1)



The problems with this workflow come down to the Camera Archives, and that FCP X doesn’t rename the source clips in Finder. (it should, shouldn’t it? Why doesn’t it?)

If I want to find a clip “kids in classroom” then i would use that term to search for them. With Camera archives you can’t rename individual clips contained inside. You’d have to keyword each archive, or folder of archives, which is where OS X Tags would come in. Keywords would be “kids” and “Classroom”. Then mount the Camera Archive to find the needle in the haystack that actually matches what you want.

I guess you could do the same sort of thing with the comments section of Library Manager software. that might work.

Also, since I’m brainstorming, I could create a “Stock Footage” Library A’La Adobe Lightroom but with FCP X (which is kinda what I'd want to begin with) but that could likely get very unwieldy in size and only one person/editor/workstation could access it at a time. (still this is a tempting idea, maybe even multiple “stock footage” libraries based on type of footage contained.)

Another problem with Camera Archives is that you can’t really go back and remove bad or unneeded clips from the archive. Ok, you can but it seems as though you really shouldn’t be doing so…? (This could be possible with a FCP X “stock footage” library.)

I should probably note that when I say "in-house stock footage library" I mean this is footage that was previously shot for a specific project, but could be used and reused for other future, completely unrelated projects. The way we do this now, is that all our footage gets transcoded to "stores" which are just finder level folders which FCP X projects alias to as a means to save space.

This sounds like a great idea in theory, until we have to archive footage to make room, which breaks our project links. It's also a bit messy to keep track of in practice. To be honest we've not done a very good job of organization as a department. I see Libraries as a way to help force us to stay more organized, if I can solve this stock footage problem. I can't see us as a department going back to our projects and moving "stock footage" to a specialized library. We just wouldn't have the time to keep up with it. We'd have to create this sort of thing at the time of log & capture ingest; before we get to creating a working project library.

If I had to guess, I'd say that some sort if Finder/FCP X tag integration will happen at some point. Seems like a no brainer..

The more I ponder over creating FCP Libraries that contain nothing but footage as a way to catalog things, and using Library Manager 2 to index these catalog Libraries, the more I like the idea. I'll have to create a proof of concept.

The first downside I can think of is that you don't get to see a thumbnail preview (you have quick look in Finder) to see what the clip you found actually is. You'd have to mount the library to investigate. Which could be a hassle if it's not quite the clip you wanted. (Though I suppose you could right-click to "open contents" and drill down to the clip. But that might be pointless because FCP X strangely doesn't rename the source clips which is likely to be nothing but useless numbers!!)

Of course, OS X 10.10 and FCP X 10.1.(2+) could change things if Finder Tags become somehow integrated into FCP X or at least offline-chachable; going back to my original post.

Ryan,

You have raised some interesting points. Please summarize your ideas and use the feedback form to submit a feature request to Apple. I am pretty sure they will be interested.

- Ronny

Looks like I got my wish. At least somewhat. Doesn't sound like Finder Tags are a two way street with FCP X & Finder yet.

But I'm also toying with using event-only catalogs as a stock footage refuge and using Final Cut Library Manager 2 for search. I've got a proof-of-concept running. Its working fairly well so far, but there are still issues. Here's how I have things setup as of now:

We've got 4 Xsan workstations, and this potential Xsan ingest station that serves as sort of a halfway point between offline stock footage catalogs and online catalogs.

Using eSATA PCI cards, I've got two dual-drive 6G docks that can mount a RAID 1 catalog drive "MASTERS | xx" (with xx being the number of the drive) in one dock, and BlackMagic HyperDeck Shuttle-sourced SSD drives docking in the other.

Each “MASTERS | xx” volume would contain a number of stock footage catalogs. Each newly ingested project gets an event named after it and all footage gets ingested into said event where it’s logged. (I’ve not yet decided on what a suitable event/size limit would be for each catalog)

The SSDs come straight off the camera and into the ingest station and a FCP X footage catalog.

We now have FC Library Manager 2 on all xsan Macs, but keeping them in sync and up to date might be the issue in terms of our non-Xsan and offline catalog volumes. We can file share into the “masters | xx” volumes from the workstations, but this takes an active user action as our current policy is to shut down the Xsan every night, so I can’t count on auto-mounting the volume at login. (Starting up the Xsan is a process that requires human action) Not to mention that the volume would change once the current MASTERS volume becomes full – it gets moved to the shelf, and an fresh MASTERS volume would be docked.

Effectively only the FCLM2 software on the ingest Mac would be completely up-to-date. Which might not be entire terrible, but it would be inconvenient. Editors would have to screen-share into the ingest station every time they want to query the stock footage catalog. Hopefully no one else is using it at the time.

However, editors would have to Screen Share to the ingest station regardless, because with the FCP X footage catalogs not on Xsan, they can’t be launched at an editor. So the editor’s target working-library would have to be opened at the ingest station and the needed footage be copied to the target working-library. Then closed. Finally, the editor can open the target working library on their own workstation.

This could get complicated. I can understand why FCP X doesn’t allow the opening of file-shared catalogs, but man in this case it would be quite handy.

With this FCLM workflow, I’m not sure how Finder Tags would then be an advantage… I don’t think they’d be needed.

"With Camera archives you can’t rename individual clips contained inside."

Maybe not a solution, but when you rename clips in the Browser, you are aware that you can , in list view, use a column called "Camera Name" that will show the original camera name. Also, this info is in the Inspector's Info section. So you are not at all lost when trying to ID a clip in the Browser between its user given name, and the original camera given name, and the FCPX given name (Creation Date/Time).

But I'd rather the old legacy system, where I rename a clip, and have the option to rename it in the Finder or not.