Ask a person. There is not a queue.

PRO if you are going to erase the card, because it hashes every file with xxHash128 by default and writes the manifests. SECURE if you want a full checksum verify without the manifest options. SOURCE when you are making several backups before erasing and want to pay for the card read only once, with the proof deferred to a later Verify Folder pass. VERIFIED confirms destination file size. FAST does not verify anything and is the one mode that never qualifies a card for erasing.

Cutvey Offload commits with F_FULLFSYNC and re-reads with F_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, so it is a fair question to put to whatever else you are running.

Both are on by default. They cost roughly 5 ms per file on SSD and materially more on spinning media, and the honest advice is to leave them on.

No. It copies only the new clips, into the same folder. The match is made on card identity rather than on a folder name that happens to look right, and the skip is only taken for files this run has proven by content are already on the destination.

Because it could not prove the destination copy was the same bytes. Name, size and modification time start that check, and they never finish it. A file that quietly corrupted on the destination has the right name, the right size and the right timestamp, so trusting those would hand you a green result over a broken file.

A file with the same name but different content was already there, so rather than overwrite it the app renamed the incoming one Finder style and reported it. The same happens if a directory or a symlink is sitting where a clip's file should go: it is stepped around, never through.

No, it is the point. An unreadable directory hides everything below it, so a run that hit one is not a complete offload. The app does not copy what it could see and report success, because the next thing you would do with that success is erase the card. Where a scan could not finish, the counts are reported as a floor rather than a total, in those words.

Because two backups on one disk is one disk. It checks before a byte moves, along with whether the destination actually has room, discounting files that are already there so continuing a mostly-copied card only needs space for what is new.

Yes. It writes ASC MHL v2.0 into the ascmhl/ chain-of-custody directory that both read, alongside a classic MHL, plus TeraCopy-style checksum lists. An optional legacy companion can be MD5, SHA-1 or C4.

It flips the first two mebibytes of the card's whole-disk device, which corrupts the filesystem header so the camera sees a malformed card and offers to reformat. The flip is its own inverse, so Restore is the identical flip re-applied, and it works right up until the camera does a real format. After a real format, it does not.

Treat it as protection against reusing a card by mistake, not as a data-recovery plan. Keep independent backups, always.

The gate needs every file on the card proved present in a watched backup folder, by content. With no backup folders configured that question is unanswerable, so the feature can never say yes. On a fresh install the app offers to pick one, as a dismissible banner rather than a modal. If you dismissed it, add a backup folder in the Safe Erase surface and the badge will update as the watcher re-verifies.

It refuses anything that is not removable or external and ejectable, and refuses anything internal, system, boot or network outright. On top of that, the card's identity is captured when the backup is verified, carried through the confirmation, and re-proved as root by the process doing the write immediately before it opens the device. A card swapped while you are typing your password causes a refusal, and nothing is written.

Strictly one dialog at a time is the whole defence against erasing the wrong card when several finish together. Each prompt names the card by volume, capacity and device node, and a prompt is dropped if the card was swapped, removed or already handled before you answered. It tells you which of those happened, because a prompt vanishing without explanation is indistinguishable from a bug.

No. Both ship inside the app, and each is preferred over any copy installed on your machine so behaviour is the same on every Mac. ProRes, H.264, H.265 and most MXF and QuickTime go through AVFoundation, DNG stills through ImageIO, and a bundled FFmpeg handles containers AVFoundation will not open, notably Sony XAVC MXF.

Formats that need licensed vendor SDKs, specifically X-OCN, ARRIRAW, ProRes RAW, Codex HDE and Phantom, are detected and shown with readable container metadata and a labelled placeholder. That is deliberate: never a crash, and never a broken image where a frame should be.

A field is captured only where the camera genuinely recorded it, and a field a clip does not have contributes no row at all rather than a row reading "unknown". If a clip is past the metadata or thumbnail cap it is marked as not looked at, which is a different thing from having failed to decode, and the report distinguishes them.

The ALE returns nothing rather than guessing a frame rate, and it tells you that is why. Media Composer rejects an ALE with a missing FPS, and an invented one is worse than no file at all: it imports cleanly and every timecode in it is wrong. CSV has no such constraint and always writes.

Manufacturer when you want previews that look like that camera's dailies and like what the operator monitored. ACES 1.3 when a mixed-camera shoot has to look consistent with itself; it deliberately will not match a vendor's own conversion, and that is the trade. Custom when there is a show LUT, assigned per camera model with per-reel overrides available for one roll.

A clip the camera wrote corrupt copies perfectly and verifies perfectly, because verification proves the destination bytes equal the source bytes and those bytes were already wrong. Turn on the broken-media check, which confirms the container parses, declares a track, and that the first sample of that track decodes. It runs off the copy path, so it can never slow or fail a copy that succeeded, and it is not a substitute for checksum verification in either direction.

It binds loopback only and is unreachable from another machine. It is off until you turn it on, every request needs a bearer token, and it dispatches only the existing command set: no arbitrary shell and no arbitrary file access. Regenerating the token restarts the server and invalidates the old one. See the automation reference.

Expected on an unsigned build, and it will be fixed by signing. The Keychain grants access to a stored item based on the requesting app's code signature, and an unsigned build has no stable one, so macOS treats each new build as a different app. Re-enter the secret; the bucket configuration itself is kept.

Yes. An optional custom endpoint host on the bucket configuration targets S3-compatible providers such as Backblaze B2, Storj, Wasabi, Seagate Lyve and MinIO, signing against the host and region you give it. Note that a bucket cannot be a source, cannot join a cascade, and cannot be moved to.

It cannot do either. The send returns immediately and runs detached, and there is no path from a push failure into a transfer's errors. It also cannot fail silently: every attempt is recorded in Settings, successes included, and the main window shows a failure once.

One thing to know: the topic is a shared secret, not a channel name. On a public server anyone who knows the string can subscribe to it. Use Generate to get a long random one. Pushes carry a source name, a file count and a byte total, never a file path and never the footage.

Each transfer writes a JSON log and a human-readable log, which collect into a per-day folder that renders the day report. They can also be written beside the media on the destination and mirrored to a second location such as a NAS. API invocations and fired events go to api-log.jsonl and events.jsonl under ~/Library/Application Support/Cutvey Offload/logs/.

The build is not yet code-signed or notarized, so Gatekeeper blocks the first launch. Right-click (or Control-click) the app in Applications, choose Open, then Open again in the dialog. You only need to do that once. Signing and notarizing remove the step entirely.

No, and neither is planned. Cutvey Offload is an Apple Silicon Mac app on macOS 14 or later, by design rather than by omission. The download page explains the reasoning.

The app runs locally on your computer. It does not send your media anywhere except to a destination you configured yourself, such as an object-storage bucket or a notification endpoint you chose. It may check a Cutvey endpoint for a newer version, and that check carries no personal data and no user content.

Free with any Cutvey subscription: one Mac on Solo, two on Team, five on Studio. Standalone it is nineteen dollars per Mac per year. There is one edition and no feature tiers. See pricing.

Because a sandboxed build could not do the job. It needs unrestricted disk access to read any mounted card and write anywhere you point it, it spawns a shell for the event scripts you write, it opens connections to arbitrary S3 endpoints, and it stores secrets in the login Keychain. It is distributed outside the Mac App Store, so sandboxing is not required, and it still ships with the hardened runtime ready for notarization.