Court Audio Chain of Custody: Preserve the Original, Work From a Copy

A court recording arrives on a disc, a thumb drive, or a download link. The natural first move is to open it, rename the files, and convert whatever will not play.

That is the wrong order.

The first job is preservation. Before the audio becomes a WAV, a transcript, a clip, or an exhibit, somebody should be able to answer five plain questions: What did we receive? Where did it come from? Who handled it? What did they do? Can we show that the preserved source has not changed since intake?

The working rule is simple:

Preserve the complete source package. Do every review, conversion, cleanup, and export from a documented copy.

Simple does not mean casual. A hash without a handoff record is incomplete. A perfect folder structure cannot establish who supplied the files. And a technically careful workflow does not, by itself, satisfy every court’s evidentiary or records-management requirements.

First, a boundary: preservation practice is not a legal conclusion

People often use chain of custody to describe any organized file-handling process. In court, the term can carry more weight. It may involve testimony, authentication, agency procedure, a discovery agreement, a court order, or jurisdiction-specific law.

This guide describes good technical preservation and accountability practices for court audio. It is not legal advice, a forensic-acquisition protocol, or a promise that a recording will be admitted into evidence. Follow the controlling court, agency, firm, client, retention, and litigation-hold rules. When authenticity is disputed, the physical device itself matters, or a forensic image is required, stop and involve qualified counsel and a trained digital-evidence examiner.

The current Federal Rules of Evidence are a useful illustration, not a universal answer. Rule 901 asks for enough evidence to support a finding that an item is what its proponent claims. Rules 1001 through 1003 separately define originals and duplicates and address when duplicates may be admitted. State rules, local court rules, administrative procedures, and the facts of the case may differ.

An unchanged hash helps answer one technical question. It does not decide authentication, admissibility, or whether the recording is the official record.

The two records you are building

A controlled workflow preserves two related records:

1. The source record: the media, files, folders, metadata, sidecars, manifests, and other material received.
2. The handling record: who received it, when and how it arrived, every material action taken, every transfer, and every exception.

The first protects the content. The second makes the handling explainable. You need both.

The NIST guide to digital-evidence preservation makes the underlying problem clear: digital data is easy to change, but there are techniques for preventing and detecting change. The goal is not to make the workflow sound forensic. The goal is to make it controlled, repeatable, and honest about its limits.

1. Assign an owner before touching the files

One named person should own intake. That person does not have to perform every later step, but they should confirm the applicable procedure and make sure the first record is created.

Before opening the media or download, determine:

• the matter or request identifier;
• who supplied the recording and under what authority;
• whether a litigation hold, protective order, confidentiality term, or agency policy applies;
• where the preserved source is allowed to live;
• who may access it;
• whether the source media must be returned; and
• who must be notified if the package is incomplete or damaged.

If nobody owns those questions, software will not fix the gap.

2. Inventory the intake before playback

Record what arrived as it arrived. For physical media, photograph or transcribe the label and note the media type, visible condition, serial number or other identifier when one exists, and packaging. For an electronic delivery, retain the original delivery notice or email according to policy and record the sender, link or service, and the time the download occurred, including the time zone.

Create an intake inventory that includes:

• matter ID and a unique item ID;
• source person, court, agency, or system;
• receiving person;
• date and time received, with time zone;
• transfer method;
• original filenames and relative folder paths;
• file sizes and visible timestamps;
• the number and type of physical media, archives, folders, and files;
• any passwords, access instructions, or expiration dates, stored securely rather than pasted into a general log; and
• anything unexpected, missing, damaged, or unreadable.

Do not assume the biggest audio-looking file is the whole production. A court-audio package may include channel maps, timestamp data, annotations, playlists, indexes, session files, export reports, checksums, or other sidecars needed to interpret the recording. Preserve the directory structure and the entire delivered package unless the controlling procedure explicitly requires a narrower collection.

If the delivery is a ZIP or another archive, preserve the archive itself first. Extract a separate copy for work and inventory the extracted contents without treating the extraction as the untouched source.

3. Protect the preserved source

Copy the complete intake into controlled storage with a documented method, then restrict routine access to it. Keep the physical media secured if policy requires it, but do not let an aging disc or thumb drive remain the only copy.

When the source can be read safely, calculate a SHA-256 hash from each source file before or during the copy and compare it with the corresponding file in controlled storage. A match verifies the bytes that were copied; a mismatch means the destination is not a verified preservation copy. Stop, retain both states, record the tool, time, operator, error, and affected paths, then follow the controlling exception procedure before making a new acquisition. If source hashing is not possible, document why and establish the first protected baseline immediately after acquisition without claiming that it proves an earlier state.

Where practical and appropriate, use a validated write blocker or a read-only acquisition method when reading writable source media. SWGDE, Best Practices for Computer Forensic Acquisition, 17-F-002-2.1 (August 5, 2025) says examiners should understand and minimize the effect of the chosen acquisition method on the source, document alterations that cannot be prevented, and use hardware or software write blockers when possible.

Do not treat a folder’s “read only” checkbox as write protection. On Windows, the read-only file attribute is not honored on directories. Use the approved storage permissions or read-only acquisition method, and verify its write restrictions with a disposable test file before handling the source. Those controls are not automatically a validated forensic write blocker. A normal file copy is not automatically a forensic image, either. If deleted data, hidden areas, device metadata, or the storage medium itself could matter, this guide is no longer enough.

September 4, 2026 correction: the original paragraph incorrectly called a folder’s read-only attribute a helpful protection. The distinction above follows Microsoft’s documented Windows behavior.

For ordinary court-audio operations, the preserved source should be:

• complete;
• access-controlled;
• protected from routine editing;
• backed up to an approved second location; and
• clearly separated from working files and deliverables.

NIST recommends retaining the format that contains the most data and, when necessary, also preserving an open-format version for access. That is the right mental model for proprietary court audio: keep the source container and its companion material even when you create a standard-audio derivative.

4. Create a hash baseline — and describe it accurately

A cryptographic hash is a repeatable fingerprint calculated from a file’s bytes. Compute a SHA-256 hash for every preserved source file as close to intake as practical. When a source-side hash was available, record both values and the comparison result. Record the hashing tool and version, the person who ran it, the date and time, and the result in a manifest that includes each file’s relative path.

Store that manifest somewhere an ordinary user who can edit the evidence cannot silently overwrite it. NIST specifically cautions that evidence could be changed before it is hashed, or changed and re-hashed if the stored hash is not protected. NIST also recommends moving away from SHA-1; its hash-functions guidance lists the approved SHA-2 and SHA-3 families and explains SHA-1’s deprecation.

What a matching SHA-256 hash supports:

• the file being checked has the same bytes as the file used to create the recorded baseline; and
• two copies with matching hashes are, for practical integrity-verification purposes, byte-for-byte copies of one another.

What a hash does not prove:

• who created the recording;
• when or where it was recorded;
• that the package was complete when supplied;
• that nobody changed it before the first trustworthy hash;
• that the voices are correctly identified;
• that the audio accurately captures the proceeding; or
• that a court will authenticate or admit it.

That is why “we hashed it” is not a chain of custody. It is one control inside a larger human process.

5. Make a working copy with an obvious boundary

Never review or convert in the preserved-source directory. Create a new working copy and make the boundary visible in the folder names:

matter-2026-0147/
  00-intake-record/
  01-preserved-source/
  02-working-copy/
  03-derived-exports/
  04-process-and-handoff-logs/
  05-delivery/

Use your organization’s naming convention; the exact numbers do not matter. The separation does.

The working copy can be renamed for usability, but keep a mapping from each working name back to its original relative path and hash. Do not put confidential party names into filenames merely for convenience if the organization’s security model uses non-identifying matter IDs.

When the working copy is created, compare its hashes to the preserved-source manifest before processing. That creates a clean starting point for the work.

6. Convert and export without rewriting history

Proprietary containers and multi-file recording packages create a real access problem; I wrote a separate plain-English court-recording format guide about that friction. Conversion is often necessary. It is still a transformation, and the result should be labeled as a derivative rather than quietly replacing the source.

For every conversion or export, log:

• the input item IDs, filenames, and hashes;
• the application and exact version used;
• the operator;
• the date and time, with time zone;
• the output format and settings;
• any channel selection, split, merge, ordering, or naming decision;
• warnings and errors;
• the output filenames and hashes; and
• the purpose of the derivative.

Do not write “lossless” simply because the output is WAV or because no intentional compression was selected. A decoded or rewrapped file may preserve audio samples while changing container structure, metadata, channel layout, or timing information. Say what the process actually did and verify the result.

DepoAudio can make local conversion more practical, and its on-device design avoids an unnecessary upload. It is not a forensic-acquisition tool, evidence-management system, or substitute for an organization’s chain-of-custody procedure. Use it — or any converter — only within the approved workflow, and retain its process details alongside the derivative.

7. Verify content, not just files

Hash verification tells you whether a particular file changed. It does not tell you whether the conversion produced the right operational result.

After conversion, verify and document:

• the expected number of recordings, sessions, and segments;
• approximate duration and the beginning and end boundaries;
• the number and order of channels;
• known speaker or microphone assignments, only when supported by the source material;
• whether channel separation, merges, or level changes occurred;
• a playback check across the beginning, middle, end, and any known problem area;
• gaps, truncation, clock or timestamp issues, decode warnings, and silent channels; and
• whether the output can be reopened in the intended review environment.

Input and output hashes should normally differ after a conversion because they are different files. Do not compare them as if a match were expected. Instead, retain the input baseline, hash the derivative, record the transformation, and perform a content check appropriate to the assignment.

This is part of the broader digital court-reporting workflow: capture, preservation, draft, review, certification, and delivery are related stages, but they are not interchangeable. A playable export is not a certified transcript, and a transcript is not a replacement for the preserved audio.

8. Treat every handoff as an event

When custody or control changes, add a handoff entry. At minimum, record:

• the unique item or package ID;
• the sender and recipient;
• the date and time, with time zone;
• the transfer method;
• the purpose of the transfer;
• which source or derivative files were included;
• the applicable hash manifest;
• access or confidentiality restrictions; and
• confirmation that the recipient received the package and verified the expected hashes.

Use approved encrypted storage and transfer systems. Send passwords or decryption material through a separately approved channel, and make sure retention plans include the keys needed to retrieve encrypted evidence later. Convenience links, personal cloud drives, and untracked email attachments create extra copies and extra questions.

9. When something goes wrong, stop making it look clean

A hash mismatch, missing sidecar, unreadable segment, unexplained modification time, incomplete download, or failed export is not an invitation to quietly try again until the folder looks right.

Stop work on the affected copy. Preserve its current state. Record the exact error, time, operator, application, and action that produced it. Return to a verified working copy made from the preserved source when appropriate, and notify the evidence custodian, counsel, client, security lead, or court contact required by policy.

If a corrected or replacement production arrives, give it a new intake event and baseline. Do not overwrite the old package under the same identity. The exception record is part of the record.

10. Retain, check, migrate, and dispose by policy

Retention is not “keep it forever” and it is not “delete it when the transcript ships.” Follow the applicable retention schedule, litigation hold, court rule, client instruction, contract, and disposal authorization.

For long-lived material:

• maintain approved backups in a location that does not share the same likely failure;
• periodically verify stored hashes;
• monitor storage media and file-format obsolescence;
• document migrations to new storage or accessible formats;
• retain the original source package alongside derivatives when required; and
• preserve encryption keys and the ability to read the audit record.

The human owner should be visible at every stage. Automation can inventory files, calculate hashes, and write logs. It cannot decide whether the right proceeding was delivered, explain an undocumented gap, identify a voice without a foundation, or accept responsibility for a certified record. That is the same principle behind building court-reporting technology from inside the workflow: the tool should support professional judgment, not impersonate it.

Printable court-audio preservation checklist

Authority and intake

• Identify the controlling court, agency, firm, client, hold, and retention requirements.
• Assign a named intake owner and unique matter/item ID.
• Record the source, receiver, transfer method, date, time, and time zone.
• Photograph or describe physical media, labels, packaging, and visible condition.
• Preserve the original delivery notice or electronic transfer record according to policy.
• Inventory every archive, folder, file, relative path, size, and visible timestamp.
• Record missing items, damage, expired links, password issues, and other exceptions.

Preserve the source

• Preserve the complete delivered package, including sidecars and companion files.
• Use write protection or read-only acquisition where practical and appropriate.
• Store the preserved source in access-controlled, approved storage.
• Create an approved backup that does not share the same likely failure.
• Calculate and protect a SHA-256 manifest as close to intake as practical.
• Record the hashing tool/version, operator, date, time, and time zone.

Work from a copy

• Create a separate working copy and verify it against the source manifest.
• Keep a mapping between original names and any renamed working files.
• Never convert, clean, clip, normalize, or annotate inside the preserved source.
• Log the converter/tool version, settings, operator, inputs, outputs, and errors.
• Record channel splits, merges, ordering, naming, and other transformation choices.
• Hash derivatives and label them as derivatives rather than replacements.
• Verify sessions, duration, boundaries, channels, playback, and known problem areas.

Handoff and exceptions

• Record sender, recipient, item ID, purpose, files, hashes, date, time, and time zone.
• Use approved encrypted transfer and communicate keys through an approved separate channel.
• Obtain receipt confirmation and hash verification from the recipient when required.
• Stop and document any mismatch, missing component, playback failure, or unexplained change.
• Treat corrected or replacement material as a new documented intake event.
• Retain, migrate, and dispose only under the controlling policy or authorization.

Keep the source boring

The best preservation workflow is not dramatic. The preserved source stays untouched. The working copy absorbs the mess. Every derivative says where it came from. Every handoff has a name and a time. Every exception remains visible.

That does not answer every evidentiary question. It does something more useful at the operational stage: it gives the professionals who will answer those questions a record they can actually explain.

Sources and further guidance

• NIST IR 8387, Digital Evidence Preservation: Considerations for Evidence Handlers
• Federal Rules of Evidence, effective December 1, 2025
• SWGDE, Best Practices for Computer Forensic Acquisition, 17-F-002-2.1, August 5, 2025
• NIST Hash Functions project
• Microsoft, File Attribute Constants

Original source review: August 21, 2026. Microsoft directory-attribute correction checked September 4, 2026. Procedures and rules change; confirm the current version before relying on them.