"Translate this video" sounds like one task. It is three, they have different solutions, and picking the wrong one is why people conclude that nothing works.
The question that separates them is not what language the audio is in. It is where the audio lives.
| What you have | The actual problem | What solves it |
|---|---|---|
| A file on your phone or computer | Decoding and transcribing a fixed recording | A transcription service, or an app that imports files |
| Something playing in another app | Getting at audio the system will not hand over | The microphone, or the platform's own captions |
| A live call or a stream | All of the above, in real time, with no second take | Live translation, on the call or through the mic |
Disclosure. We make OmniTalk, which does the second and third of these. The first one we do not do, and the section on files says who to use instead.
The constraint that explains everything
iOS gives no general way for one app to read another app's audio output. There is no system audio tap, no loopback device, nothing an app can request. Apple's screen-broadcast machinery can hand a broadcast extension the system audio stream, but that requires the user to start a screen broadcast from Control Center, and it exists for streaming your screen rather than for reading other apps.
So when an app claims to translate a video playing in another app, it is doing one of two things: reading captions the platform already publishes, or listening through the microphone to your phone's own speaker.
The microphone route is what most apps use, including ours. It is a real acoustic loop: the phone plays the audio out loud, and the phone hears it back.
Echo cancellation is the hidden setting. Every voice app normally runs acoustic echo cancellation, whose entire job is to remove the phone's own speaker output from the microphone signal so you do not hear yourself on a call. For this feature that filter is exactly wrong, because the speaker output is the thing you want to capture. An app doing this properly turns it off.
What that costs you. Room noise, reverberation and speaker quality all enter the transcript. A quiet room and a moderate volume beat a loud one, because phone speakers distort near maximum. This route will never match transcribing the file directly.
The three routes are not interchangeable, and the differences are large enough to decide the question for you:
| Route | Language coverage | Typical delay | What limits accuracy |
|---|---|---|---|
| Platform caption track, translated | 100+ on the big platforms | None, it is already text | Whatever the platform's own captions got wrong |
| File transcription | Varies by service | Faster than real time | The original recording quality |
| Speaker to microphone, live | 60+ in OmniTalk, 9 in Apple's Live Translation | 1 to 3 seconds | Room noise, speaker distortion, overlapping voices |
Sources: OmniTalk features and Apple's iOS feature availability page, retrieved 12 August 2026. The delay figures are structural rather than measured: audio has to be spoken before it can be heard.
Problem 1: a file you already have
If the audio is a file you can move around, do not use the microphone route. Transcribing the original is more accurate, faster than real time, and gives you a text file you can edit.
Practical order:
- Check for existing captions first. YouTube auto-captions and most streaming platforms publish a caption track you can translate directly. Reading published text beats re-deriving it from sound.
- If it is your own recording, transcription tools handle a file in a fraction of its duration: a 10-minute interview is usually done in under 1 minute, and most services will translate the transcript as a second step.
- If it is a voice message, some messaging apps now transcribe in-app. Check before reaching for anything else.
The failure mode here is quality of source audio, not tooling. Two people talking over each other is hard for every system, and no app fixes a recording where the microphone was in someone's pocket.
Problem 2: something playing in another app
This is the case the microphone route exists for, and it is the common one: a video in a social app, a podcast, a voice note, a news clip.
How to get a good result:
- Take your headphones out: the loop is acoustic and cannot work without it.
- Use moderate volume, not maximum: speaker distortion costs more accuracy than the extra few decibels gain you.
- Put the phone on a hard surface rather than a soft one, or hold it. Cushions absorb the reflection.
- Expect 1 to 3 seconds of delay: the audio has to be spoken before it can be heard, so captions run behind the picture. This is inherent, not a bug.
- Replay anything that matters. A second pass over the same 30 seconds costs you nothing but time, and catches most of what a single listen drops.
What it cannot do: separate two overlapping speakers reliably, handle music with lyrics, or recover words a speaker mumbled. Anything the microphone genuinely cannot hear is gone.
Problem 3: a live call
Calls are their own case, because both people are already on a phone and the audio is bidirectional.
Apple's Live Translation runs on Phone and FaceTime calls on qualifying hardware, which is a genuinely different surface from in-person use, and it does not carry the one-directional limitation that the in-person version has. We wrote up the requirements and the languages in the Live Translation article.
For anything outside Phone and FaceTime, you are back to the microphone route, with the additional problem that a call held to your ear is not audible to the microphone. Speakerphone is the only practical way, and it is worth saying out loud that the other person can tell.
Subtitles are a separate problem again
If the video has burned-in subtitles rather than a caption track, the text is part of the picture. Reading it is optical character recognition, not speech recognition, and it fails in 3 places speech recognition never does: stylised fonts, text over busy backgrounds, and subtitles that hold for under 1 second before cutting.
The practical move is to pause on the frame and use a camera or screenshot translation instead of trying to read moving text. Accuracy on a still frame is far better than on a moving one.
Where OmniTalk loses
We cannot import a file. Translate Video or Audio listens live. If you have an audio file sitting on your phone and time to spare, a transcription service will give you a better and more editable result, and we would rather tell you that than have you fight the microphone route.
We cannot beat published captions. When a platform already publishes a caption track, translating that text is more accurate than anything derived from sound. Check for captions before opening any app, including ours.
The acoustic loop has a quality ceiling. Everything above about volume, distance and room noise applies to us as much as anyone. A perfect transcription of a phone speaker in a noisy café is not available from any vendor.
It is a PRO feature. Translate Video or Audio is not in the free tier, per our features page. Apple's built-in captions and platform caption tracks cost nothing and are the right first try.
A quick decision list
- The video has captions and you want them in another language. Use the platform's own translate-captions option.
- You hold the file and it matters. Transcribe the file, then translate the transcript.
- It is playing in another app and you want it now. Microphone route, headphones out.
- It is a Phone or FaceTime call on recent hardware. Apple's Live Translation, no app needed.
- It is burned-in subtitles. Pause, then translate the still frame with a camera.
FAQ
Why does audio translation stop working when I put my AirPods in? Because the app is listening to your phone's speaker through its microphone. Headphones divert the audio into your ears, so there is nothing for the microphone to hear.
Can an app translate audio from another app without the speaker? Not on iOS in the general case. There is no system audio tap available to apps, which is why the microphone route exists at all.
Why do the captions lag behind the video? The audio must be spoken before it can be heard and recognised. A second or two of delay is structural.
Is transcribing a file more accurate than the microphone route? Yes, usually by a wide margin. The file is the original signal; the microphone route is a re-recording of a speaker in a room.
Does it work with music? Poorly. Speech recognition is trained on speech, and sung vocals over instrumentation are a different problem.
What about a video with two people talking at once? Expect the transcript to follow one voice and drop the other. Reliable speaker separation is not solved in this setting.
Retrieved 12 August 2026. Platform behaviour and app features change; the iOS audio constraint described here has held for several major releases, but verify anything a purchase depends on.
👉 Get OmniTalk on the App Store · OmniTalk features · Support FAQ