One cutoff is not enough

There's a quiet fraud running through digital music collections. Take a 128 kbps MP3, decode it, re-encode it as FLAC, and you have a file that passes every integrity check, plays perfectly, and occupies lossless-sized disk space — while everything the MP3 encoder threw away stays gone forever. These files circulate in download stores, shared libraries, and collections people have spent years and real money building. The container says lossless. The signal says otherwise.

I spent the last several months building a Windows tool, Sunara Reference, that reads the signal. This is the story of how it works, why the obvious approach wasn't good enough, and what I measured along the way — including the detector I had to delete.

The obvious approach, and why it convicts the innocent

Almost every existing checker does one thing: it looks at where the spectrum stops. Lossy encoders apply a low-pass filter whose corner depends on bitrate, so a FLAC whose content dies at 16 kHz is suspicious. Some tools make you eyeball a spectrogram yourself; others automate the threshold. Either way, it's a single measurement.

And here's the thing — it mostly works. Codec low-pass filtering is real and it's the loudest artifact a transcode leaves behind. If catching fakes were the whole job, a cutoff check would nearly finish it.

The problem is the other half of the job. Plenty of genuine recordings also stop early: old masters, analog tape sources, deliberate mastering filters, quiet acoustic material that simply never produced much energy up there. To a cutoff-only detector, a beautifully preserved 1970s recording looks exactly like an MP3. Anyone who has run their own rips through one of these tools and been told their originals are fake has met this failure mode personally.

Any detector can catch fakes if it's allowed to accuse innocent files. The actual engineering problem is catching fakes without doing that. That reframing drove every decision that followed.

Codecs leave more than one fingerprint

A lossy encoder doesn't just truncate the spectrum. It quantizes, switches block sizes, shapes noise according to a psychoacoustic model, and reconstructs high-frequency content it decided not to store. Each of those operations leaves its own residue in the signal, and critically, the residues are independent — a genuine recording might mimic one of them by coincidence, but mimicking all of them at once is much harder.

So instead of one detector, Sunara Reference runs five, grouped into three evidence families.

Cutoff behavior — not just where the spectrum ends, but how. One detector tracks the effective high-frequency edge block by block through the entire track. A codec's low-pass filter sits perfectly still; natural roll-off wanders as the music changes. Position plus stability turns out to be far more informative than position alone. A second detector builds a median spectrum for the whole track and hunts for a cliff — a drop too steep and too deep to be acoustic. On my test material, that cliff detector fires on roughly 98% of transcodes and only about 7% of genuine files. It is a superb fake detector. It is also precisely the detector that would convict old genuine masters if it were allowed to work alone — which is the whole argument for what comes next.

High-frequency texture — what the surviving HF content looks like statistically. This family taught me the most humbling lesson of the project. My starting assumption was that lossy reconstruction would leave flatter, more noise-like high frequencies than a real recording. The data said the opposite: in the band I was measuring, genuine files were consistently the flatter ones, while transcodes showed sparse, patchy HF — missing bins, unevenly distributed energy, the fingerprint of a codec deciding some of that band wasn't worth spending bits on. I had the sign backwards. The detector works well now, but only because I let the measurements overrule my intuition. After that, every threshold in the app had to come from data, not from what sounded plausible.

Temporal dynamics — how the HF region behaves over time. Quantization and block switching leave a characteristic frame-to-frame jitter in spectral magnitudes, so one detector measures per-bin variance of the frame deltas. It's very effective on MP3 material and noticeably weaker on AAC — which makes sense, because AAC's temporal noise shaping smooths exactly the artifact being measured. A second detector examines how consistent the spectral structure near the cutoff region stays between adjacent frames; lossy HF tends to be unnaturally repetitive there, while real HF evolves.

No single one of these is trustworthy alone. That's not a weakness of the design — it is the design.

Making detectors admit what they don't know

Every detector in the engine reports two numbers, not one: a verdict from 0 to 1, and a reliability — how much this detector should be trusted on this particular file.

That second number matters more than it sounds. Hand a quiet solo-piano track to the edge-tracking detector and there's barely any HF energy to track; the honest answer isn't "fake" or "real," it's "I couldn't see much." Reliability lets a detector say exactly that, and the fusion layer listens: weak or unreliable verdicts get softened toward neutral so they can't dominate a decision they have no business dominating.

The fusion itself is built on one asymmetric principle: artifacts prove fake, but the absence of artifacts does not prove real. A codec cliff at 16 kHz with matching texture evidence is damning. A clean spectrum proves only that nothing was found. So declaring a file fake requires strong evidence from one family with support from another, while declaring it genuine requires broader agreement across families. And when the families genuinely conflict, the engine doesn't average its way to false confidence — it pulls the score toward the middle and labels the file Borderline.

I consider that label a feature, not an apology. A tool that admits uncertainty on the hard 5% is more useful than one that confidently coin-flips them.

The detector I killed

Not everything survived. One hypothesis I liked a lot: in real music, low-frequency and high-frequency energy should move together — a drum hit excites the whole spectrum — and lossy coding might disturb that coupling. I built it twice: first on absolute band energies, then on frame-to-frame energy dynamics with several supporting features.

The evaluation was unambiguous. Genuine files and transcodes were statistically indistinguishable on every variant — balanced accuracy around 50–52%, a coin flip. Lossy codecs preserve broadband energy envelopes almost perfectly; the damage lives in fine spectral structure, not in how loud the bands are relative to each other. No amount of threshold tuning fixes a feature that doesn't separate the classes.

So it was deleted. It cost real evenings and it produced nothing, and I'd make the same trade again — because every detector that stayed had to clear the same bar, and now I know the bar means something.

Testing honestly

Numbers are easy to inflate with a friendly dataset, so the dataset was designed to be unfriendly. I started with 101 genuine hi-res FLACs, then created the fakes from those same 101 files: transcoded through MP3 192, MP3 128, and AAC 160, then re-encoded to FLAC. Four conditions, 404 files, and — this is the important part — identical music on both sides of every comparison. A paired design means the engine can't cheat by learning that a genre or a mastering style correlates with fakeness. It has to find the codec, not the music.

Results, per condition:

The misses are instructive. They cluster in content edge cases — a sparse choral recording, an old film song — where cutoff evidence is genuinely weak and the HF region is legitimately ambiguous. Those files mostly land in Borderline rather than being confidently misclassified, which is the system behaving as designed.

Two caveats I insist on making myself. First, these are controlled conditions: four codec configurations, one collection of source material, fakes that I manufactured. The wild contains more codecs, more bitrates, and stranger masters, and real-world accuracy will differ. Second, the 0-to-1 score the app reports is a confidence value, not a calibrated probability. A score of 0.8 does not mean an 80% chance of fake, and I refuse to use probability language until I've done proper calibration on held-out data — which is on the roadmap, because for the professional uses this engine is headed toward, a defensible probability is worth far more than an impressive-sounding one.

What I'm not publishing, and what's next

I've described what every detector measures and why the fusion works the way it does. I'm deliberately not publishing the exact features, thresholds, and weights — the tuned combination is the commercial core of this work. But the architecture is the part worth sharing anyway: independent evidence families, per-detector reliability, asymmetric fusion, and an honest Borderline class. None of that is specific to fake FLAC detection. It's a general recipe for building classifiers that know when to shut up, and it transfers directly to harder audio-authenticity and QC problems — which is where this engine goes next.

The desktop app is free: Sunara Reference — aloosoft.com/products/sunara-reference/ And if you have a signal problem that involves extracting trustworthy decisions from messy data, that's the work we do at Aloosoft: aloosoft.com/contact/