Camera Metadata Search: What's Actually in Your Footage (and Why You Can't Search It)

You're cutting a reel of your best work to send a client. There's a shot you know you have, but you can't remember the file name, because nobody remembers file names. What you do remember: V-RAPTOR, 8K, 50mm, sometime around March last year.

Most of that is written into the file. Finder can't search it. Neither can your NLE, at least not across your whole archive. So you scrub.

I've spent an unreasonable amount of time inside camera metadata, what each format writes, what survives a transcode, what quietly disappears, because I'm building a Mac app that searches it. This page is what I found.

What camera metadata actually is

Camera metadata is everything the camera knew at the moment it rolled. Not just the obvious fields (camera model, resolution, frame rate, date) but lens focal length, T-stop, ND position, white balance, colour science version, and the reel and clip ID that identify the take.

It lives in three different places, and the difference between them is the whole problem.

Some of it is written into the file header, the block of data at the front of the file that tells your Mac how to decode everything after it. This travels with the footage. Copy the file anywhere and the header comes with it.

Some of it sits in a sidecar, a small separate file next to the media with the same name and a different extension, like the .rmd RED writes alongside an .R3D. Sidecars travel only if whoever moved the files brought them along, and plenty of copy operations quietly take just the video.

And some of it never existed in the footage at all. The keywords you added in Final Cut, the markers in Premiere, the bins and smart collections, all of that lives in the project file. Open the same footage in a different app, or on a different machine, and it's gone.

That third category is worth sitting with. Most of the organisational work editors do is stored in a place the footage itself knows nothing about.

What metadata is stored in a RED R3D file?

R3D headers are dense. A V-RAPTOR file records the camera body, the brain, and the sensor as two separate fields: V-RAPTOR XL [X] 8K VV and V-RAPTOR [X] VV in the file I pulled apart, where the bracketed [X] is RED's own name for the sensor generation, not a gap in this page. Alongside them sits the body's serial number, firmware version, and the CFexpress or SD card the clip was recorded to. ISO, colour temperature, resolution, frame rate, REDCODE compression quality, reel number, take number, and per-frame timecode are all in there too. None of it is optional. All of it gets written the moment you roll.

Lens data is the exception, and it's the one that matters most for the V-RAPTOR-at-50mm search from the top of this page. RED reserves fields for lens make and model, but they only populate if the mount is talking to the lens electronically, RED's own PL/LPL glass, Cooke /i, Zeiss eXtended Data. Put manual PL glass on the camera, which is most of what actually ships on RED bodies, and both fields come back empty, or literally the string "unknown". The header has a place for the thing you searched by. It just was never told the answer.

R3D is proprietary and versioned by firmware, so a new camera generation can add fields before generic tools catch up. Point a general-purpose reader at a current V-RAPTOR file and you'll get most of the named fields back, plus a pile it can read the value of but not explain. RED's own SDK is still the only thing guaranteed to know what every field means.

Then there's the sidecar. RED clips carry an .rmd alongside the .R3D, an XML file holding whatever look was applied in REDCINE-X: ISO and white balance as graded, which can differ from what the camera actually recorded, IPP2 tone curves, CDL values, crop and framing, in and out trim points. It also carries a full slate, production, director, DP, scene, shot, take. In the file I pulled apart, almost every one of those fields shipped empty. The structure is there. Nobody filled it in on the day, and it's the first thing a copy operation leaves behind.

What metadata is stored in an ARRIRAW file?

ARRIRAW ships inside an MXF container, and MXF is an open, published standard, so a lot comes back for free: camera model, SUP version, image geometry, frame rate, embedded timecode, audio. Pull the clip I used for this section and you get ALEXA 35, SUP 5.01.00, 4608×2592, 24fps and a valid start timecode, without needing anything from ARRI at all.

None of that is the metadata anyone's actually searching by. Lens, T-stop, exposure index, ND, white balance, colour space, all of it rides in a separate descriptive-metadata track, and a generic reader's default output shows exactly one line for it: "Descriptive Metadata Track," no value attached. Go out of your way to ask for unlabelled tags too and that line resolves into a UUID, a pointer into a scheme ARRI defines privately, still not the data itself. So the format that writes the richest metadata in the industry ends up in the same place as RED's proprietary one, just reached from the other direction: a standard container with the interesting part fenced off behind a private extension instead of a private format with everything fenced off.

What metadata is stored in a Blackmagic BRAW file?

BRAW inverts the ARRI arrangement: a .braw file is a QuickTime .mov wearing a different extension, with camera fields written into Apple's open Keys atom as plain, self-describing strings. Open container, open extension, readable without anything from Blackmagic. The clip I pulled apart came off a URSA Cine 17K 65, Blackmagic's flagship large-format body, and the header shows it: firmware 9.5.3, an 11712×5376 frame, compression set to Q1 (constant quality rather than a fixed ratio), a camera ID, reel and clip numbering, and shoot tags for environment, day or night, and whether it was a good take.

The slate is where this file gets unusual. Production, director and camera operator are all populated: a named director, a camera operator, a terse production code in ProductionName. The camera reserves those fields but never fills them in itself; somebody on this shoot was entering data as they worked. Compare it to RED's .rmd slate a few sections up, where the identical fields shipped empty, and the pattern is clear enough: metadata completeness has as much to do with the crew as with the hardware.

Two things sit further in than the header fields. The look is baked straight into the file: a 431 KB 3D LUT, BLURRED_B_CAMERA_BM.cube, generated in Resolve and stored whole inside the clip's own Keys atom rather than left in a sidecar beside it, so there's nothing to orphan if the file gets copied on its own. And underneath the header entirely, two dedicated tracks log raw accelerometer and gyroscope readings for the whole ten seconds, over a thousand samples a second. A default metadata scan never surfaces those, because they aren't stored as fields. They're their own timed tracks, and you have to go looking.

None of it moves the lens problem. LensType and Filters are reserved fields in this same open scheme, and both came back blank: PL mount, manual glass, nothing talking to the body. The container doesn't decide what gets recorded. The glass does.

What metadata is stored in MXF files?

MXF isn't a camera format. It's a container, standardised by SMPTE, that any manufacturer can pack video into however they like. ARRIRAW ships inside one. So does Sony's XAVC, Canon's XF-AVC, Panasonic's P2 output. Point a generic reader at any of them and you get the same structural split seen in the ARRI section above: a set of fields the container itself defines, universally readable (codec, frame rate, image geometry, timecode, audio), and a "Descriptive Metadata" track sitting next to it that's just a wrapper. What's actually inside that wrapper is defined by whoever wrote the file, registered against SMPTE's own scheme registry as a private Universal Label, and a tool that doesn't know that specific vendor's scheme reads it as an opaque UUID and stops.

Which means the interesting question for any given MXF file was never "is this format open." It is. The question is which manufacturer's scheme is sitting in the descriptive track, and whether whatever's reading the file was built to know it.

What metadata survives in ProRes?

A ProRes file is the same open QuickTime wrapper a BRAW file is: .mov, Keys atom and all. Nothing about the format stops a camera or a transcoder from writing exactly the kind of rich, self-describing metadata Blackmagic writes into its BRAW files. The mechanism is right there, open, available to anyone.

Whether it gets used is a different question, and the answer is almost always no. I transcoded a real R3D clip to Apple ProRes 422 HQ through REDCINE-X to see what REDline's own exporter does with that opening. The resulting file carries pixel dimensions, frame rate, and an exact, correct timecode. Past that, essentially nothing: no camera model, no ISO, no reel or clip number, no lens field, not even an empty one. The field structure itself doesn't exist in the output the way it did in the source. The one thing that hints at where this file came from is a private redm atom sitting in the file's UserData box, and a generic reader has no idea what's inside it. It's the exact "open container, private extension" pattern from the ARRI section, just showing up on the way out of a transcode instead of the way in.

So the honest answer is: ProRes can hold almost anything, in principle, and in practice holds almost nothing, because the tools that write it don't bother. The format was never the limit.

What happens to metadata when you transcode

Here's the dailies problem, run for real instead of described from memory. Same R3D clip, transcoded through REDCINE-X to ProRes 422 HQ, the exact pipeline a lot of sets actually use to get offline media to an editor overnight. Metadata pulled from both files, field by field:

Two fields made it across untouched: resolution and timecode. Everything else, every field a search like the one at the top of this page depends on, didn't. That includes reel and clip numbering, which is worth pausing on, because it's the one people assume is safe. It isn't, not as metadata. If a facility's dailies still carry a usable reel/clip reference, it's because someone encoded it into the filename, a convention, not because the format preserved it.

Nothing about this is a bug. ProRes is a delivery codec. It was never asked to carry a shooting log, and the tool that wrote this particular file didn't try, past the two fields it apparently considers non-negotiable. The moment you transcode for an edit, everything you might later want to search by has to already live somewhere else, or it stops existing the instant the export finishes.

Why your NLE can't search camera metadata

Premiere, Resolve and Final Cut can all read a good chunk of what's covered above. Open a clip's properties panel in any of them and real fields show up. What none of them do is let you ask a question across your archive. There's no bar you type "V-RAPTOR, 8K, 50mm" into and get back every matching clip from every project you've ever touched.

That's the second half of the problem this page opened with. The first half is that a lot of what editors actually organise by (markers, keywords, bins, smart collections, the stuff from the intro's third category) was never camera metadata at all. It's written by the NLE into its own project file, which means it only exists inside that one project, on whatever machine last opened it. Move the footage into a different project, or open it in different software, and none of that organisational work comes with it. The footage doesn't know it happened.

Put those two gaps together and the shape of the problem is clear: your NLE can show you what one file knows about itself, and it can hold what you tell it about one project. Nothing shows you what your whole archive knows about itself, across every project, without you opening each one by hand. That's not a vendor being lazy. Searching arbitrary embedded metadata across thousands of files scattered over drives an NLE was never pointed at is a different kind of tool than an editor, built for a different job.

How to search footage by camera metadata

A few partial tools already exist here. Finder's own metadata fields cover a handful of the basics (dates, sometimes dimensions) and nothing camera-specific. On-set tools like ShotPut and Silverstack log metadata beautifully at ingest, for that one shoot, and don't reach back into your archive from three years ago. Enterprise MAM systems solve this properly, at a price and an install complexity built for a facility, not one editor with a drive full of footage.

Montaggio reads the fields this page has been pulling apart, at index time, not on demand, and puts them in the same search bar as everything else it indexes: what's actually in frame, who's in it, what's said out loud. Type a description and it searches content. Type @ and a name and it searches faces. Type a phrase in quotes and it searches what was said. Add /camera:, /lens:, /resolution:, /place:, or /codec: and it narrows by exactly the fields this page has been reading out of raw files by hand: the same REDline metadata, the same BRAW Keys atom, read once at index time so you're never waiting on it later. Browse structurally by any of those, plus date, the way you'd browse folders, when you don't have a query in mind yet, just a rough shape of what you're after.

Run the scenario from the top of this page today: /camera:v-raptor /resolution:8k in the search bar, then drill down to March of last year in Browse, which is where date narrowing lives. If the lens was electronic, /lens:50mm gets you the rest of the way there in the same search. If it wasn't (manual PL glass, like most of what actually ships on these bodies), that field was never populated to begin with, and no software fixes a value the camera didn't record. That's not a Montaggio limitation. It's the R3D section of this page, applied.

Montaggio is in private beta for macOS 14 and later. Join the waitlist and I'll email you the moment you can point it at your own footage.

Frequently asked questions

Sources

RED footage

Sample R3D: V-RAPTOR [X] 8K VV, LA sunset

ARRI footage

ALEXA 35 sample clips (Frame.io share)

BRAW

Blackmagic RAW test file

Blackmagic URSA Cine gallery

Transcode test

R3D to Apple ProRes 422 HQ via REDCINE-X Professional (REDline CLI), run locally against the same clip sourced above, not a separate download.