Cataloging b-roll across clients without a MAM
StoryFolder —
Part of: How to catalog b-roll across multiple clients
Last updated: 2 September 2026.
A searchable visual index is often enough for a studio of two to fifteen people. If the job is to look at thumbnails, narrow by client and job number, save the questions you ask weekly, and hand a producer a spreadsheet, that is index work. You need a MAM once the media itself has to be managed.
Managing the media means where it lives, how it gets ingested, which proxies your editors cut with, who is allowed to touch it, and how two people work in it at once. StoryFolder sits on the index side of that line and does not pretend otherwise. It leaves your files where they already are, keeps its own database on one machine, and manages nothing about the media itself: no automatic ingest, watch folders, volume tracking, proxies your NLE can cut with, or sync between machines. Teams share the output of the library rather than the library. When the question you actually need answered is "which drive is this on," that is a drive cataloguer's job, and NeoFinder and DiskCatalogMaker are the two people keep coming back to.
New in 0.4. The library side of this argument got the three pieces it was missing: collections, quick filters and video-level metadata fields. What each one is for.
Do small studios actually need a MAM?
Usually not. The dividing question is whether you need to find the shot and point back at the source, or whether you need to govern the media itself: move it between storage tiers, hand out permissions, generate proxies, keep an inventory of what is archived where. Governing media is infrastructure, and it arrives with the administrator that infrastructure needs.
A post veteran, quoted by postPerspective, drew the low end of the line without hedging: "If you are a freelance, project-based editor and you are working from home, you don't need a MAM." He does not say what you should use instead, which is where most readers get stuck.
| The job in front of you | What it takes |
|---|---|
| Find the drone shot from a client's job two years ago | A visual index with business fields on it |
| Recognise a shot by looking at it | Thumbnails, at shot level |
| Narrow to one client, one job, one kind of material | Typed fields and filter chips |
| Ask the same question every Monday | Saved views |
| Gather picks from twelve projects into one place | Cross-project collections |
| Give a producer a shot list they can open in Excel | A spreadsheet export |
| Know which unplugged external a file is on | A drive cataloguer |
| Ingest a card automatically when it mounts | A MAM with watch folders |
| Give an assistant read-only access, and an editor write access | A MAM with permissions |
| Have two editors log the same library at once | A MAM with a server behind it |
| Push proxies into everyone's NLE | A MAM, or your own proxy pipeline |
Someone on r/editors, asking whether a very basic MAM exists, wrote the requirements list for this whole category better than any product page has:
"All they really want is a database that will search a volume, create thumbnails, and allow comments. All they want to do is know where the footage can be found. They don't want to be tied in to monthly contracts, nor do they need any automated tagging or other bells and…"
Thumbnails and findability are exactly what an index gives you. "Search a volume" is not. StoryFolder indexes the videos you deliberately import, one at a time, and it never sees the rest of the disk they came from. Point it at a selects reel and each shot in that reel gets a thumbnail and somewhere to type; point it at nothing and a folder of two hundred untouched clips stays invisible.
What is the smallest workable b-roll system?
Storage you already own, a schema no bigger than the pillar's eight-field template, a visual index over the material you would genuinely reuse, and something exportable that points back at the original file. A field nobody fills costs more than the one you never made, so cut the schema shorter than feels comfortable.
A shape that has survived contact with real client work:
| Field | What it answers |
|---|---|
Client |
Whose job was this? |
Job# |
Which job, in your own numbering? |
Content Type |
B-roll, interview, GVs, drone? |
The first two gate a whole job and the third narrows inside it. The rest of the template, where those field names came from and how often each one actually gets filled is the pillar's story, how to catalog b-roll across multiple clients. Fields belong to the library rather than to any one project, so they appear on everything you import afterwards, and the shape of the index itself is folders, collections and quick filters. Build a search or a filter, then Save as quick filter to keep it as a card in the rail with a live count that re-runs as that library grows. When no filter describes the pull you want, add shots to a collection that spans projects, one shot per Add to collection, which is quick for a dozen picks and a slog for forty. Building the schema, correcting the shot boundaries and exporting the result are all covered there too. This page is only about whether that layer is enough for you.
Which jobs can a lightweight visual index cover?
Everything in the left column below, and none of it requires a server.
| What you want to do | How an index does it |
|---|---|
| Recognise material by eye | A grid of shot thumbnails per video |
| Find a phrase someone said | Search matches transcript alongside metadata, in one pass |
| Find a typed value | Search matches Text, Dropdown, Tag and Number fields by substring |
| Combine client and shot type | A video-scoped filter gates whole projects, then a shot filter selects inside them |
| Reuse a question | Save it as a quick filter, with a live count |
| Build a pull for an edit | A collection of hand-picked shots spanning projects |
| Give a producer a shot list | XLSX with a column per field and a thumbnail per row |
| Show a client the shots | A published link, or a storyboard PDF |
Two limits on that last row are worth knowing before you promise anything. The published link is a page people look at: three layout modes, no commenting, no picking, no timecodes, and no video playback for boards built from local files. And the spreadsheet export and custom fields both sit behind Pro, while the free tier runs 3 boards at 12 shots each, which is enough to test the idea on a short reel and not enough to run on.
What are the warning signs that you need a real MAM?
Any one of these is a hard cutoff, not a nice-to-have you can work around:
- Media arrives faster than a person can import it. Watch folders and card ingest are the point at which an index stops scaling. StoryFolder imports one video per drop and says so in the overlay.
- Your editors need proxies generated centrally. StoryFolder makes a small internal proxy so the app can browse quickly. It is not a proxy your NLE cuts with, and there is no transcode farm behind it.
- Two people need the same library open. The database is a local SQLite file on one machine with nothing syncing it. A second person gets a published link or an XLSX, which is a copy of an answer rather than access to the library.
- Access has to differ by person. There are no roles and no per-user permissions. A link is public, unlisted, or password-protected, and that is the entire model.
- You need to know which shelf a drive is on. Nothing records a volume name. A file that moves goes media-offline and offers
Locate File…, which reconnects a replacement on a duration match, and that is a repair rather than an inventory. - Picks have to land back in the timeline. There is no EDL, XML, FCPXML or AAF writer, so a selection leaves as a spreadsheet, a PDF or a link.
The fifth is the one that catches studios out, because it feels like the same problem as findability and it is a different product category. Oliver Peters, writing about project organisation in January 2021, described a stack with twelve backup drives at home and over two hundred at work, and named DiskCatalogMaker as the piece that answers where something is. Someone on r/videography put the amateur version of the same tool plainly, counting the drives on the shelf at the time they wrote it: "I offload completed projects and have a spreadsheet of what's on which drive (I have 40 drives in a closet now, going back about 16 years)." A drive cataloguer indexes a disk once and then answers questions about it while it sits unplugged. That is a genuinely different mechanism from indexing shots inside videos you chose.
The drive cataloguers do not solve the shot problem either. A poster on Hacker News in 2026, hugorut, described years of footage with filenames like "C01456" and a run through NeoFinder, Lightroom and assorted DAMs, none of which fit how he works with video. Choose the layer that matches the question you get asked most, and run both if you get asked both.
How does the workflow fail when nobody maintains it?
It fails at the fields nobody can fill fast enough. A poster on r/editors aimed this at the tier above, and it lands just as hard here. They wrote that the enterprise products were "Great for a big post house, but really pricy for smaller outfits. My mini soapbox about MAM is that it will only ever be as good as whoever is keeping it…"
So make one or two fields genuinely required and let the rest be optional. Favour values that repeat down a whole reel, because you can select a run of shots and set one value on all of them at once. An exhaustive scheme collapses inside a month. A two-field scheme survives a change of staff, which is the only test that matters.
What should you test before committing?
Run this on one reel, not on your archive:
- Import a local
.movor.mp4— a selects or b-roll reel from a recent job. See importing a local video file. - Create the fields you would actually fill, and no others. See custom fields.
- Fill them on the reel: drag-select a run of shots on the board, then set one value on all of them from the shared panel. Time yourself.
- Type a value into the search box and check the shot comes back with a reason you can read. See searching metadata and transcripts.
- Move the source file to a different folder, reopen the project, and reconnect it with
Locate File…. - Export the spreadsheet and send it to a colleague who did not shoot the job. See exporting a shot list.
If step three took longer than the reel is worth, cut fields until it does not. If step five is the step you care about most, you want a drive cataloguer instead. And if you got to step six and immediately wanted the recipient to be able to edit what you sent, you have already outgrown this layer and should be pricing a MAM.
FAQ
What size team is this workflow for? Studios of roughly two to fifteen people doing client work, which is who the underlying research covers. It is an audience description rather than a limit the software enforces.
Does StoryFolder replace a NAS? No. A local import is never copied into the app, so the file stays on your NAS or drive and the app keeps an index and its cached frames locally.
Can it import a whole drive automatically? No. Import takes one video at a time, and there are no watch folders, so a multi-file drop skips the extras.
Can two editors share one live library? No. The library is a local SQLite database on one machine with no sync layer. Teammates receive a published link or an exported spreadsheet.
What finds a file on an unplugged drive?
A drive cataloguer such as NeoFinder or DiskCatalogMaker. StoryFolder records no volume name and only offers Locate File… once you have reconnected the source.
Is the free tier enough to try this? It runs 3 boards at 12 shots each, which is enough for a test reel. Custom fields and spreadsheet export are Pro.