Camera Card Offload Checklist With Checksums

The Short Answer

A safe offload copies every camera card to at least two separate drives, verifies each copy against the original with a checksum, writes a log, and only lets the card be formatted after a named person has signed off. Do it with software built for the job rather than dragging folders in Finder or Explorer, because those tools tell you the copy finished, not that it is identical.

This checklist is for the person offloading, whether that is a DIT, a second AC, or a producer who is doing it themselves on a small shoot. For the wider role, read our DIT workflow guide.

Why a Checksum, Not a Glance

A checksum is a short fingerprint calculated from the contents of a file. If a single bit differs between the original and the copy, the fingerprints will not match. Dragging a folder only confirms that the copy operation finished, and an eyeball check of file sizes will not catch a flipped bit or a partly written clip.

Offload tools calculate a checksum while they copy, then verify. Pomfort's documentation for Silverstack, for example, says it re-reads the source after each copy by default, which can also detect read errors. Common choices for the hash are xxHash, which is very fast and not designed for security, and MD5, which is older and widely supported. For offloads, speed and accuracy matter more than cryptographic strength, so check which one your DIT, your post house or your insurer expects, and use the same one on every card.

The Offload Checklist

Before the shoot

1. 1Agree on the offload tool, the checksum type, and who owns the offload.
2. 2Label every card and every drive with unique IDs, for example A001 for the first camera A card.
3. 3Prepare at least two destination drives, plus a third for delivery to the lab if the schedule needs it. Format them and test that they mount.
4. 4Write down the naming convention (below) and put it where the team can see it.
5. 5Run a test offload with a real card so you know the speed and the software settings work.

At the card swap

1. 1Do not format a card in camera until it has been offloaded and verified, and the person responsible says it can go back into circulation.
2. 2Log the card: roll, camera, date, time received, who received it.
3. 3Mount the card read-only if you can, and use a reader that supports the card's maximum speed.
4. 4Copy the whole card, not just the clips folder. Camera systems store metadata outside the clip folders, and some post tools need it.

During the offload

1. 1Copy to two destinations at the same time or in sequence, with checksum verification turned on.
2. 2Watch for errors and warnings. A single failed file means the whole card needs to be looked at again.
3. 3Do not eject a card or drive while the tool is still writing or verifying.
4. 4When it finishes, save the report: file list, hashes, date and any warnings.

After the offload

1. 1Spot-check that clips play from one of the copies, not just from the card.
2. 2Confirm that the file count and total size match the source.
3. 3Mark the card as offloaded in the log, with the destination drive names and the initials of the person who verified it.
4. 4Keep the card unformatted until your team's rule is met. Many teams hold cards until the footage has been verified in post or backed up to a third location. Your producer, insurer or buyer may have its own rule, so ask.
5. 5End of day: seal the volume or finish the log, and store the drives in separate bags or locations.

What Is ASC MHL?

The American Society of Cinematographers' Media Hash List (ASC MHL) is a specification for recording file hashes in a standard format. It follows the older Classic MHL files, which Silverstack and other tools still support. According to the ASC specification and tool vendors' documentation, a history is stored as manifests plus a chain file, and every operation such as an offload, backup or verification adds a new generation, so you can see where in the chain a file stopped matching.

In practice:

• Pomfort's Silverstack made ASC MHL the default hash manifest in version 9.0, and its article describes sealing each volume at the end of the shoot day so post knows the package is complete.
• In post, a tool such as MediaVerify checks the folder against the history. It first scans for missing or new files, then hashes every file and compares it, and a pass requires that the history be complete and all hashes match.
• If a file fails, the generation history helps you find where the content changed.

Not every tool supports it, so ask what your post team can read.

A Naming Convention for Offloads

Pick one, write it down and never improvise. A pattern that works for many small teams:

• Destination folder: DATE_CAMERA_CARD, for example 2026-10-16_A_A001
• Day folder: SHOOTDAY_DATE, for example D03_2026-10-16
• Drive label: PROJECT_OFFLOAD_01, PROJECT_OFFLOAD_02
• Do not rename camera clips that the camera numbered. Many post tools relink from the original names. Add metadata in your log instead.

Our project folder structure guide shows how this fits into the rest of the project.

Backups and Transport

• Copy 1 stays on set until the shoot day is complete.
• Copy 2 goes to the post house or the producer's location in a different bag or vehicle.
• A third copy to a cloud service or an offsite drive is a good idea for anything you cannot reshoot. For the cloud choices, see cloud storage for video professionals.
• Never transport all copies together.

Common Mistakes

• Formatting a card because the transfer bar said 100 percent
• Offloading to one drive and calling it backed up
• Switching checksum types halfway through a shoot
• Renaming clips on the card before the copy
• Skipping the log on busy days
• Ejecting drives before the verify finishes

Want a person to help?

If you want a data workflow set up before the shoot, including the offload tool, naming, reports and handoff to post, our production consulting team can help. See our DIT workflow consulting, or tell us about your shoot and a real person on our team will reply.