Cinema camera storage recovery starts with a question that has nothing to do with software: can any computer other than the manufacturer’s read this media at all. Professional media range from ordinary SATA and NVMe devices that a laptop mounts without complaint to proprietary carriers that only a vendor reader can address. Confirm which category you hold before you act, because on the second, attempts outside the vendor toolchain are spent on the wrong problem.
The cause of a lost take is also more often procedural than electrical: the card and its file system are intact, and the footage exists as files the offload step failed to move.
Professional media are not one technology
Diagnosing which layer failed takes about ten minutes and decides everything that follows.
Grouping CFast, CFexpress, SxS, and camera-specific SSDs together is convenient for a search engine and misleading for a technician. They differ in interface, in presentation to the host, and in how much of the recovery path you control.
- CFast 2.0 is a SATA device in a compact carrier, using AHCI. A CFast reader exposes it as an ordinary block device with a FAT32 or exFAT volume on top. Devices such as the ARRI AMIRA, Blackmagic URSA Mini Pro, and Canon Cinema EOS bodies write to it. From a recovery standpoint, it behaves like a very fast SD card with a real controller.
- CFexpress Type A and Type B are NVMe devices carried on PCIe lanes. The host sees an NVMe namespace, and the volume on top is nearly always exFAT. Canon, Nikon, Sony, Panasonic, and several cinema bodies use it. This is where the flash inside is managed by an SSD-class controller with a proper flash translation layer, not the simplified mapping found in an SD card.
- SxS and SxS Pro X are Sony’s proprietary ExpressCard-format media, PCIe-based, carrying a UDF volume that stock operating systems will not mount without a driver. They are addressed through Sony’s reader and software stack.
- Camera-specific solid state media are the closed end of the market: RED MINI-MAG and RED PRO, Sony AXSM cards for the AXS-R7 recorder, Codex Compact Drives, and similar carriers. These require the matching vendor reader, and in several cases the vendor’s own software to reconstruct the recording into a usable file.
The table that decides your next move
| Media | Interface | Volume typically present | Reader required | Realistic recovery path |
|---|---|---|---|---|
| SD / UHS-II | SD | exFAT or FAT32 | Any SD reader | Software scan, then a laboratory if silent |
| CFast 2.0 | SATA / AHCI | exFAT or FAT32 | CFast reader | Software scan behaves like SD recovery |
| CFexpress Type A/B | NVMe / PCIe | exFAT | CFexpress reader | Software first; laboratory work is far harder than on SD |
| SxS, SxS Pro X | PCIe | UDF | Sony reader plus driver | Vendor tooling first, then a specialist lab |
| RED MINI-MAG, RED PRO | Proprietary | RED container | RED STATION class reader | Vendor tooling, then a specialist lab |
| Sony AXSM (AXS-R7) | Proprietary | UDF-based | AXS reader | Vendor tooling, then a specialist lab |
| Codex Compact Drive | Proprietary | Codex format | Codex reader | Vendor tooling, then a specialist lab |
The pattern the table exposes is that the recovery path narrows as the interface becomes more proprietary. Software can help on the left-hand rows and cannot help at all on the right-hand ones.
If you are on Windows and the card is still detected by a computer, a purpose-built recovery tool such as XRecovery (xappset.com) can scan SD, microSD, and other memory cards for deleted or formatted photos and videos. As with any recovery tool, stop writing to the card first and always save recovered files to a different drive.
Three things to confirm before you attempt anything
One: is the failure logical or physical? A card that mounts and shows a volume has a logical problem and is a software case. A card that produces no device at all, on a known-good reader on a rear-panel port without a hub, has a physical or controller-level problem. Those two categories have completely different costs and completely different success rates, and the check takes one insertion. The silent-card decision tree covers the variations.
Two: which volume should be there, and is the vendor’s tool the only thing that can read it? A production should know before the shoot whether the card is UDF-based, exFAT-based, or wrapped in a proprietary container. If the answer is one of the closed formats, the plan is not “run a recovery tool later,” it is “call the rental house and the vendor today,” because the alternative does not exist. Offload software such as a DIT cart’s copy utility may be able to read the volume while a generic recovery scanner cannot, and that difference is worth exploiting before shipping anything.
Three: what is the material worth, and who carries the risk? On a production with insurance, a completion bond, or a client contract, the moment of decision is a conversation rather than a solo judgment call. A card used as the camera original deserves different handling from a card holding a transcoded proxy of something already backed up. The software versus laboratory decision is the same calculation here, scaled up by the value of the take.
Why the closed formats usually go back to the manufacturer
Two mechanisms push professional media toward the vendor, and neither is about difficulty so much as about access.
The first is the volume format. A UDF volume written by a professional recorder, or a container built by RED or Codex, is not a file system that a generic scanner knows how to walk. The scanner may find no signature it recognizes and report an empty card while the footage sits in plain sight to the right tool. This is a case where a scan returning zero files proves nothing about the card.
The second is the flash translation layer. CFexpress and camera SSDs contain a full SSD controller with wear leveling, and the mapping from logical block addresses to physical flash pages is complex, versioned, and typically not published. On an SD card, a laboratory can often reconstruct mapping from the controller’s own metadata. On a modern NVMe media device, the same job is substantially harder, which is why chip-off work on CFexpress is rarer and more expensive than on microSD. The companion page on recovering professional cards deals with the tool side of the same media.
Where the loss usually actually happened
In practice, most “lost cinema footage” arrives at the technician’s desk one step away from the card, which is why the first job is to prove where the failure sits.
| Reported symptom | Most common real cause | First check |
|---|---|---|
| Volume mounts but the take folder is missing | Offload deleted or moved it, or the camera reused a folder name | Compare folder listing against the camera’s clip list |
| Copy finished, verification failed, file plays halfway | Destination was truncated or the source was ejected mid-read | Compare byte counts, then re-transfer from the original |
| Card mounts on the DIT cart but not on the laptop | Missing vendor driver, or a UDF volume | Install the vendor driver before concluding anything |
| Card is invisible on every reader | Controller-level or physical failure | Stop inserting it and prepare a vendor or lab case |
| Card mounts read-only | Write-protect state or controller falling back after errors | Image it immediately rather than repairing in place |
The first row is the most frequent and the least alarming. A card that mounts, with a healthy file system and a missing take, is usually a correctly functioning card that the offload process wrote to incorrectly. Image it, inventory the files, and compare the inventory against the camera’s own clip numbering before assuming the worst. A gap in the numbering tells you exactly how many clips are involved, and a complete set plus a missing deliverable points at the copy rather than at the card.
The counterintuitive part of professional media
Two facts about this class of media consistently surprise experienced operators.
A quick format on professional media is not always quick at the flash level. On many recorders, formatting is a file system operation and the data survives, which makes the media recoverable. But some cards and recorders implement sanitize or secure-erase instead, and that command tells the controller to unmap or erase the underlying pages. On SSD-class media with active garbage collection, blocks that were unmapped can be consolidated and erased within minutes even with no new recordings. The practical consequence is that prompt imaging matters far more on CFexpress than on an SD card, and a card left powered in a reader for a day is a card whose recoverability quietly declines.
A large file whose content is intact but whose container is unreadable is the best possible news. A cinema take that lands as tens of gigabytes of REDCODE or ProRes payload with a damaged wrapper is a container problem, not a data problem, and container problems are solved by rewriting the wrapper. That is precisely the situation the cinema RAW video recovery workflow is built for. File size is the diagnostic: an empty recording is small, and a large broken recording is full of frames.
An on-set practice that would have prevented most of this
The failures in this article share one root: the camera original existed in exactly one place, and the only copy of that place was in motion. A dual-card recording configuration, an offload that verifies before erasing, and a second destination that is never mounted read-write during the shoot remove nearly all of it. The DIT data management workflow and the guidance on dual card recording setups cover the operational side; the point here is that no recovery method, software or laboratory, improves on having a second copy.
Frequently Asked Questions
Can I recover a CFast or CFexpress card with ordinary recovery software?
For CFast, usually yes: it presents as a SATA volume with a standard file system, so a normal scan works when the card mounts. For CFexpress, the software step is the same, but act fast, because SSD-class garbage collection can erase unmapped blocks far sooner than an SD card would.
Why does my SxS or RED card show as empty in every recovery tool?
Those media carry proprietary or UDF volumes that generic scanners cannot parse, so an empty result means the tool cannot read the volume, not that the card is empty. Use the vendor reader and software first, and involve the manufacturer before a laboratory.
Is a card that mounts read-only worth repairing in place?
No. Mount it, take a complete image, and treat that image as the working copy. Repairing in place risks a controller failure mid-write, and every write to a card in a degraded state can move the failure from logical to physical.
How do I know whether the footage is lost or just not copied?
Compare the camera’s clip numbering with the files on the card and in the offload destination. Consecutive numbering with a missing deliverable means the media is fine and the copy step failed; a gap in the numbering means a specific clip was never completed.