How We Became S.O.T.A. on the Podonos Independent Deepfake Detection Benchmark

A technical write-up of the result behind our first-place commercial latency on the Podonos audio deepfake detection benchmark.

Podonos runs a public benchmark for audio deepfake detection, built to replace self-reported scores with verifiable ones. It hosts a fixed evaluation set, holds the labels privately and computes the scores itself. The September 2026 board covers 23 systems.

Detectif.ai reported the lowest mean latency of any commercial system with published timing: 24 ms per clip, or 119× faster than real time. Podonos scored the same entry at 94.47% accuracy across all 4,524 files, with 97.3% of deepfakes detected. This article documents what the benchmark measures, how those numbers read together, and where the result stops.

Official benchmark write-up: Podonos.

That split between scored numbers and reported numbers runs through everything below.

The Problem

A deepfake score has one job on a call: arrive while the decision is still open. Once a caller has been verified and the action has gone through, a late score is a forensic record, not a control.

So two measurements matter together. The benchmark publishes both:

accuracy         = correct files / files scored
real-time factor = processing time / audio duration
processing speed = 1 / real-time factor

Lower is better for the real-time factor. At 1.0, a system takes as long to analyze a clip as the clip takes to play.

Our reported factor was 0.0084, which is a processing speed of 119× real time.

The Test Set

The evaluation set is fixed and every entrant answers the same files:

• 4,524 audio files across six formats: MP3, WAV, FLAC, OGG, M4A and WebM,
• an even split between genuine and synthetic speech,
• genuine speech from three public corpora: VCTK, LJ Speech and LibriTTS,
• synthetic speech from about 25 text-to-speech and voice cloning systems, both commercial APIs and open-weights models,
• and a transcription check on every synthetic clip, so each one really contains the intended utterance.

Entrants submit predictions. Podonos scores them against labels the entrants never see.

That is the important property of this board. No vendor scores its own row.

Result 1: Lowest Reported Commercial Latency

Fig 1 replays the ranking. At 24 ms per clip, our entry finished first among commercial systems with published timing. By processing speed, 119× real time is 2.3× the next-fastest commercial system.

Speed alone proves very little. Open-source baselines on the same board report latencies as low as 5 ms, at 56.83% accuracy on a balanced set.

The useful question is what accuracy survives at that speed.

Result 2: Accuracy at That Speed

Podonos scored our entry at 94.47% accuracy, ninth of 23 systems. Of the eight systems above us, each one either runs slower or published no timing.

Fig 2 puts both measurements on one chart. Our entry sits at the right edge of the shaded region: 94.47% accuracy at 119× real time.

That is the point we care about. The model does not trade detection away to reach that speed: 97.3% of the synthetic files were caught.

Result 3: Every File Scored

Accuracy depends on what a system is allowed to skip. Our entry returned a decision on every file and declined none:

files scored     = 4,524 of 4,524
deepfakes missed = 2.7%
deepfakes caught = 100% - 2.7% = 97.3%

Not every commercial system did. Corsound AI declined 14.3% of files and Reality Defender 17.2%, mostly clips under about 1.5 seconds. Their accuracy covers a smaller sample, and Podonos notes that those rows are not directly comparable with full-coverage rows.

A short clip is also what a live call gives you in its first seconds. Declining it is not a neutral outcome.

Beyond the Main Board

A benchmark row is one operating point. Our working deployment preprint measures the other question: what happens to one detector when the precision, runtime and device change. It scored the same 4,000 clips on every configuration.

The same study ran a byte-identical INT8 graph on a OnePlus handset, CPU only. It stayed ahead of the audio on 3,986 of 4,000 clips, or 99.65%.

These are measured configurations, not guarantees for every device or call. They show where the speed comes from: deployment choices we can measure one at a time.

Our current model runs at 24 ms on GPU and 84 ms on CPU.

Size is the reason. Our models are small, so each call needs less compute. That keeps latency low and keeps the cost of running them low, on GPU or CPU.

What We Took From It

A detector is not proven by a score that only looks strong in isolation. The useful question is whether it holds its accuracy at the speed a live decision needs.

Our main takeaways were:

• Read speed and accuracy together, never one alone.
• Compare latency only with the hardware and service conditions stated.
• Check coverage before comparing accuracy.
• Keep the main board and the telephone tracks apart.
• Separate what a third party scored from what a vendor reported.
• Test on your own channels, languages and voice generators before you trust any board, including this one.

The scored part of the result is 94.47% accuracy on all 4,524 files. The reported part is 24 ms per clip, the lowest of any commercial system with published timing. Together they describe a detector made to answer while the call is still live.