The question I get most often about voice detection is some version of: can you tell me which tool made this?
The short answer is no, and I want to spend this article explaining why, because the reasoning tells you a lot about how synthetic speech actually gets produced. It also explains why some clips from these products are much easier to catch than others, which is a genuinely useful thing to understand even though it is not the answer people came for.
The pipeline is three parts, and only one of them is yours
Every commercial text-to-speech product is stacked roughly the same way.
At the front is a text processing stage. It expands numbers and abbreviations, works out where sentences break, applies pronunciation dictionaries, and decides how to handle anything ambiguous. This is where "Dr. Smith lives on Elm Dr." becomes two different words. It is unglamorous work and it is largely invisible in the output.
In the middle is an acoustic model. It converts processed text into an intermediate representation of the sound: usually a mel spectrogram, sometimes a sequence of learned tokens. This stage decides the pitch contour, the timing, the emphasis, the emotional colour. When people talk about a voice sounding expressive or flat, they are mostly talking about this layer.
At the back is a vocoder. It takes the intermediate representation and produces an actual waveform, sample by sample. This is the part that has to invent phase, invent high-frequency detail, and invent the fine texture that makes audio sound like a recording rather than a synthesis.
Detection lives almost entirely at the vocoder stage. And here is the thing: the vocoder is the layer that companies share, license, fork, and swap out.
Brand names are not architectures
Neural vocoding went through a well-documented sequence of public research. WaveNet, then WaveRNN, then the parallel and adversarial families like WaveGlow and MelGAN, then HiFi-GAN, which became something close to a default because it produced good audio fast enough to serve at scale. More recently there has been movement toward diffusion approaches and toward end-to-end models where the boundary between acoustic model and vocoder blurs entirely.
Most of that research was published. A lot of it shipped as open implementations. Commercial products were built on top of it, then fine-tuned, then partially replaced, then replaced again.
So when a detector picks up a vocoder artifact, what it has found is evidence about an architecture family. Mapping that back to a company name requires an assumption that a given company is currently using a given architecture, exclusively, on the endpoint that produced this file. That assumption goes stale silently. A vendor ships a new model version on a Tuesday and every attribution claim built on the old one is now wrong, with no announcement and no way for you to know.
There is a second problem, which is that the mapping was never one-to-one to begin with. Multiple products have run on the same underlying family at the same time. Attribution in that situation is not even theoretically recoverable from the audio.
This is why our detector reports whether speech appears synthesised and stops there. It is a narrower claim than customers want. It is the claim the evidence supports.
What actually differs between the products
With attribution off the table, the useful comparison is about what each product is built to do, because that shapes how its output tends to behave under detection.
ElevenLabs is the one most people mean when they say AI voice. Its centre of gravity is expressive long-form narration and voice cloning from short samples, and it has been aggressive about multilingual output. The expressiveness is the relevant part here. Output aimed at sounding emotionally natural carries prosody that is much closer to human distributions, which means the prosody signal I described as weak in our explainer on how detection works gets weaker still. Detection on this kind of output leans harder on spectral evidence.
Murf sits in the corporate and instructional space: presentations, e-learning modules, product explainers. The typical output is a measured, professional read, often assembled in a timeline editor alongside music and cut between takes. That editing matters. Assembled audio has been through a mixing stage, which means normalisation, possibly compression, possibly noise processing, all applied after synthesis. Post-processing reshapes the exact spectral detail a detector wants to see.
PlayHT has pushed hard on cloning and on API-first delivery, including low-latency streaming for interactive use. Streaming synthesis is worth flagging because generating audio in small chunks under a latency budget is a different engineering problem than generating a finished file, and the seams between chunks are their own kind of artifact.
OpenAI's TTS offers a fixed set of built-in voices through the API rather than open-ended cloning of arbitrary people, which changes the threat model more than it changes the detection problem. It is also very widely used inside other products, which is a useful reminder that the audio in front of you often did not come from someone visiting a website. It came from an application that called an API.
I have deliberately not put accuracy figures against any of these names. We have not run a published, methodologically sound benchmark across current versions of all four with sample audio and a documented protocol, so any table I produced would be decoration. If you see one of those tables somewhere without the samples and the methodology attached, ask for them.
The variables that actually predict detectability
Across all four products, the things that move the needle are mostly not the brand.
How long the clip is. Under roughly ten seconds of continuous speech, evidence gets thin regardless of source. Our detector will decline to score clips that do not contain enough actual speech, which is a design decision I would rather defend than the alternative of producing a confident number from nothing.
How many times it has been re-encoded. This is the big one. Detection evidence lives in fine spectral detail. Lossy compression is specifically designed to discard detail that human hearing does not consciously register, and there is heavy overlap between those two categories. A file that went from synthesis, to an upload, to a platform re-encode, to a download, to a forward through a messaging app has been through several rounds of that. Each round takes evidence away.
Whether it was post-processed. Studio treatment applied after synthesis, the kind that is completely routine in the Murf-style workflow, changes the spectral surface the detector reads.
Whether it is narrowband. Anything that has been through a traditional phone system has lost everything above roughly 3.4 kHz, and a meaningful share of the evidence lives up there. This is covered in more depth in our piece on detecting cloned voices over phone calls.
How recent the generation is. Every detector has a training cutoff against a moving target. A model that has seen a great deal of one generation family and very little of a newer one will perform unevenly, and that unevenness does not announce itself.
If I had to summarise: a thirty-second uncompressed WAV straight out of any of these four engines is a comfortable case. A nine-second Opus voice note forwarded twice through a messaging app is a hard case no matter which engine produced it.
The cloning question
Voice cloning is where the practical concern usually sits, and it deserves separating from generic text-to-speech.
Cloning takes a sample of a real person and produces new speech in something resembling their voice. The sample requirement has come down a lot over the past few years, and the quality at short sample lengths has improved to the point where the old advice about needing long clean recordings no longer holds.
For detection, the useful point is that cloning does not change what we are looking for. The clone is still produced by a vocoder, and the vocoder still has to invent a waveform. A clone of your CFO's voice and a stock narrator voice from the same product go through the same final stage and leave the same category of trace. Detection difficulty is driven by the delivery conditions listed above, not by whose voice is being imitated.
What cloning does change is the consequence of being wrong, which is why the finance controls piece argues that process design should carry more of the load than detection.
How to actually evaluate a detector on these engines
If you want to test a tool rather than take anyone's word for it, including ours, here is a protocol that will tell you something real.
Generate the same script from each engine you care about. Use current versions, and write the date down, because this ages.
Keep the original uncompressed output. Then make degraded copies deliberately: a 128 kbps MP3, a version that has been through a messaging app, a version cut to eight seconds, a version with noise reduction applied. Now you have a matrix rather than a single data point.
Run all of it. Then, and this is the part people skip, run an equal number of genuine human recordings through the same matrix. Real voice notes, real phone recordings, real studio narration, real people reading scripts aloud. A detector that catches every synthetic clip and also flags a third of your human ones is not a good detector, and testing only synthetic samples hides that completely.
Look at what the tool does with the hard cases specifically. Does it abstain, or does it always produce a number? A tool that never says "I cannot tell" from a three-second noisy fragment is not being confident. It is being unfalsifiable.
Our detector accepts MP3, WAV, M4A, OGG and FLAC files up to 25 MB, and returns an AI score, a human score that is exactly its complement, and one of three verdicts including an explicit uncertain state. Free checks are available without an account at the voice detector.
The claim worth defending
I would rather tell you a smaller true thing than a larger convenient one.
A detector can give you evidence about whether speech was machine-generated. That evidence gets weaker with compression, with brevity, with post-processing, and with novelty. It does not identify the product, the account, or the person who typed the script, and any tool that says otherwise is making an inference it cannot support from the audio alone.
If you need to know which product made a clip, the answer will come from somewhere other than the waveform. Billing records, API logs, platform cooperation, the person who uploaded it. Those are investigative routes, not acoustic ones, and confusing the two is how people end up very confident about something that was never in the file.
Try it on your own writing