A clip in a folder called "Stills" is still a clip

Reference folders accumulate video without anyone deciding to build a video collection: a screen recording of reference footage saved next to concept art, a handful of location scouts shot as short pans instead of stills, a motion study dropped into whatever folder happened to be open at the time. None of it lives in a folder actually named for video, which is exactly why "find every clip in my reference library" turns out to be a harder question than it sounds — not because there's a lot of footage, but because nobody can remember where each piece of it landed.

Why "search by folder name" was never going to work

The obvious first move — open Finder, look for anything called "Video," "Footage" or "Clips" — only surfaces the fraction of a collection that someone deliberately filed that way. It misses the screen recording saved next to the sketches it was reference for, the phone-shot location pan that lives in the same folder as the stills from the same scout, and the motion-capture file someone dropped into a project folder years ago and never revisited. The folder name reflects what someone was thinking about when they saved a file, not what kind of file it actually is — and those two things drift apart the longer a library's been growing.

Step 1: Register the folders as they already are

Whatever root already holds the mix of stills and clips, point the app at it as it sits — there's no need to separate video into its own folder first. The first pass reads both media types in the same sweep, regardless of which subfolder each file happens to be in.

Step 2: Ask for every video file, regardless of extension

type:video matches on what the file actually is, read at index time — not on its filename or its container format. A .mov sitting in a folder called "Stills" comes back exactly the same as one sitting in a folder called "Footage."

If that number is higher than you expected, that's usually the actual finding — clips accumulate quietly in folders nobody's treating as a video collection, and a single query is what surfaces the true count.

Step 3: Narrow to a specific container when it matters

Most of the time type:video alone is the right query. When a task specifically needs one container format — sourcing footage for an edit that only accepts .mp4, say — ext: narrows to exactly that.

An extension the app doesn't recognize as video still works as a filter here — ext: matches on what's actually on the filename, so an unusual container still narrows correctly even if it's not one of the common ones.

Step 4: Search across folder names that don't hint at content

Because the query filters on the file, not the enclosing folder's name, video hiding in an oddly-named or generically-named folder surfaces the same way it would from a folder actually called "Video."

in: scopes a search to one registered folder when you already suspect where something is; leaving it off searches the whole workspace at once, which is the more useful default when the actual goal is finding clips you didn't know you had.

Step 5: Reach clips across more than one drive in the same query

A reference collection built up over years rarely lives on one disk. A query doesn't care which root a result is actually sitting on — clips on an internal drive and clips on an archive drive return in the same grid.

Step 6: Separate raw footage from lightweight screen captures by resolution

Not every clip in a reference folder is equally useful — a quick screen recording saved for reference is a different asset from an actual location scout shot on a camera. Dimensions, read at index time, are a fast way to tell them apart without opening each file.

Step 7: Find the clips nobody's reviewed yet

Once the full set is visible, the next useful question is usually which of them haven't actually been looked at since they were saved.

Step 8: Put the results on a canvas for an actual review pass

A list of forty-one file names is not a review; seeing the clips is. Placing a query's results onto a canvas turns a search into something you can actually scan and play through, one clip at a time, inline.

Why this is harder with Finder or Spotlight alone

Spotlight searches by filename and system metadata, not by tag, rating or whether a file has a note attached — a search for "clips I haven't tagged yet" has no equivalent there, because the concept doesn't exist outside a tool that reads and stores it. Finder's own file-type filter comes closer, but it operates one folder or one saved search at a time and doesn't combine with the kind of library-specific filtering — rating, tag, notes — that actually distinguishes a reviewed clip from an unreviewed one. Neither is wrong for what it's built for; neither was built for a reference library's specific questions.

What the sweep doesn't tell you, and why that's the review's job

A query answers "where is every clip" — it doesn't answer "which of these is actually still worth keeping." Those are different questions on purpose. A count of eighty-seven doesn't distinguish a location scout that's central to an active project from a test recording made to check whether a camera setting worked, three years ago, and never looked at again. Deciding that distinction requires an actual look at each file, which is exactly what step 8's canvas is for — the query narrows a folder down to a reviewable number, and the review itself is still a human judgment the search isn't trying to automate.

That division of labour is worth being explicit about, because it's tempting to treat a large type:video result as a problem the app should have solved further. It found the footage; deciding what to do with each clip — keep, discard from the workspace's tags and ratings, promote onto an active board — is the part that was always going to need a person looking at the actual frame.

Doing the same sweep for a specific project instead of the whole library

The full-library sweep in step 2 is the right starting point the first time, but a recurring, narrower version — scoped to one project's root rather than everything — is usually the more useful query day to day.

Running that narrower version regularly, rather than relying on the one-time full sweep to have caught everything forever, is what keeps a project's own footage visible as it accumulates through production rather than requiring another full-library pass months later to rediscover it.

Checking that nothing was missed after a big folder move

After consolidating footage from an old machine, an external drive, or a former collaborator's handoff into the workspace, a quick check that the video actually got indexed — not just the stills — is worth running before trusting the sweep completely.

If that count looks lower than expected against what was actually copied in, the usual cause is a container format the transfer renamed or re-wrapped unexpectedly — worth opening Finder's own file list for the same folder and comparing counts directly, rather than assuming the index missed something on its own.

Common mistakes worth avoiding

Assuming clips only need finding if they're in a folder named for video — the whole point of the steps above is that they don't need to be, and a search restricted to "the video folder" misses everything saved somewhere else. Filtering by extension first instead of starting with type:video — extension narrows correctly but only once you already know what you're looking for, and starting broad is what surfaces footage you didn't know existed. And treating a high result count as a problem to fix immediately — eighty-seven clips found is information, not an obligation to tag all of them today; step 7's narrower query is the more realistic next action.

A worked example: the folder that turned out to have footage nobody remembered

A studio archive built up over several years, mostly stills, is a typical case where a sweep like this actually earns its keep. Running type:video against the whole thing for the first time regularly turns up footage nobody currently on the team knew was there — a scout shot as a pan by someone who's since left, a screen-captured reference for a shot that never made the final cut, a motion study saved for a project that shipped two years ago.

None of those twenty-nine clips needed anyone to remember they existed. They needed the folder to already be registered as a workspace, and one query run against it. That's the actual value of the sweep on an archive this old: not organizing anything, just making the invisible part of a collection visible again.

What to do when the sweep turns up more footage than expected

A first full-library type:video query on a collection that's been growing for years often returns more than anyone expected, simply because video accumulates invisibly in folders nobody's treating as a video collection. That's not a sign anything's wrong — it's the actual value of running the sweep. From there, the same query patterns above scale to whatever the real number turns out to be: narrow by resolution to separate footage worth keeping from screen-capture clutter, narrow by tag or folder once a first pass has sorted the obviously useful from the obviously not, and rely on the watcher rather than a repeat sweep to keep the count accurate as new clips get added.

For the deeper workflow once video is actually part of the working library — tagging, rating and arranging clips the same way as stills — organizing video references picks up from here. The full set of query keys covers every filter used above, and if the workspace holding all this footage is already large, indexing a very large folder covers what the first pass actually looks like at that scale. For a video-specific reference workflow beyond search alone, a video reference manager built for Mac and the wider round-up of video reference tools are worth reading if playback — scrubbing, frame stepping — turns out to matter as much as finding the footage in the first place; the comparison with refern is honest about where that comparison currently favours the other app.

The short version

type:video on its own, run against the whole workspace, is the single most useful line in this entire page — everything after step 2 is refinement on top of that one query. If nothing else here gets used regularly, that one is worth keeping in mind the next time a project needs "every clip we have" and the honest answer is currently "I'm not sure." It takes less time to run than it took to read this sentence, and it never needs a folder to have been organized correctly first for the answer to be right, regardless of how many years of inconsistent filing sit behind it.

Most of the value here comes from running the sweep once, honestly, rather than assuming a folder's contents are known. A collection that's been growing for a few years almost always holds more video than whoever's been adding to it remembers saving — not because anyone was careless, but because a clip saved for one afternoon's task rarely gets revisited once that task is done, and it sits there, correctly indexed and searchable, for as long as nobody thinks to ask type:video the question directly. Asking it once, properly, is the whole fix.

Run the sweep against your own folders — thirty days, every feature, no card and no account, is enough to find out how much footage is actually sitting in a library you thought was mostly stills.