Arabic Speech-to-Text: Deepgram vs Whisper vs Azure, and the One-Week Test on Your Own Calls
Published accuracy scores won't tell you how an engine handles a Khaleeji caller on a phone line. Here is what separates Deepgram, Whisper and Azure for Arabic, and a one-week test to settle it on your own audio.
Every vendor's published Arabic accuracy number was measured on someone else's audio. That number mostly comes from clean, read speech in Modern Standard Arabic (MSA). Your callers speak Khaleeji, Egyptian or Levantine, often from a car, over a compressed phone line. So the score on the vendor's page tells you very little about your own calls.
That gap matters because speech-to-text (STT) is the first step in any voice agent. Everything after it waits on the transcript. A wrong transcript gives you a wrong answer. A slow one makes the whole conversation lag.
Gulf buyers usually shortlist three engines: Deepgram, OpenAI's Whisper and Microsoft Azure AI Speech. We have not published a head-to-head benchmark, and we won't make one up. Instead, you get the structural differences that decide the choice, plus a test protocol you can run on your own recordings in about a week.
Why Arabic breaks English-style evaluation
Arabic has diglossia. People write in MSA but speak in dialects, and the two differ in vocabulary, pronunciation and grammar. Models trained mostly on news broadcasts and audiobooks tend to push dialect speech toward the nearest MSA form. That produces dropped words, "corrected" grammar the caller never used, or outright invented phrases. The wider problem is covered in Arabic tokenization, dialects and search in production.
Phone audio makes it worse. Most phone lines carry narrowband audio at 8kHz. Many modern models are trained on 16kHz audio, so phone recordings reach them with part of the signal missing.
There is also a scoring trap. Arabic spelling varies in ways that don't change the meaning: different forms of alef, taa marbuta written as haa, optional diacritics. Score raw output against a reference and those differences count as errors. An engine can look much worse than it is. Normalize both texts before you compare them.
For a live voice agent, three things decide the outcome:
- ▸Time to first transcript. How fast the engine returns usable text while the caller is still talking.
- ▸Dialect accuracy on phone audio. Word error rate (WER, the share of words the engine gets wrong) on your callers, not on broadcast speech.
- ▸Endpointing. How quickly and reliably the engine decides the caller has finished speaking.
Endpointing is where many voice pilots fail. A study of turn-taking across ten languages put the typical gap between speakers at around 200 milliseconds (Stivers et al., PNAS, 2009). If your system waits most of a second of silence before deciding the caller is done, it feels slow before the language model has started. The two Deepgram settings that control this, endpointing versus utterance_end_ms, with code, are in the latency post.
Deepgram: built for live conversation
Deepgram was designed for streaming. Audio goes in over a persistent connection and partial transcripts come back while the caller is still speaking. For an AI receptionist, a triage line or a sales qualification agent, that design is the right starting point.
Its endpointing can be tuned. Deepgram's endpointing documentation describes the silence threshold that closes an utterance. That is the setting that most affects whether your agent interrupts people or feels sluggish. Its current model family is Nova. Deepgram's language support page lists Arabic for the Nova family, with regional codes that include ar-AE, ar-SA and ar-EG. Before you commit, check two things on that page. Is the dialect code you need listed, and is streaming supported for the language setting you plan to use?
The weak spot is domain vocabulary. Drug names, local project names and Arabic mixed with English business jargon are where any general model slips. Deepgram supports keyword boosting, which helps. Test it on your own term list rather than assuming it works.
Whisper: accurate, but built for recordings
OpenAI's Whisper is an open-weight model family. Its large models cope well with background noise and mixed Arabic and English. Because the weights are public, you can run it on your own servers, which matters if your data cannot leave your building. The PDPL checklist for data that cannot leave the building sets out what that obligation means in Saudi Arabia and the UAE.
The catch is how it works. Whisper processes audio in 30-second windows. Streaming versions exist, but they face a built-in trade-off. Output text early and accuracy drops, sometimes with invented words. Wait for more audio and the caller waits too. That trade-off is why Whisper rarely suits a live agent.
It is the right choice when nobody is waiting on the line:
- ▸Transcribing call recordings for quality review
- ▸Pulling compliance evidence out of sales calls after the fact
- ▸Dictation, where someone records first and reads the result later
In those jobs, accuracy matters far more than speed, and Whisper's strengths count.
Azure AI Speech: the compliance and customization option
Azure AI Speech gets shortlisted by banks, hospitals and government bodies in the Gulf. Its appeal is less about raw speed and more about procurement and control.
Azure has data center regions in the Gulf, including UAE North. Azure's region list for the Speech service shows uaenorth with real-time and batch transcription. Custom speech training runs in other regions, and the trained model is then copied across. If your regulator or legal team requires voice data to be processed in-country, that can settle the question early. Confirm that the speech features you need are actually offered in that region, because availability varies by feature. For Saudi deployments, map your obligations under the PDPL first.
Azure's distinctive feature is Custom Speech. You can upload text and audio from your own domain, such as pharmaceutical names or neighborhood and development names, to adapt the base Arabic model. For specialist vocabulary, that is often the biggest accuracy gain on offer. The cost is ongoing work: someone has to maintain the training data and retest after each base model update.
Azure supports streaming. Whether its speed fits your conversation budget depends on your network path and setup. Measure it; don't assume.
Working out the cost
STT is billed by the minute, so the formula is simple:
Calls per day × Average call length in minutes × Days per month × Price per minute
Take today's list price for each engine from its pricing page. Then adjust for three things the list price leaves out:
- ▸Volume tiers. All three providers discount at scale. At enterprise volume, ask for a quote rather than using the public rate.
- ▸Customization. Custom models on Azure are priced separately from the standard service.
- ▸Self-hosting. Running Whisper on your own GPUs turns a per-minute cost into a fixed monthly one. It pays off only if your volume keeps the hardware busy. Compare
monthly GPU and engineering cost ÷ minutes transcribedagainst the API rate at your real volume.
For a mid-sized operator, the STT bill is usually small next to the cost of a wrong transcript or a caller who hangs up. Choose on fit first. Then negotiate price.
The test: settle it on your own audio in a week
You can run this yourself, and the result will be more useful than any published table.
- ▸Collect 100 to 200 real call clips, each 20 to 60 seconds long. Pull them from your actual phone system at its native sample rate. Get consent and remove personal data first.
- ▸Spread them across your dialects and conditions. Match your real caller mix by dialect, and include noisy calls and calls that mix Arabic and English. Label each clip.
- ▸Have a native speaker write the reference transcripts in the dialect actually spoken, not "cleaned up" MSA.
- ▸Write a normalization script for alef forms, taa marbuta, diacritics and numerals. Apply it to both the reference and every engine's output.
- ▸Score WER and character error rate per dialect. A single overall average hides where an engine fails.
- ▸Score your critical terms separately. Count how often each engine gets your 50 most important names, products and numbers right. One wrong medication name costs more than ten wrong filler words.
- ▸Stream the clips in real time from the region you will deploy in. Record the time to the first partial transcript and the time to the final transcript after speech ends.
- ▸Test endpointing with natural pauses. Count how often each engine cuts a caller off mid-sentence, and how long it takes to close a finished one.
- ▸Write down the sample size and method with the results, so the decision can be checked and repeated after the next model update.
A competent engineer can run this in four to six working days. Most of that time goes into getting the reference transcripts right.
Frequently Asked Questions
Can we run Whisper on our own servers to save on API costs? Yes, and for data that must stay on-premise it is often the right move. It saves money only if your volume keeps the GPUs busy. For live conversation it also needs serious engineering to keep the delay acceptable. For batch transcription of recordings, it is much simpler and usually the better fit.
How do these engines handle Arabic and English in the same sentence? All three claim support, but they set it up differently. Whisper reads the whole audio window, which helps with mixed speech. Deepgram and Azure usually need the right language or language-detection setting in the request, and continuous detection can add delay. Include mixed-language clips in your test set and score them separately.
Why does our voice agent pilot keep interrupting callers? Usually the endpointing is set too aggressively, often a fixed silence threshold that fires when a caller pauses for breath. The fix is to tune the threshold on real calls. Combine it with a check on whether the sentence sounds finished, rather than relying on silence alone. Test it with the natural pauses in your own recordings, not with scripted speech.
The decision
A sound pattern is two engines, not one. A streaming engine handles the live conversation. A slower, more accurate engine reviews the recordings afterwards. If you are regulated, data location narrows the list before accuracy is even measured. Once the transcription engine is chosen, run the same two-day test for the voice side before you pick a text-to-speech voice.
Your real choices are two. Which streaming engine survives step 7 of the test on your callers, and does your vocabulary justify the upkeep of a custom model? Run the test before you sign a volume commitment, and re-run it after each major model update, because these engines change quickly.
→ Voice AI Latency: How to Build a Streaming Pipeline That Answers in Under 500ms → ElevenLabs vs Azure Neural Voice for Arabic: Cost, Latency, and Pronunciation Control → Arabic AI in Production: Tokenization, Dialects, and Search That Finds the Right Document