Checksummed Transfers for Client Masters
Ship masters with an xxHash manifest and packing list, plus a rule for WeTransfer versus Aspera, Signiant, MASV, or a physical drive.
A master that arrives one bit different is a different master. Consumer send links do not tell you that. They tell you the upload finished.
That is the gap. A WeTransfer, a Drive folder, a Slack drop: useful for a review cut. None of them is a delivery protocol for the file a colourist, a mixer, or a client's archive will treat as the original. The protocol is a packing list, a checksum that finishes at RAM speed, and a decision about the pipe.
Review copies and masters are different jobs
WeTransfer's own plan-limits page caps a free account at 3 GB per transfer, and at 10 transfers or 3 GB total in a 30-day rolling window. Ultimate removes the per-transfer size cap. Their own copy is also clear that a browser preview is shown at lower resolution than the original, and that a download of the original is not supposed to be re-encoded.
So the failure mode is not "WeTransfer secretly transcodes your ProRes." It is everything around that claim:
- The recipient saves the preview, not the original.
- The transfer is incomplete and nobody notices, because there is no hash to compare.
- The file is then forwarded through Slack, iMessage, or a cloud drive that does transcode video for playback.
- C2PA hard bindings hash the bytes. The first genuine rewrite breaks them. A convenience re-encode has just stripped the provenance record you thought you delivered.
Drive-by sending is sending without a named file list, without a hash, and without a confirmation that the bytes on the far disk match yours. For a review MP4 that is annoying. For a client master it is how you spend a week arguing about a file that is "the same" and is not.
Keep review copies on the cheap pipe. Put a hash next to them anyway, because review copies still get uploaded to platforms and still get blamed on you. Put masters on a pipe that can prove arrival.
A checksum that finishes at RAM speed
MD5 is what a lot of facility specs still print. It is also slow on multi-gigabyte media, and it is a broken cryptographic hash for collision resistance. You are not using it to defeat an attacker. You are using it to catch a flipped bit, a truncated copy, or a file that was replaced with a similarly named one.
xxHash is the non-cryptographic hash built for that job. The official site describes it as working at RAM speed, in four flavours: XXH32, XXH64, XXH3 64-bit, and XXH3 128-bit. Media tools already speak it: Hedge, Pomfort Silverstack, TeraCopy, and rsync sit on the project's own "used by" list. Pomfort's data-integrity write-up treats xxhash64 as a normal media-management hash alongside MD5.
Pick one variant and print it on every packing list. XXH3-128 is the one to standardise on for masters unless a vendor has already named MD5 in a delivery spec. If they have, ship both. Computing two hashes is cheaper than a recall.
A checksum is not a vibe. Same algorithm, same file, same digest. Different algorithm, different digest, argument. Name the algorithm in the manifest, not just the hex string.
Store the digest next to the file, not inside a filename you will later rename. A sidecar or a single MANIFEST.csv for the bag is enough. Hash the media files, not only the zip. If you zip for transport, hash the zip too, then hash the members after unzip.
When to pay for Aspera, Signiant, or MASV versus a drive
Speed is not the criterion. Proof, resume, and who is on the other end are.
| Situation | Pipe | Why |
|---|---|---|
| Review cut, a few GB, named recipient | Consumer link plus a hash sidecar | Fine for picture. Not an archive. |
| Ad-hoc master, tens or hundreds of GB, non-technical recipient | MASV-class portal | Built for terabyte-scale media, with retry and encryption in flight and at rest. MASV publishes SOC 2 Type II, ISO 27001:2022, and TPN membership. |
| Recurring studio-to-vendor, files land on your storage | Signiant Media Shuttle | Point-to-point into on-prem or object storage. Checkpoint Restart resumes an interrupted transfer. CloudSpeX can pre-validate format, aspect ratio, and frame rate before the file is accepted. |
| Long-haul, high latency, huge volumes, IT already in the room | IBM Aspera | FASP is a UDP-based transport IBM describes as keeping line-speed throughput when TCP collapses over distance and loss. The ascp client can resume against a full-file checksum (-k 3). |
| Multi-terabyte bag, air-gap, or a WAN that will not make the date | Physical drive | Checksum before it leaves. Checksum on arrival. Courier tracking on the crate, not the file. |
Do not mix pipes for one bag. A master on Aspera and its sidecar on email is how the sidecar gets lost and the master gets "verified" by opening it.
A physical drive still wins when the data is larger than the week you have, or when the client will not put the file on a third-party network. Treat the drive as a copy, not the archive. Your checksummed original stays put until the far-end hash matches.
The packing list
This is the document that leaves with the files. One row per media file. One extra row for the bag (zip, disk image, or folder). CSV beats a PDF, because the far end can check hashes against it without retyping hex.
| Column | Example | Rule |
|---|---|---|
| shot_id | sc03_sh020 |
Stable ID you minted. Never the generator's filename. |
| filename | acme-launch_sc03_sh020_v012_pic.mov |
The name on disk, after your rename. |
| bytes | 3847291024 |
Exact byte size. |
| hash_alg | XXH3-128 |
Named. |
| hash | (hex digest) | Lowercase hex of the whole file. |
| container | mov |
|
| codec | prores_422 |
Finishing codec, not the model's MP4. |
| width_height | 1920x1080 |
From the file, not the brief. |
| fps | 25 |
Versely timelines default to 25. Confirm the file. |
| duration_tc | 00:00:08:00 |
|
| color_tag | bt709 |
Empty if untagged. Do not invent a tag. |
| audio | pcm_48k_24b_2ch |
|
| hashed_at | 2026-08-21T14:02:11Z |
ISO 8601. |
| role | online |
review, online, or archive. |
Before you send:
- Rename into your grammar. Generator download names do not survive a regen.
- Confirm dimensions and duration on the real file, not the filename. The video metadata inspector does that in the browser and never uploads; it will not give you a trustworthy frame rate, so use ffprobe when fps is load-bearing.
- Check whether the bag will even fit the pipe with a file size calculator if you are still on a consumer cap.
- Hash. Write the manifest.
- Copy. Hash the copy. Only then point a transfer tool at the copy.
- On arrival, the recipient hashes again and diffs against the manifest. A mismatch is not "try playing it." It is a failed delivery.
Keep the generation record in the same bag: model name, date, and the shot_id. Saving takes into one project as you generate is how that record exists when you pack. The handoff around codec and frame rate is in handing generated clips to a human editor. Provenance that has to survive the client's own transcode belongs in a metadata preservation clause, because a perfect hash of a file whose credentials were stripped on ingest is still a compliance gap. What actually happens to a C2PA binding through trims and re-encodes is in sign, strip, survive.
The UGC version of "the folder has to be usable" is a delivery spec that earns repeat orders. This packing list is the finishing version of the same idea: the far end can verify without calling you.
FAQ
Does a matching hash mean the picture is the right shot?
No. It means those bytes are the bytes you hashed. If you hashed the wrong take, the far end now has a perfect copy of the wrong take. The shot_id and a still or reference movie in the bag are what stop that. Hash after you pick, not after you download.
Should I hash the zip or the files inside it?
Both, if you zip. The zip hash tells you the bag survived the pipe. The member hashes tell you the unzip on the far machine produced the same files you packed. Zip tools are not identical across OS versions. Trust the members.
Is MD5 ever the right answer?
Yes, when a facility spec names it. Compute MD5 for them and XXH3-128 for you. Do not argue cryptography with a delivery QC sheet. Do not use MD5 as your only hash on a multi-terabyte bag if you have a choice: it is the slow option, and it is the one whose collision story is public.
What if the client will only accept a WeTransfer?
Send a review copy on WeTransfer. Put the master on whatever pipe you can both operate, even if that is a drive. If they insist the WeTransfer is the master, attach the packing list, make them return the hash they computed, and write "unverified if hash not returned" on the delivery log. The log is what you have when the file that went live is not the file you sent.