Did the audio file arrive unchanged? Keep a checksum beside the listening check
When an editor receives an audio file, two questions need separate answers: did the expected file arrive unchanged, and does it contain the right audio? A checksum helps with the first question. It does not answer the second.
The Canadian Heritage Information Network's digital-preservation guidance explains fixity: applying the same algorithm to unchanged file contents produces the same checksum, while a content change is overwhelmingly likely to produce a different one. Its examples concern preservation practice. Here we apply that principle to a small, explicitly identified audio handoff.
Download the integrity and listening acceptance ledger. It records a SHA-256 comparison separately from the recipient's listening result. No file is uploaded to SoundBuddy.
Identify the exact deliverable first
Choose a final listening file or agreed editing asset, not an open project that is still changing. Record its revision name and purpose. Calculate its checksum after the intended export and metadata changes are finished, before transferring it.
A recipient who receives a newly encoded MP3 cannot compare it with the checksum of your original WAV and expect equality. They are different files. Even an intentional metadata edit can change file bytes without changing the passage you hear. Record a new approved revision when that happens; keep the earlier record rather than replacing history silently.
| Observation | What it supports | What still needs checking |
|---|---|---|
| Expected SHA-256 equals received SHA-256 | Strong practical evidence that the compared file bytes match | Identity of the expected reference and intended audio |
| Checksums differ | The compared byte sequences differ | Wrong revision, conversion, metadata change or transfer problem |
| Checksum matches but a voice is missing | The received copy matches that reference | Whether the source deliverable met the brief |
| File plays but no reference exists | The player opened that copy | Whether it is the intended unchanged deliverable |
Keep the expected checksum in a channel or record you trust. A hash supplied alongside an unknown file is not, on its own, proof of its author or authenticity. This article covers practical integrity comparison, not digital signatures or forensic certification.
A local SHA-256 check on Mac
For readers comfortable with Terminal, the shasum documentation explains selecting an algorithm with -a and reading files in binary mode with -b. On the Mac used to prepare this guide, /usr/bin/shasum is available. Check the tool on your own machine rather than installing an unrelated utility from an advertisement.
An example command, for a file in the current Terminal folder, is:
shasum -a 256 -b -- "interview-final-r1.wav"
The filename is an example. Use your actual file path and keep quotes around paths containing spaces. The double hyphen ends command options. This command reads the named file and prints a checksum; it does not play, repair or transfer it. If the file is elsewhere, use its actual path rather than assuming Terminal is in Finder's current folder.
Run the same command against the received copy. Compare the complete hexadecimal checksum, not only its first few characters. A filename printed after it identifies the local path used; source and destination paths can differ while the hash matches.
If the result differs, preserve both copies
Do not overwrite the received file or regenerate the expected checksum from it just to get a match. Confirm the reference filename and revision first. Ask whether the delivery workflow changed format, edited metadata or supplied a preview instead of the original.
If the expected unchanged download can be obtained again, save it separately and repeat the comparison. Record what changed. If a deliberate new render is now the approved deliverable, give it a new record and checksum. An unexplained mismatch should remain unresolved.
Why a matching checksum still needs a content check
The 2021 IASA paper Audiovisual Quality Control and Preservation Case Studies from Libraries, Archives, and Museums, by Julia Kim and colleagues, describes an archival transfer where checksums matched but some video files still had playback problems. The reference bytes had already been affected earlier in the workflow. That case supports keeping integrity and content checks separate; it does not measure failures in ordinary audio handoffs or validate our template.
Finish with listening acceptance
The recipient should still open the intended file, check the beginning and ending, and confirm the required voices or channels. Record that separately from bytes matched. For separate OBS sources, use the recording-track map. For an editable Logic project, inspect which assets travel with it before treating one audio checksum as a project-level check.
We checked this command locally using a generated silent WAV fixture, an unchanged copy and a deliberately changed copy. The unchanged bytes matched; the altered bytes did not. That narrow fixture check does not demonstrate a real interview transfer, sound quality, storage-device reliability or recipient delivery.
SoundBuddy does not hash or certify recordings. Stop when the expected reference is identified, the byte comparison is recorded and the intended listener has independently accepted the content. Keep all three observations visible in the handoff record.