[Bug] qwen3_asr：audio_chunk_mode=vad 在静音区间编造台词、--request-sequence 缺少静音闸 #1220

中文

环境

• audio.cpp v0.9.4（Windows x64，Vulkan 构建），--backend cpu
• 家族 qwen3_asr，模型 Qwen3-ASR-1.7B-GGUF/qwen3-asr-1.7b-q8_0.gguf
• 输入：16 kHz 单声道 16-bit PCM WAV；CLI 的工作目录设为 CLI 所在目录（保证 assets/framework/models/silero_vad 能解析）

现象 1：audio_chunk_mode=vad 在静音区间「编造」台词（已人耳核实）

一段 15 秒音频：开头约 1 秒是被切断的女声，随后约 4.5 秒近乎静音，后半段才有人说话。

• audio_chunk_mode=auto -> 85 字符
  Hallam says you don't need to be here. There's still no word from Agnes. Please come.
• audio_chunk_mode=vad -> 133 字符
  Hallam says you don't need to be here. Greetings. Sir, Hallam will be down shortly. There's still no word from Agnes. Please come. 是。

人耳复核：把该音频 1.5-7.0 秒单独抽出来听，结果是「约 1 秒另一句话的残尾（女声），之后 5-6 秒静音」。
也就是说多出来的 Greetings. Sir, Hallam will be down shortly.（约 2.7 秒台词）是模型编造的，不是 auto 漏读。

两条通道都会复现（所以问题在分块模式，不在批处理通道）：

• --audio + --request-option audio_chunk_mode=vad -> 133 字符（同样编造那句）
• --request-sequence + {"options":{"audio_chunk_mode":"vad"}} -> 133 字符

现象 2：--request-sequence 没有静音闸

ffmpeg -f lavfi -i anullsrc=r=16000:cl=mono -t 1.0 silence1s.wav

# 单请求通道 -> text_output=（空，正确）
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --audio silence1s.wav

# 序列通道，同一文件同一模型，不加任何选项 -> text_output=Okay.
echo '[{"id":"sil","audio":"silence1s.wav","language":"English"}]' > seq.json
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --request-sequence seq.json

静音输入下的矩阵：

另：0.75 毫秒静音在序列通道返回 Yeah.。

已排除

• 不是请求字段缺失：补齐官方 qwen3_asr_offline 用例的字段（含 text）行为不变。
• 不是会话预热：把静音作为唯一且第一条请求，依然幻觉。
• 现象 1 不是批处理通道导致：--audio 单独跑同样复现。
• 注意：序列通道下命令行 --request-option 会被拒绝（unknown option: --request-option），选项必须写进每个请求的 options 对象。

影响

• 我们想在长音频转写里用 --request-sequence：15 秒切片下快约 26%（8 片：56.95 秒 vs 逐片 77.28 秒）。
• 上述两个现象都会把假文本注入下游的翻译与 TTS（由合成音念出来），所以目前只能自己加闸过滤。

希望确认

1. 序列通道是否应当与单请求通道一样做静音闸？现在默认 auto 会静默返回 Okay.。
2. audio_chunk_mode=vad 在静音段编造文本是否是已知限制？它是修复现象 2 的那个选项，却反而成了编造台词的来源，建议至少在文档里警示。

English

Title (EN): [Bug] qwen3_asr: audio_chunk_mode=vad fabricates text over silent regions, and --request-sequence skips the silence gate

Environment

• audio.cpp v0.9.4 (Windows x64, Vulkan build), --backend cpu
• family qwen3_asr, model Qwen3-ASR-1.7B-GGUF/qwen3-asr-1.7b-q8_0.gguf
• input: 16 kHz mono 16-bit PCM WAV; CLI started with cwd = the CLI directory (so assets/framework/models/silero_vad resolves)

Symptom 1 - audio_chunk_mode=vad invents dialogue over a silent region (human-verified)

A 15 s clip: ~1 s of clipped female speech at the start, then ~4.5 s of near-silence, then speech again.

• audio_chunk_mode=auto -> 85 chars: Hallam says you don't need to be here. There's still no word from Agnes. Please come.
• audio_chunk_mode=vad -> 133 chars: Hallam says you don't need to be here. Greetings. Sir, Hallam will be down shortly. There's still no word from Agnes. Please come. 是。

A human listened to 1.5-7.0 s of the same audio: "~1 s of another sentence, cut off, female voice, then 5-6 s of silence". So the extra Greetings. Sir, Hallam will be down shortly. (~2.7 s of speech) is fabricated, not speech that auto dropped.

Reproduces through both paths, so it is the chunk mode, not the batch channel: --audio + --request-option audio_chunk_mode=vad -> 133 chars; --request-sequence + {"options":{"audio_chunk_mode":"vad"}} -> 133 chars.

Symptom 2 - the sequence path has no silence gate

ffmpeg -f lavfi -i anullsrc=r=16000:cl=mono -t 1.0 silence1s.wav

# single-request path -> text_output=   (empty, correct)
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --audio silence1s.wav

# sequence path, same file and model, no extra options -> text_output=Okay.
echo '[{"id":"sil","audio":"silence1s.wav","language":"English"}]' > seq.json
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --request-sequence seq.json

Matrix for silent input:

0.75 ms of silence returns Yeah. in the sequence path.

Ruled out

• Missing request fields (official qwen3_asr_offline fields incl. text change nothing).
• Warm session state (silence as the first and only request still hallucinates).
• The batch channel as the cause of Symptom 1 (reproduces through --audio).
• Note: the sequence path rejects --request-option on the command line; options belong inside each request's options object.

Impact

• We would like to use --request-sequence for long-form transcription: ~26% faster on 15 s slices (8 slices: 56.95 s vs 77.28 s with one process per slice).
• Both symptoms inject fake text that downstream translation and TTS will speak, so we gate them ourselves today.

Ask

1. Should the sequence path apply the same silence gate as the single-request path? Right now auto silently returns Okay. there.
2. Is fabricating text over silent stretches with audio_chunk_mode=vad a known limitation? It is the option that fixes Symptom 2, yet it is the one that invents dialogue here - worth a documentation warning at least.## 中文（主）

环境

• audio.cpp v0.9.4（Windows x64，Vulkan 构建），--backend cpu
• 家族 qwen3_asr，模型 Qwen3-ASR-1.7B-GGUF/qwen3-asr-1.7b-q8_0.gguf
• 输入：16 kHz 单声道 16-bit PCM WAV；CLI 的工作目录设为 CLI 所在目录（保证 assets/framework/models/silero_vad 能解析）

现象 1：audio_chunk_mode=vad 在静音区间「编造」台词（已人耳核实）

一段 15 秒音频：开头约 1 秒是被切断的女声，随后约 4.5 秒近乎静音，后半段才有人说话。

• audio_chunk_mode=auto -> 85 字符
  Hallam says you don't need to be here. There's still no word from Agnes. Please come.
• audio_chunk_mode=vad -> 133 字符
  Hallam says you don't need to be here. Greetings. Sir, Hallam will be down shortly. There's still no word from Agnes. Please come. 是。

人耳复核：把该音频 1.5-7.0 秒单独抽出来听，结果是「约 1 秒另一句话的残尾（女声），之后 5-6 秒静音」。
也就是说多出来的 Greetings. Sir, Hallam will be down shortly.（约 2.7 秒台词）是模型编造的，不是 auto 漏读。

两条通道都会复现（所以问题在分块模式，不在批处理通道）：

• --audio + --request-option audio_chunk_mode=vad -> 133 字符（同样编造那句）
• --request-sequence + {"options":{"audio_chunk_mode":"vad"}} -> 133 字符

现象 2：--request-sequence 没有静音闸

ffmpeg -f lavfi -i anullsrc=r=16000:cl=mono -t 1.0 silence1s.wav

# 单请求通道 -> text_output=（空，正确）
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --audio silence1s.wav

# 序列通道，同一文件同一模型，不加任何选项 -> text_output=Okay.
echo '[{"id":"sil","audio":"silence1s.wav","language":"English"}]' > seq.json
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --request-sequence seq.json

静音输入下的矩阵：

另：0.75 毫秒静音在序列通道返回 Yeah.。

已排除

• 不是请求字段缺失：补齐官方 qwen3_asr_offline 用例的字段（含 text）行为不变。
• 不是会话预热：把静音作为唯一且第一条请求，依然幻觉。
• 现象 1 不是批处理通道导致：--audio 单独跑同样复现。
• 注意：序列通道下命令行 --request-option 会被拒绝（unknown option: --request-option），选项必须写进每个请求的 options 对象。

影响

• 我们想在长音频转写里用 --request-sequence：15 秒切片下快约 26%（8 片：56.95 秒 vs 逐片 77.28 秒）。
• 上述两个现象都会把假文本注入下游的翻译与 TTS（由合成音念出来），所以目前只能自己加闸过滤。

希望确认

1. 序列通道是否应当与单请求通道一样做静音闸？现在默认 auto 会静默返回 Okay.。
2. audio_chunk_mode=vad 在静音段编造文本是否是已知限制？它是修复现象 2 的那个选项，却反而成了编造台词的来源，建议至少在文档里警示。

English

Title (EN): [Bug] qwen3_asr: audio_chunk_mode=vad fabricates text over silent regions, and --request-sequence skips the silence gate

Environment

• audio.cpp v0.9.4 (Windows x64, Vulkan build), --backend cpu
• family qwen3_asr, model Qwen3-ASR-1.7B-GGUF/qwen3-asr-1.7b-q8_0.gguf
• input: 16 kHz mono 16-bit PCM WAV; CLI started with cwd = the CLI directory (so assets/framework/models/silero_vad resolves)

Symptom 1 - audio_chunk_mode=vad invents dialogue over a silent region (human-verified)

A 15 s clip: ~1 s of clipped female speech at the start, then ~4.5 s of near-silence, then speech again.

• audio_chunk_mode=auto -> 85 chars: Hallam says you don't need to be here. There's still no word from Agnes. Please come.
• audio_chunk_mode=vad -> 133 chars: Hallam says you don't need to be here. Greetings. Sir, Hallam will be down shortly. There's still no word from Agnes. Please come. 是。

A human listened to 1.5-7.0 s of the same audio: "~1 s of another sentence, cut off, female voice, then 5-6 s of silence". So the extra Greetings. Sir, Hallam will be down shortly. (~2.7 s of speech) is fabricated, not speech that auto dropped.

Reproduces through both paths, so it is the chunk mode, not the batch channel: --audio + --request-option audio_chunk_mode=vad -> 133 chars; --request-sequence + {"options":{"audio_chunk_mode":"vad"}} -> 133 chars.

Symptom 2 - the sequence path has no silence gate

ffmpeg -f lavfi -i anullsrc=r=16000:cl=mono -t 1.0 silence1s.wav

# single-request path -> text_output=   (empty, correct)
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --audio silence1s.wav

# sequence path, same file and model, no extra options -> text_output=Okay.
echo '[{"id":"sil","audio":"silence1s.wav","language":"English"}]' > seq.json
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --request-sequence seq.json

Matrix for silent input:

0.75 ms of silence returns Yeah. in the sequence path.

Ruled out

• Missing request fields (official qwen3_asr_offline fields incl. text change nothing).
• Warm session state (silence as the first and only request still hallucinates).
• The batch channel as the cause of Symptom 1 (reproduces through --audio).
• Note: the sequence path rejects --request-option on the command line; options belong inside each request's options object.

Impact

• We would like to use --request-sequence for long-form transcription: ~26% faster on 15 s slices (8 slices: 56.95 s vs 77.28 s with one process per slice).
• Both symptoms inject fake text that downstream translation and TTS will speak, so we gate them ourselves today.

Ask

1. Should the sequence path apply the same silence gate as the single-request path? Right now auto silently returns Okay. there.
2. Is fabricating text over silent stretches with audio_chunk_mode=vad a known limitation? It is the option that fixes Symptom 2, yet it is the one that invents dialogue here - worth a documentation warning at least.### Environment

• audio.cpp v0.9.4 (Windows x64, Vulkan build), --backend cpu
• family qwen3_asr, model Qwen3-ASR-1.7B-GGUF/qwen3-asr-1.7b-q8_0.gguf
• input: 16 kHz mono 16-bit PCM WAV; CLI started with cwd = the CLI directory (so assets/framework/models/silero_vad resolves)

Two related problems with hallucination control on qwen3_asr.

Symptom 1 - audio_chunk_mode=vad invents dialogue over a silent region (human-verified)

A 15 s clip: about 1 s of clipped female speech at the start, then ~4.5 s of near-silence, then speech again.

• audio_chunk_mode=auto -> 85 chars
  Hallam says you don't need to be here. There's still no word from Agnes. Please come.
• audio_chunk_mode=vad -> 133 chars
  Hallam says you don't need to be here. Greetings. Sir, Hallam will be down shortly. There's still no word from Agnes. Please come. 是。

A human listened to that region (1.5-7.0 s of the same audio): "about 1 s of another sentence, cut off, a female voice, then 5-6 s of silence". So the extra
Greetings. Sir, Hallam will be down shortly. (+ trailing token) is fabricated - it is not speech that auto dropped.

The same result is produced through both paths, so this is the chunk mode, not the batch channel:

• --audio + --request-option audio_chunk_mode=vad -> 133 chars (same fabricated sentence)
• --request-sequence with {"options":{"audio_chunk_mode":"vad"}} -> 133 chars

Symptom 2 - the sequence path has no silence gate

ffmpeg -f lavfi -i anullsrc=r=16000:cl=mono -t 1.0 silence1s.wav

# single-request path -> text_output=   (empty, correct)
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --audio silence1s.wav

# sequence path, same file and model, no extra options -> text_output=Okay.
echo '[{"id":"sil","audio":"silence1s.wav","language":"English"}]' > seq.json
audiocpp_cli --task asr --family qwen3_asr --model <gguf> --backend cpu --request-sequence seq.json

Matrix for silent input:

0.75 ms of silence returns Yeah. in the sequence path.

Ruled out

• Missing request fields: adding the fields used by the official qwen3_asr_offline case (including text) changes nothing.
• Warm session state: silence as the first and only request still hallucinates.
• Batch channel as the cause of Symptom 1: it reproduces through --audio too.
• Note: in the sequence path --request-option on the command line is rejected (unknown option: --request-option); options belong inside each request's options object.

Impact

• We would like to use --request-sequence for long-form transcription: ~26% faster on 15 s slices (8 slices: 56.95 s versus 77.28 s with one process per slice).
• Both symptoms inject fake text that downstream translation and TTS will speak, so we currently gate them ourselves.

Ask

1. Should the sequence path apply the same silence gate as the single-request path? Right now auto silently returns Okay. there.
2. Is audio_chunk_mode=vad expected to fabricate text over silent stretches? If this is a known limitation, documenting it would help - vad looks like the "safe" choice (and it is the one that fixes Symptom 2), yet it is the one that invents dialogue here.