Audio provenance & tamper forensics · file-borne seals

attest

Proof a recording is what it claims to be.
Chain integrity
Duration
Slices in chain
Sample rate
Decoded samples
Altered slices
Sealed at

Time ledger · signal field

particle density · brightness = loudness
00:00
Signal density · whole recordingloudness per slice
0:00.00:00.0
Select a slice on the chain, then re-cut it to test the seal.
Verified — chain intact The whole recording is covered by one root.
Provenance root · SHA-256sealed

Merkle Link analysis — one root for the file

every slice folds inward to a single seal
covered by the seal no longer matches fingerprint tone

Checks Forensic checks · multi-method authenticity

Illustrative demonstrations of established audio-forensic methods, derived from this recording's own per-slice data. Real deployments add external references — a power-grid frequency archive for ENF, a trained anti-spoofing model for synthetic-voice detection. The Merkle hash-seal above remains the definitive integrity check.

Electric network frequency (ENF)illustrative
Acoustic noise-floor consistencyillustrative
Codec & double-compression historyillustrative
Synthetic-voice likelihoodillustrative
anti-spoofing score (ASVspoof-style)

Manifest Slice register

click a row to inspect
# Time Fingerprint Loud. Status

Pass Provenance pass

held with the file

Held with the file, not asserted by it. Only what you enter, plus what the audio itself measures.

Article 50, EU AI Act asks that synthetic or manipulated media be disclosed to the people who meet it. A provenance seal is one way to let a file carry that disclosure on its own — verifiable slice by slice.

Note What Attest does

From sound to seal

Attest reads the actual decoded samples of a recording, cuts them into slices along the timeline, and takes a SHA-256 fingerprint of each slice. The fingerprints are then linked two ways.

1Slice. The waveform is cut into equal spans of time. Each becomes one entry in the manifest.
2Fingerprint. SHA-256 turns each slice into a fixed hash. Its bytes set the slice's stacked band mix, so the chain reads as a spectrum of fingerprints.
3Chain. Each fingerprint is folded into a running hash of the one before it, so order is sealed in, not only content.
4Root. The fingerprints also pair upward through a Merkle tree to one root hash — the file's single seal.

Re-cut one slice and its fingerprint changes. The manifest flags that slice, the running chain diverges from that point on, and the path from the slice up to the root turns over — the whole seal no longer matches. Nothing is guessed: every verdict is a fresh SHA-256 comparison against the sealed manifest.

Why slice-level and not one yes/no

A single verdict for a whole file answers only whether something changed. A per-slice manifest answers where — which seconds were re-cut, spliced or replaced, and which are still covered by the original seal. That is the difference between an alarm and a record.

Every sound carries its papers.