FEATURES Version 3.3.1
Everything it does, and what each part is worth.
Cutvey Offload copies camera cards and drives to several destinations at once, proves the copies, organises them on the way in, documents them, and can clear the card afterwards. This page is the whole surface, in the order you would meet it on a shoot day.
01 Verification
Five modes, and an honest account of what each one proves.
Chosen per offload from the action bar. The names are not speed grades. They are different claims about evidence, and the app is careful never to let a weaker one stand in for a stronger one.
| Mode | What it does | Proves destination content |
|---|---|---|
| FAST | Copy only, no verification. The fastest thing the app can do, and it is the only mode that never qualifies a card for erasing. | No |
| VERIFIED | Copies and confirms destination file size. | Size only |
| SOURCE | An independent content fingerprint of the source, written to a checksum list, plus VERIFIED's size check on the destination. Built for the case where you make several backups before erasing a card: the card is read once, and every copy still ends up with a manifest. | Deferred |
| SECURE | xxHash64 checksum of every file, read back and compared. | Yes |
| PRO | xxHash128 by default, or xxHash64 or MD5. Writes a checksum list, and can do an optional double source read-back that defeats the OS page cache to catch a failing card. | Yes |
Source hashing happens during the copy
The fingerprint is taken inline on the copy pass, so verification only has to re-read the destination. That is one read of the card, not two, unless you deliberately turn on the double read-back to test a card you have stopped trusting.
SOURCE defers the proof, it does not skip it
The expensive half of a full verify is re-reading each destination, so five destinations cost five extra reads. SOURCE pays for the card read once, and the proof is deferrable precisely because the fingerprint is of the card, which will not exist much longer, while the destinations will. Verify Folder is what collects on it later.
02 What makes a verified copy verified
Cutvey Offload commits withF_FULLFSYNCand re-reads withF_NOCACHE, so verification happens against the device rather than the page cache. No other vendor documents whether their verification reads the device or the cache — ask them.
Why the full barrier
A plain fsync on macOS returns once the bytes reach the drive's volatile cache. Without the full barrier a verify can pass against bytes that have never reached the platter, and a card can be erased against a copy that a power loss would have taken with it.
Why the uncached read
Reading back what you just wrote, out of RAM, is not verification. It is an expensive comparison against yourself.
What it costs
Roughly 5 ms per file on SSD, and materially more on spinning media. Both are on by default and the advice is to keep them on. Mounts that reject the barrier fall back to fsync, and the message names both error numbers so you know whether to blame the app or the mount.
Bytes are never published until they are on the device
A destination file is never written at its final path. It streams into an in-flight sibling file, takes the barrier, and is published with a single atomic rename. The destination path changes exactly once, from the old file to the complete new one. A failed or cancelled copy removes only the in-flight file and never touches whatever was already there, and a process killed outright leaves an inert orphan that the scanner knows to skip.
Before a byte moves
- It checks the destination has room. Files already present are discounted, so continuing a mostly-copied card needs room only for what is new.
- It warns if two destinations for one source turn out to be the same physical drive. Two backups on one disk is one disk.
- A per-source-name override can force a fixed verification level for any source whose name matches a pattern, so a nameless
UNTITLEDcard or an ARRI raw folder always gets the strongest checks regardless of where the chip was left.
03 Manifests
The paper trail is the product.
A verified copy nobody can check later is a claim, not evidence. Cutvey Offload writes and re-reads three record formats, and it reads back what it wrote.
- Classic MHL, written and re-read. The standard covers xxHash64 and MD5, so the PRO algorithm has to be one of those for the app to write one.
- ASC MHL v2.0, the modern chain-of-custody
ascmhl/directory that Silverstack and YoYotta read, written alongside the classic MHL and working with every PRO algorithm. xxHash128 is written as<xxh128>per the spec. - Checksum lists in the TeraCopy style, written per transfer.
- An optional legacy companion in MD5, SHA-1 or C4, computed in the same read pass, so a second digest costs no extra pass over the media.
Illustration of a written manifest
The readers round-trip
A written manifest parses back to exactly the paths and digests it recorded, including names with spaces, newlines, or characters XML cannot carry. The app also reuses an existing manifest's checksums when a file's size and modification time already match, instead of re-hashing the source, and flags zero-byte and missing files while it is there.
04 Organization
Footage lands organised, not sorted out later.
Rename Format and Folder Format are built from tokens, and file-based tokens used in a folder format re-sort files into a new structure on the way in.
| Family | Tokens |
|---|---|
| Source | {Source Name} {Counter} |
| Date and time | {YYYY} through {ss} |
| File-based | {Filename} {File Extension} {File MM} and the rest |
| Content-based | {Content YYYY}, the date of the oldest file on the card |
| User-defined | any element you declare, for example {Project} {Location} |
Labels and Auto Labels
Click a disk name to label it. The label names the parent folder on the destination, a slash creates subfolders, and tokens are allowed. Auto Labels follow the active preset.
Elements
Custom metadata fields prompted in a Review panel before the transfer starts. Their values flow into labels, folder and rename formats, logs, and MHLs. Text, dropdown, date and counter kinds; the last two compute their own value and are deliberately left out of the prompt, because an element that always has an answer must never be the reason an unattended run stops to ask a question nobody is there to answer.
Ignore rules and presets
Skip by extension or name fragment, or invert it to copy only those. Bundle a package or named directory as one unit above a size threshold, drop empty folders, or flatten. Presets are shareable .cutvey JSON files you can export and hand to the next cart.
05 Transfers
Cascades, queues, duplicates, and picking up where you stopped.
Assigning volumes creates one pending transfer for every source and destination pair. Each one runs and reports independently, and can be queued, stopped and resumed on its own.
Cascades and Cascading Groups
Copy to the fastest disk first, then have the secondary destinations copy from that disk rather than from the card, so the card is released early and can go back to the camera. Cascading Groups extend this with branching and chaining across several groups.
Queue modes
Off, so everything runs in parallel. Single Source. Single Destination. Or Single Transfer, when the bus or the drive is the bottleneck and running four at once just makes all four slower.
Duplicate Detect, and what a skip means
A file already on the destination is skipped only when this run has proven by content that the destination holds the same bytes. Name, size and modification time start that check and never finish it, so a file that quietly corrupted on the destination is re-copied rather than trusted. A same-name-but-different file is renamed Finder style, as name 2.ext, and reported.
Stop, resume, and continuing an offload
The same proof-by-content rule is what makes resume safe: a resumed transfer re-runs and skips only what actually copied. It is also what lets you continue an offload. Pull a card at lunch, keep shooting on it, and the wrap offload copies only the new clips into the same folder, proven by card identity rather than by a folder name that happens to match.
Move, with proof
Within a volume, a Move is a rename: near-instant and inherently integrity-preserving. Across volumes it copies, proves the destination by content, then deletes, never on size or timestamp. It is refused outright in any mode that cannot prove destination content, rather than quietly downgraded to a copy, and the deletions are batched only after the whole transfer succeeds, so a failure never leaves you with neither copy.
Date and time override
Pin the effective date for logs and day folders without touching the system clock, with an optional 4 AM rollover so an overnight shoot files under the day it started rather than the day it ended.
06 Ingest Browser
One card, several destinations, different rules for each.
Cherry-pick individual folders inside a source card. Each folder you check becomes its own labelled source, so a single card can be split into several organised destinations in one pass.
Each checked folder can also carry its own preset, not just its own label. That is what lets a card's DCIM and its audio folder land under different organization rules in a single pass, instead of forcing two runs. A folder you did not give a preset uses the batch settings.
Built for a big card
The browser lists one level at a time, lazily, so pointing it at a full 512 GB card does not stall the window while it walks every directory on the volume.
The card sentinel
A small record at the card root remembers prior offloads, so a re-inserted card can offer to skip what was already copied. It is written only to writable cards, and it is never itself copied into your footage.
07 Logs and day reports
Every transfer writes its own record, and the day collects them.
Each transfer writes a JSON log and a human-readable log. Logs gather into a per-day folder that renders a self-contained HTML or PDF day report with your logo, a title and note, totals, and per-source and per-destination detail, plus a CSV export.
Beside the media, and somewhere else
Transfer logs can be written alongside the footage on the destination, and mirrored to a second location such as a NAS, so the paper trail is not only on this Mac. Requested-but-failed is distinguishable from not-requested, rather than both showing up as nothing.
Clip Awareness
Adds thumbnails and media metadata to the day report, probed from the destination copy and off the copy path, so producing a richer report can never slow the thing that actually matters.
A floor, not a total
When a scan could not finish, the day report says the counts are a floor rather than a total, in those words. A confident number that is quietly wrong is worse than no number.
08 Camera reports
A contact sheet of everything on the card.
Point the app at footage by drag and drop, or let a report fire automatically at the end of an offload. It groups clips into report, days, reels and clips, with reel detection covering ARRI and Blackmagic and generic reel prefixes, RED reel folders, and DCIM numbered rolls.
What it captures
Duration, resolution, codec, frame rate, start timecode and date, plus ISO or EI, white balance in Kelvin and tint, shutter angle and speed, lens make and model and focal length and T-stop, ND, colour space and gamma tag, bit depth, audio channels, and scene, take and slate.
Each is captured only where a source genuinely provides it, and a field a clip does not have contributes no row at all. The report omits it rather than printing "unknown" or a dash. The label, order and formatting are declared once, so the HTML report, the ALE and the CSV cannot drift apart.
Reports disclose their own caps
A clip beyond the metadata cap or the thumbnail cap is marked as not looked at, rather than rendered identically to a clip that genuinely failed to decode. An unexamined thing must not look like an examined one.
Where it lands
The folder the files were copied to, which is what an automated workflow wants and the default on fresh installs, or your Documents folder, or anywhere you choose, with a token-driven file name. A dark HTML report and a light PDF, every time.
Three ways to render the previews
A camera-native Log clip previews flat unless it is converted. There are three answers, and they are different products rather than three qualities of the same one. Chosen per shoot, and overridable per camera model.
| Render | What it is | Reach for it when |
|---|---|---|
| Manufacturer | A Log to Rec.709 conversion generated from each vendor's published curve and primaries. RED R3D bypasses it and uses RED's own IPP2. | You want previews that look like that camera's dailies, and like what the operator monitored. |
| ACES 1.3 | The Academy's ACES 1.3 RRT and Rec.709 Output Transform, applied to every camera identically, fed the same per-camera decode. RED R3D switches to a scene-referred decode so it goes through ACES rather than staying on IPP2. | A mixed-camera shoot that has to look consistent with itself. It deliberately will not match a vendor's own conversion. That is the trade, and the app says so. |
| Custom | Your own .cube, assigned per camera model and detected automatically from clip metadata. Per-reel overrides still win for one roll. |
There is a show LUT and everyone has already agreed to it. |
Both RAW SDKs ship inside the app
Cutvey Offload is compatible with Blackmagic RAW, which loads from the app's Frameworks folder, and with RED R3D, which loads from its Resources folder. Each is preferred over any copy installed on the machine, so behaviour is identical on every Mac. You install nothing.
ALE and CSV for editorial
The same report renders as an Avid Log Exchange file and as a CSV, from an Editorial Tables panel, with column names following the vocabulary Avid, Resolve and Silverstack already emit. The ALE is refused rather than guessed at when the frame rate is unknown, because Media Composer rejects an ALE with no FPS and an invented one imports cleanly with every timecode wrong.
Broken-media check
An optional pass confirming the container parses, declares at least one track, and that the first sample of that track actually decodes. A file that opens is not a file that plays to the end, and the check says so about itself. It is not a substitute for checksum verification and cannot be substituted by it.
What decodes, and what does not
| Format | How it is handled |
|---|---|
| ProRes, DNxHR, H.264, H.265, most MXF and QuickTime | AVFoundation, natively. |
| DNG stills | ImageIO. |
| Blackmagic RAW (.braw) | The Blackmagic RAW framework, bundled with the app. |
| RED R3D (.R3D) | RED's redistributable runtime library, bundled with the app. CPU decode. |
| Sony XAVC MXF and friends | The bundled FFmpeg frame grabber, for containers AVFoundation will not open. |
| X-OCN, ARRIRAW, ProRes RAW, Codex HDE, Phantom | Detected and shown with readable container metadata and a labelled placeholder. These need licensed vendor SDKs. Never a crash, and never a dangling link. |
09 Verify Folder
Collect on the proof months later.
Re-check a delivered folder against the manifest it carries: the answer to "is the footage on this archive drive still the footage we shipped?" It reads all three record formats the app writes, and re-hashes with whatever kind the record is in, C4 included.
It is two steps on purpose. Pick a folder, see which manifest was found, and only then commit to the re-hash. Discovery is nearly free; verification reads every byte of a delivery that may be terabytes. Splitting them means you find out before the wait that you are about to verify against a classic MHL from 2019 rather than the ASC MHL chain you assumed was there.
You can also seal a folder Cutvey never copied, seal or verify many folders at once where one failure does not stop the rest, and compare two folders with no manifest at all, by content or faster by name and size. That last one is the everyday "did that drag actually land?"
| Bucket | Verdict |
|---|---|
| corrupted | Fail. In the manifest, on disk, digest disagrees. |
| missing | Fail. In the manifest, not on disk. |
| unreadable | Fail, and its own bucket. "The bytes are wrong" and "I could not look at the bytes" are different facts, and someone deciding whether to re-clone a drive needs to know which. |
| incomplete | Fail, before any count is consulted. A folder that would not fully walk can never report a pass. |
| extra | Never a failure, only reported. A manifest records what it recorded. It does not forbid someone adding a camera report afterwards. |
A discovery failure is amber, not red
No manifest, a manifest that could not be trusted, or not a directory at all means no verdict was reached, and it renders as "Could not verify, no check was made". Not verifying is not the same as failing, and colouring it red would claim a check that never ran.
10 Safe Erase
Reversible by construction, gated by content.
Once a card is provably backed up, the erase applies a reversible change: it flips the first two mebibytes of the card's whole-disk device, so the filesystem header is corrupt and the camera sees a malformed card and prompts to reformat. Because the flip is its own inverse, Restore is the identical flip re-applied. It undoes the fake format right up until the camera does a real one.
The strong gate
Every file on the card is proved present in a watched backup folder by content checksum against a manifest: the hash has to match and the real bytes have to be on disk. Overlapping roots are refused, so a card cannot verify against itself. A card the walk could not fully read is a hard failure. This is a statement about the card: every byte on this card exists somewhere else. Nothing relaxes it, bypasses it, or makes it optional.
The weaker one, named as weaker
The automated chain can also authorise an erase on the strength of a completed, verified offload. That is strictly weaker: a preset that flattens folders and skips file types deliberately produces a destination that is not a mirror of the card. So it is off by default, buried behind a warning, warned again in the confirmation sheet in plain language, and reachable only from the chain. It says outright that it does not compare the card against the backup file by file, and that the stronger check still lives on the Safe Erase screen.
- 01Device eligibilityThe whole disk is resolved and its flags re-read. Anything that is not removable or external, and ejectable, and not internal or system or boot or network, is refused. The boot disk is refused by name.
- 02Explicit confirmationA sheet naming the volume, its size and its device node, with an "I have verified the backup" checkbox that has to be ticked before the red confirm button enables.
- 03Card identityVolume UUID, whole-disk size, media name and serial are captured when the backup is verified, carried through the confirmation, and re-checked against a fresh read of the disk immediately before the privileged write. Every other check answers "may a card be erased here?" Only this one answers "is this the card I verified?"
- 04Administrator authorizationThe write runs in a separate privileged process, which is handed the expected identity out of band and re-proves it as root before it opens the device. A card swapped while the password is being typed is refused by the process doing the writing.
- 05Restore has an identity gate tooThere is no backup gate on Restore, because un-corrupting is safe. But the flip is its own inverse, so applied to a card that is not fake-formatted it would corrupt it. Restore therefore refuses unless the disk at the recorded node matches the recorded card and has no mounted volume.
Always watching, not watching-when-open
The backup watcher starts when the app launches and restarts on every volume mount and unmount, so card verification is already current when you open the Safe Erase surface, rather than beginning at the moment you open it. Multiple backup folders are supported, and they persist. Fake-formatted cards persist too, so Restore survives a relaunch.
11 The automated chain
Insert, copy, cascade, verify, report, and then one question.
Two independent checkboxes, both off by default: offer to eject the card when a copy completes, and offer to securely erase it. When both are on, a card raises one dialog offering both, eject first and erase second and subordinate with its warning. You pick one. There is no "do both".
A queued prompt is re-checked before it is shown
The hazard is the minutes between a card finishing and its dialog reaching the front of the queue, during which you can pull it, swap it, or handle it by hand. So a stale prompt is dropped, and it tells you why: it was already handled, the card was removed, a different card is now in that slot, the card in that slot is not the one that finished, or its transfers changed after the prompt was queued.
Strictly one dialog at a time
Cards that finish together are asked about one at a time, each named by volume, capacity and device node. One at a time is the entire defence against erasing the wrong card when several finish together, so it is enforced by the queue itself rather than left to whoever is calling it.
12 Notifications
Told on the cart, told across the lot.
macOS notifications and an in-app bell fire when a source finishes offloading. Optional phone push through ntfy, either the public server or your own, sends the same alert to your phone. Install the free app, subscribe to a topic, done. No account, no password, no server of your own unless you want one.
A report can also be composed as an email in your own mail client, so nothing has to store your mail credentials, because it never has them.
Three guarantees, in the order they matter
- It cannot delay a transfer. The send returns immediately and the request runs detached with a short timeout. The copy path never waits on it.
- It cannot fail an offload. There is no path from the push into a transfer's errors. The strongest thing a failure does is set a string.
- It cannot fail silently. Every attempt lands in Settings, successes included, because that is where you go to ask whether it is working. The main window shows a failure once, because a banner that announced every success would be trained away within a day and then not seen when it mattered.
The topic is a shared secret, not a channel name
On a public ntfy server anyone who knows the topic string can subscribe to it. There is no second factor. That is why Generate produces a long random string, and why a push carries a source name, a file count and a byte total, and never a file path and never the footage.
Everything above is in every copy.
There is no feature tier and no Pro upsell. Free with any Cutvey subscription, or nineteen dollars per Mac per year on its own.