Home · Blog · AI Voice Detection
AI VOICE DETECTION

Audio Formats and AI Detection: Why the File You Send Changes the Answer

The same recording can come back scored differently depending on which copy you upload. That is not the detector being unreliable, and understanding why makes you much better at using one.

AU

Somebody uploads a clip and gets one result. They upload what they believe is the same clip, saved differently, and get another. Then they email me asking which one to believe.

The answer is almost always the less compressed one, and the reason is worth understanding, because file handling is the part of detection that users actually control. Model quality is our problem. What you upload is yours, and it makes more difference than most people expect.

What we accept, and the one that catches people out

Our voice detector takes MP3, WAV, M4A, OGG and FLAC, up to 25 MB.

The gap in that list is Opus, and it is the gap that trips people up daily, because WhatsApp voice notes are Opus files. So are Telegram voice messages, and so is a lot of what gets exported from Discord. If someone forwards you a voice note and you try to upload it directly, it will be rejected. Not scored badly. Rejected at the door, with an error telling you the accepted formats.

I would rather say that plainly than have you discover it mid-investigation. Converting is straightforward and I cover it below, though the conversion comes with a caveat that matters.

One more thing on uploads: we check the file's actual byte signature, not just its extension. Renaming something to end in .mp3 does not make it audio, and a file whose contents do not match will be turned away. This is a security measure rather than a detection one, but it explains the occasional confusing rejection of a file that was mislabelled somewhere upstream.

Lossy, lossless, and where the evidence lives

To understand why format matters you need one idea: detection evidence lives in fine spectral detail, and lossy compression is engineered to remove exactly that kind of detail.

A detector is looking for traces left by the synthesis process, mostly by the vocoder that had to invent a waveform. Those traces are subtle. High-frequency texture that carries almost no meaning. The precise character of noise in fricatives. Consistency in harmonic structure that a real vocal tract never quite achieves.

Lossy codecs are psychoacoustic. They model what human hearing notices and discard what falls below perceptual thresholds, because that is how you get a file ten times smaller that sounds nearly identical. The codec has no idea it is destroying forensic evidence. It is doing exactly its job. The overlap between "inaudible to humans" and "diagnostic for detectors" is simply very large.

So the format hierarchy, best to worst for analysis:

WAV and FLAC are lossless. FLAC is compressed but reconstructs the original samples exactly. Both preserve everything. If you have a choice, choose one of these.

M4A and high-bitrate MP3 are lossy but generally usable, particularly above 192 kbps. Evidence is thinned, not erased.

Low-bitrate MP3 and OGG, in the 64 to 96 kbps range, have lost a great deal. Still worth running, with expectations adjusted.

Anything that has been through a messaging platform has usually been re-encoded at low bitrate and often narrowband as well. This is the hardest category, and it is unfortunately the most common in real cases.

Generation loss is the thing to actually worry about

Single-pass compression is survivable. What does the damage is stacking.

Consider a realistic chain. Audio is generated. It gets uploaded to a platform, which re-encodes it. Someone downloads it and shares it through a messaging app, which re-encodes again at a different bitrate. The recipient screen-records it because that was easier than finding the file, which encodes it a third time through a completely different codec.

Each pass discards detail based on the previous pass's output, not the original. Errors compound. By the fourth generation, the fine structure a detector needs has been quantised, discarded and re-approximated repeatedly. What remains is perceptually fine and forensically thin.

This is why the single most valuable thing you can do is get the earliest copy that exists. Not a cleaner-sounding copy. An earlier one. If the person who sent you a clip still has what they received, ask for that. If it originated on a device, ask for the device file. Chasing the original does more for your result than any setting on our end.

A related tip for anyone receiving files: ask people to send audio as a file or document attachment rather than as a voice message. Most platforms treat those pathways differently, and the file attachment route often avoids a re-encode that the voice message route applies automatically.

Converting a voice note without making things worse

If you have an Opus file and need it in an accepted format, use ffmpeg and copy rather than re-compress where you can.

To wrap it in an accepted container while keeping the audio stream untouched:

ffmpeg -i voicenote.opus -c copy voicenote.ogg

Opus is commonly carried in an Ogg container already, and this remuxes without touching a sample. Nothing is lost. If the stream will not copy cleanly into that container, decode once to lossless instead:

ffmpeg -i voicenote.opus -c:a pcm_s16le -ar 16000 output.wav

Note the sample rate. Do not upsample. Setting 48000 on audio that was encoded at 16 kHz does not recover anything, it just interpolates and makes the file larger while implying detail that was never captured. Check what you actually have first:

ffprobe -v error -show_streams voicenote.opus

and match it.

The caveat I promised: conversion does not restore evidence. Decoding a heavily compressed Opus file to WAV gives you a lossless copy of degraded audio. The file gets bigger. The information does not come back. All you are doing is avoiding a further round of loss, which is worth doing, but do not read the WAV extension as a sign of quality.

Never convert lossy to lossy. Opus to MP3 is two rounds of psychoacoustic destruction with different models, and it is strictly worse than either alone.

Sample rate, bit depth, and channels

Some practical notes on the other properties.

Sample rate sets the frequency ceiling, which is half the rate. A 16 kHz file contains nothing above 8 kHz. An 8 kHz file, standard for traditional telephony, contains nothing above 4 kHz, and a substantial share of the evidence lives above that line. This is a hard limit that no processing undoes, and it is the core reason phone call detection is so much harder than file detection.

Bit depth matters much less. 16-bit is fine. 24-bit does not meaningfully help detection. Do not go hunting for high bit depth.

Channels rarely matter for speech, which is usually mono or dual mono. If you have a genuine stereo recording with different content in each channel, such as a two-mic interview setup, be aware that mixing to mono can blur things, and consider splitting and analysing separately.

Silence and noise count against you. Our detector runs a quality check before scoring and measures how much actual speech is present. A 30-second clip with 6 seconds of speech and 24 seconds of room tone is, from the model's point of view, a 6-second clip. Trim to the speech before uploading. This is probably the highest-value piece of preparation available to a user.

The 25 MB cap, and what to do about long recordings

If your file exceeds 25 MB, the answer is not to compress it harder. Compressing to fit is the one thing guaranteed to reduce the quality of the answer.

Cut instead. Take the most relevant continuous 30 to 60 seconds of clear speech and upload that at full quality. A minute of clean lossless audio is far better material than an hour crushed to fit under a size limit.

If you need to assess a long recording properly, sample it. Take several clips from different points, run them separately, and compare. That also surfaces something a single upload cannot: a recording assembled from multiple sources may score differently in different sections, and that variation is itself a finding worth having.

For reference, a minute of 16-bit 44.1 kHz mono WAV runs to roughly 5 MB, so you have room for several minutes of lossless audio inside the cap.

Preparing a file properly, in order

  1. Get the earliest copy that exists. This matters more than everything below it combined.
  2. Check what you actually have with ffprobe. Format, bitrate, sample rate, duration.
  3. If it is an unsupported format, remux without re-encoding, or decode once to WAV at the native sample rate.
  4. Trim to continuous speech. Cut the silence, the music, the crosstalk.
  5. Aim for at least 15 to 30 seconds of clear single-speaker audio if the material allows.
  6. Do not upsample, do not apply noise reduction, do not normalise, do not enhance.
  7. Keep it under 25 MB by cutting duration, never by increasing compression.

That sixth point deserves emphasis because the instinct runs the other way. Modern noise reduction and speech enhancement are machine learning systems that partially regenerate the signal to make it sound cleaner. From a detector's perspective that is another synthesis stage applied on top, and it pushes genuine audio toward the exact profile the detector is looking for. Enhancement can create false positives. Send the raw file, however rough it sounds.

Reading the result with the format in mind

Our detector returns an AI score from 0 to 100, a human score that is exactly its complement, and a verdict of human, AI, or uncertain.

Interpret those against the file you gave it.

A clear result on a lossless 30-second file is meaningful evidence. The same result on an 8-second, twice-forwarded, low-bitrate clip is a much weaker signal, and you should carry that weakness forward into whatever conclusion you draw.

An uncertain verdict on degraded audio is the system working correctly. It means the evidence surviving in that file cannot support a claim either way. That is a genuine finding about the limits of your material, and it is more useful than a confident number generated from nothing. Our earlier voice model produced exactly those confident numbers, scoring real human voice notes at 99 percent AI because it had learned the wrong boundary, and the confidence told nobody anything. I would rather the tool decline.

And a low AI score never proves audio is genuine. It means no artifacts were found, and everything in this article describes ways artifacts get destroyed by handling rather than by the audio being real. Why detectors disagree goes further into how to weigh a result you cannot fully trust.

If you want to try it, the voice detector is free without an account. Bring the best copy you have, trim it to the speech, and resist the urge to clean it up first.

Try it on your own writing

DB

Founder & CEO · TextSight

Writing about AI detection, humanization, and the strange new craft of writing in 2026. Operates Lacewing Technologies from Maharashtra, India.

Try the detector free.

Paste any text. See where AI signals show up. Fix what's flagged in minutes.

Start free — no card More from the blog