input_audio_transcription returns fabricated content in unspoken languages while the model understands the audio correctly (Arabic, gemini-3.1-flash-live-preview)

> Re-posted from google-gemini/cookbook#1345 at the request of @kkorpal, who asked for Live API bugs to be tracked here. The audio clips below were already shared with the Live engineering team on that thread.

### Description of the bug:

input_audio_transcription on the Live API does not transcribe the input audio. It returns text that is fluent and confident
but unrelated to what was spoken — including whole answers rendered in languages the speaker never used, Arabic written in
Latin transliteration, invented content on long turns, and in one case profanity the speaker never said.

The decisive detail: the model's own spoken replies prove it understood the audio correctly. Only the transcription channel
is wrong. That rules out microphone, encoding, audio quality, and network as causes, and points at the transcription channel
being generated from the tokenized audio rather than transcribed from it.

Environment
- Model: gemini-3.1-flash-live-preview (Gemini API / AI Studio backend, vertexai=False)
- Setup config: input_audio_transcription + output_audio_transcription via types.AudioTranscriptionConfig()
- Client: livekit-agents 1.7 with livekit-plugins-google, Python 3.12
- Audio: WebRTC, single speaker, Egyptian Arabic mixed with English technical terms
- Two production-like interview sessions, 2026-08-24 and 2026-08-25

Steps to reproduce
1. Open a Live session with input_audio_transcription enabled.
2. Speak Egyptian Arabic containing English technical terms, in long turns (60-110 seconds), with occasional multi-second
thinking pauses.
3. Compare inputTranscription.text against the model's own spoken reply for the same turn.

Reproduces on roughly 15-25% of turns. ~~Turns longer than ~90 seconds fail most often.~~ (Corrected below: failures correlate with position in the session, not turn length.) It is intermittent, not deterministic.

### Actual vs expected behavior:

Expected: inputTranscription.text contains what the speaker said, in the language they said it.

Actual: it contains fluent text that is frequently in a different language, partially or wholly invented, and occasionally
offensive.

Four distinct failure shapes were observed:

1. Correct meaning returned in a language never spoken

An Arabic answer about Git workflow came back as fluent Portuguese that accurately describes dev/staging/master branches, PR
templates, labels, GitHub Actions and requested changes:

▎ "Em relação ao Git, a gente tem três branches: a gente tem a dev, a gente tem a staging e a gente tem a master ou a main...
▎ o desenvolvedor ou qualquer pessoa da equipe abre um PR. O PR, geralmente, tem um template que eles seguem..."

The meaning is right; the language is invented. A failing ASR cannot produce a fluent, accurate paragraph in a language that
was not spoken. Another turn in the same session returned Spanish; another returned Arabic in Latin transliteration.

2. The model understood correctly at the same moment

Immediately after the Portuguese transcript above, the model replied in Arabic:

▎ "تمام، واضح إن سير العمل عندكم منظم جدًا" ("OK, clearly your workflow is very organized")

That is a correct response to the Arabic Git answer that was actually spoken. This held on every corrupted turn: the audio
path was right, the transcript was wrong.

3. Fabricated content plus degenerate repetition on a long turn

A ~105-second Arabic answer returned an invented Brazilian Portuguese video testimonial — a man named "Lucas" from São Paulo
reviewing a phone-repair course — with one sentence repeated ~50 times, ending in YouTube outro boilerplate ("deixa o seu
like, se inscreva e clique no sininho"). None of it was spoken. The repetition is characteristic of unanchored autoregressive
generation rather than transcription.

4. Hallucinated profanity

A turn of ordinary Arabic returned, in full:

▎ Fick dich.

German profanity, never spoken, in a language not used anywhere in the session.

### Any other information you'd like to share?

Both known workarounds were tested on real audio and both failed.

1. Stating the language requirement in system instructions — the guidance given by Google staff on the developer forum. A
block was added instructing the model to write the speaker's words in Arabic script, never to translate, never to
transliterate, and to emit nothing for silent audio. Tested 2026-08-25 across real sessions: no measurable improvement.

2. Routing the transcript through a function-tool argument — a workaround shared by another developer. A previous_answer
parameter was added to an existing tool, instructing the model to reconstruct what the speaker said from conversational
context instead of relaying a transcript. This does bypass the corrupted channel: tool arguments returned clean Arabic on
turns where inputTranscription returned transliterated garbage. But the output is not a transcript:
- it is a summary — 41% of words retained on a measured turn (39 words → 16, 2 sentences → 1)
- 6 of 14 turns returned third-person English notes ("Candidate said they don't know")
- the model omitted the parameter entirely on 29% of turns

So the reasoning path produces correct content while the transcription path does not — but the reasoning path only yields an
abstract, not the speaker's words.

**Why this matters beyond accuracy**

This transcript is the permanent record of a job interview, read by recruiters and used to evaluate candidates. Failure 4
means a candidate can be recorded as swearing at their interviewer. Failure 1 is more insidious: the output is fluent and
plausible, so a corrupted transcript is indistinguishable from a correct one without re-listening to the original audio.
Other developers report the same failure also drops and alters words within the correct language (e.g. "My wifi doesn't work"
→ "My wife isn't well"), which no downstream check can detect.

---

## Follow-up: audio repro clips and a correction

Both are 16 kHz mono PCM WAV, cut from a single ~10-minute session
(`gemini-3.1-flash-live-preview`, Egyptian Arabic). Offsets below are **within
each clip**.

**Upfront, so you are not surprised by it: the recording conditions are not
ideal.** There is background noise and my voice is not always clear. I am
flagging that deliberately rather than letting you discover it, because I do not
think it explains what came back — see the note under the tables.

---

### `gemini_live_arabic_repro_425-545.wav` — 120s, four failures

| Clip offset | `inputTranscription` returned | Language actually spoken |
|---|---|---|
| ~09-26s | `kami zabir ga le hasab kul hala fi nafsul waqtul procedure li bnatabu in qultu skin tiji wibqa liya branch...` | Arabic |
| ~50-54s | `It will not dissolve the cement.` | Arabic |
| ~70s | `um pedaço de solda` | Arabic |
| ~70-72s | `Também.` | Arabic |

### `gemini_live_arabic_repro_570-625.wav` — 55s, three failures

| Clip offset | `inputTranscription` returned | Language actually spoken |
|---|---|---|
| ~03-17s | `count as out of عدد التيم الموجود والبروجكت اللي شغالين عليه` | Arabic |
| ~17-29s | `em tais hora de mini CEO` | Arabic — asking who the company's CEO is |
| ~29-39s | `بتاع زورا في السالري` | Arabic — asking about salary |

**No Portuguese was spoken at any point in this session, by either party.** The
entire interview is Arabic, with English technical terms.

---

### Why I do not think noise accounts for this

Poor audio should degrade a transcript toward silence, partial words, or
nonsense. It should not produce **fluent, grammatical output in a language nobody
spoke**. `um pedaço de solda` and `Também.` are well-formed Portuguese. Noise can
turn Arabic into garbled Arabic; it cannot turn Arabic into Portuguese.

The clearest case is from an earlier session, where a ~109-second Arabic answer
describing a Git workflow was returned as fluent Portuguese that **correctly**
described dev/staging/master branches, PR templates, labels, GitHub Actions and
requested changes. Noise cannot add information that is not in the signal. And at
that same moment the model's own spoken reply was a correct Arabic response to
what I had actually said — so the audio was understood; only the transcript was
wrong. I can supply that recording too if it would help.

### Correction: this is not length-driven

My original report said long turns (>90s) fail most often. Across three sessions
that does not hold, and in this session it is inverted:

| | turn durations |
|---|---|
| transcribed correctly | 39.8s, 68.8s, **84.1s**, **78.2s**, 35.1s |
| corrupted | 10.7s, 16.7s, 4.4s, 0.1s, 2.2s, 13.7s, 12.4s, 10.0s |

Every long turn was correct; every corrupted turn was short.

**What does correlate is position in the session:**

- before 320s into the session: **0 of 5** candidate turns corrupted
- after 433s: **8 of 11** corrupted

The same shape appears in my two other sessions — one had failures only in its
last two turns, the other clustered them in the second half. Corruption seems to
accumulate as the session runs rather than depending on any single utterance.

That may matter for reproducing it: feeding one clip into a fresh session may
transcribe fine. You may need to run a session for several minutes first, or
replay a full session, before the behaviour appears.

### Notes on the audio

- Cut from a **LiveKit Room Composite recording** (AAC/MP4, re-encoded), not the
original Opus WebRTC stream the API received. Accent, Arabic/English
code-switching, pacing and pauses are preserved, but it is not byte-identical
to what the model was fed.
- The composite mixes both speakers, so the agent's Arabic replies are audible
between candidate turns. I can provide a candidate-only track if useful.
- Nothing in these windows is personally identifying. Happy to share the full
session recordings privately if that helps, given the position effect above.

[gemini_live_arabic_repro_570-625.wav](https://github.com/user-attachments/files/31455401/gemini_live_arabic_repro_570-625.wav)
[gemini_live_arabic_repro_425-545.wav](https://github.com/user-attachments/files/31455406/gemini_live_arabic_repro_425-545.wav)

Start by replaying the attached WAV clips through a Live API session with input_audio_transcription enabled, then compare inputTranscription.text with the spoken audio and the model's spoken reply. Check whether corruption appears after several minutes or later in the session; done means a reproducible failure pattern and evidence suitable for the Live engineering team.

Written by the indexing model from the issue text.