Systems and subsystems

Compression forensics

Nineteen features that read the traces a lossy codec leaves in the upper band, trained with both classes laundered so the model cannot learn that MP3 means a particular generator. It detects codec history well and the class barely, so it is evidence and routing, never score.

In plain words

Compression forensicsFeatures that read the traces a lossy codec leaves in the upper band: spectral holes, floor depth, effective bandwidth. They describe a file's processing history, not the voice, so they are evidence and routing here.: a codec leaves holes and floors in the spectrum. On our training data the fakes from two commercial generators arrive as MP3 and the real speech does not, so a naive compression detector would score perfectly by reading the format. We re-encode (launderPassing audio through a codec round-trip, band-limit or added noise. Attackers do it to hide artifacts; we do it to both classes in training so a detector cannot learn "compressed means fake".) a random half of both classes before training, which leaves it nothing to learn but the actual traces. What it then finds is that the whole test set reads as laundered, which says something about how the test set was made and nothing about which files are fake.

What goes in and comes out

In: the prepared clip. Out: the 19 features and a probability from trees, a sentence such as compression-trace features synthetic-like (P=0.97): whole-clip floor depth 1.7 SD below real speech (toward synthetic); …, and the routing fact of the clip's effective bandwidth.

Where it lives

Features and laundering in compression.py; the detector in detectors/compression.py; extraction in extract_compression.py; trained by the same trainer as the handcrafted detector with its own prefix.

Parameters and where each is set

• Analysis: 1,024source: src/hearsay/compression.py line 35 (GitHub; assumes main is public)-point frames; the hole band 3,000source: src/hearsay/compression.py line 40 (GitHub; assumes main is public)–7,000source: src/hearsay/compression.py line 40 (GitHub; assumes main is public) Hz; a deep hole is 75 dB below the clip's peak and a local hole 30 dB below the frame's band median (compression.py, lines 35–40).
• The 19 features: effective bandwidth (the highest quarter-kilohertz band from 3 kHz up within 40 dB of the 1–3 kHz level), four band levels from 4 to 8 kHz relative to 1–3 kHz, the high-band slope, eight deep- and local-hole statistics (fraction, flicker, persistence, runs), and five floor statistics including the valley depth and the low-band floor (compression.py, lines 46–102).
• Laundering: an FFmpeg encode as MP3 (three times in four) or AAC at a bitrate from 24source: src/hearsay/compression.py line 42 (GitHub; assumes main is public) to 128source: src/hearsay/compression.py line 42 (GitHub; assumes main is public) kbps and an encode rate of 16,000source: src/hearsay/compression.py line 43 (GitHub; assumes main is public), 22,050source: src/hearsay/compression.py line 43 (GitHub; assumes main is public) or 44,100source: src/hearsay/compression.py line 43 (GitHub; assumes main is public) Hz, decoded back to 16 kHz (compression.py, lines 41–147); the training run laundered half the rows, drawn per row from a seeded generator.
• Routing: the runner reports the bandwidth against the 7,250source: src/hearsay/pipeline.py line 618 (GitHub; assumes main is public) Hz band match, and the container's facts decide whether the result is "run for evidence" or "applies" (pipeline.py, lines 605–619).

Status

Built and exported; evidence and routing only, by the leave-one-out rule set in the plan.

Numbers

Codec history: AUC 0.90source: README.md, section what-worked–0.94source: README.md, section what-worked. Class: inner 0.931source: README.md, section numbers, holdout 0.900source: README.md, section numbers (EER 20.1%source: README.md, section numbers); it calls 80.7%source: README.md, section numbers of the test set synthetic because the test set reads as laundered throughout (mean P(laundered) 0.62source: README.md, section what-did-not-work). Bandwidth inventory of the test set: 981source: README.md, section orchestration-what-routing-changes files at 7,250source: README.md, section orchestration-what-routing-changes Hz, 670source: README.md, section orchestration-what-routing-changes at 7,500source: README.md, section orchestration-what-routing-changes Hz, 12 full band, 8 at 5–7 kHz.

Known limits

It describes a file's processing history, not the voice. The codec hunt found that the test set's wall is not an MP3 or AAC round-trip at any tested setting, so its "laundered" reading of the test set is a low-pass signature rather than a codec's. A comment in the module names a 3–8 kHz median where the code uses 3–7 kHz.

Tests that pin it

tests/test_compression_detector.py: features finite and matching their labels, the band match pulls the effective bandwidth below the cutoff, laundering leaves traces (needs an MP3 encoder), an unknown codec is rejected, draws are reproducible, the contract, direction, the sentence names traces and standard deviations, memoization, a missing model is an error, registration, the scripts exist. tests/test_pipeline.py pins the 7250 Hz routing line.

Sources

The CPU detectors report, "Compression forensics detector"; the codec hunt; Architecture §7.