低音量段落使解碼提前終止，且靜默回報成功：82 分鐘錄音只轉出 69 秒

[kiki830621]

Problem

一段低音量的語音會讓解碼提前終止，而轉錄回報成功。 82 分鐘的錄音只產出涵蓋前 69 秒 的 9 個 cue，transcribe_status 回 done，沒有任何 error、warning 或 exit code 異常。

使用者拿到的是一個看起來正常的 SRT 檔，內容少了 98.6%。

這不是 #154（context 截斷未揭露）的變體。#154 是降低品質；本 issue 是靜默丟掉幾乎全部內容。

Type

bug

Actual

實際輸出（完整檔案，405 bytes）：

1
00:00:00,000 --> 00:00:07,000
看一下

...（中略）...

6
00:00:47,000 --> 00:00:55,000
SAкая

7
00:00:56,000 --> 00:00:59,000
死鬼

8
00:01:00,000 --> 00:01:05,000
Send

9
00:01:06,000 --> 00:01:09,000
魔 ley test

注意 cue 6 的 SAкая 混入西里爾字母、cue 9 的 魔 ley test —— decoder 在崩潰前的 hallucination。

Expected

• 完整轉錄，或
• 明確失敗。回報 done 是本 issue 的核心問題 —— 靜默的部分比截斷本身更嚴重。

重現

#	輸入	backend	模式	結果
1	82 min m4a（16k mono）	mlx-audio / whisper-large-v3-turbo	async	❌ 9 cues，停在 00:01:09
2	同上切出的前 10 分鐘	同上	async	❌ 9 cues，停在 00:01:11
3	同上	同上	sync	❌ 5 cues，停在 00:01:08
4	同一錄音的 t=2000s 起 2 分鐘	同上	sync	✅ 48 cues，完整覆蓋

三次失敗都停在 68–71 秒。 不隨檔案長度變化、async 與 sync 皆然 —— 排除長度與執行模式。

Root cause

輸入音檔在 60–90 秒是全片音量最低處：

時間	mean_volume	max_volume
0s	−29.2 dB	−2.2 dB
30s	−30.6 dB	−8.3 dB
60s	−32.4 dB	−16.9 dB
90s	−27.8 dB	−0.6 dB
120s	−23.7 dB	−0.6 dB
（其後至 4900s）	−23 ~ −28 dB	−0 ~ −8 dB

decoder 死在 68–71 秒，正是這個低音量區間。 90 秒之後音量恢復正常，內容都在 —— 是解碼放棄了，不是音檔有缺。

修法驗證

對同一個 10 分鐘段落套 ffmpeg -af "dynaudnorm=f=200:g=15:p=0.9"（60–90s 的 mean 從 −32.4 dB 拉到 −15.5 dB），其餘參數完全不變：

	cue 數	最後時間碼
原檔	9	00:01:11
正規化後	238	00:09:59.940

單一變數，26 倍差異。

第二個失敗模式（同一批重現中發現）

正規化後把 82 分鐘切成 9 個 10 分鐘段落轉錄，其中 2 段（n00、n01）文字完整但塌成單一 cue：

1
00:00:00,000 --> 00:09:59,740
看一下喔我呃看一下看我們可以一起跟AI討論來來討論你頂著小堂用火談判高便他說...（4,401 bytes，全部擠在一條）

其餘 7 段正常分段（252–392 cues）。同樣是 status: done。

把這兩段再切成 5 分鐘後重跑即恢復正常分段（139 / 86 / 123 / 167 cues）。

此模式先前也出現過 —— 本機留有 08-03 會議....mlx-audio-無時間碼.srt（37 分鐘檔的同型產物）。

Impact

• 使用者無法從輸出判斷是否成功。 檔案存在、格式合法、有時間碼、status: done —— 只有把 cue 數與音檔長度對照才看得出來。本次是人工發現的。
• 影響任何含安靜段落的錄音。會議錄音的開頭（架設、就座、寒暄）天生偏安靜，正是高風險區。
• recommend 最佳化的是 CER，不會警示分段或截斷風險。本次 recommend 給 mlx-audio（CER 0.7%）並無不當 —— 問題不在選型。

建議的處理方向（僅供參考，未讀 codebase）

1. 完整性檢查（最小、最有價值） —— 轉錄後比對「最後 cue 的結束時間」與「音檔長度」，落差超過閾值即 warn 或 fail。本次的 69s vs 4942s 會立刻被抓到。單一 cue 涵蓋整段的情況同理可測。
2. 前處理 —— 對輸入套用動態音量正規化，或至少在偵測到低音量段落時警示。
3. 不要回報 done —— 截斷時應有明確狀態。

第 1 點與後兩者正交：即使不修根因，只要不再靜默，使用者就能自救。

環境

• macOS 27.0，Apple M5 Max
• backend：mlx-audio / whisper/large-v3-turbo（default quantization），profile medium
• 輸入：16 kHz mono，AAC 64k（由 ALAC + AAC 來源正規化而來）
• 經 MCP transcribe 呼叫（bestasr-mcp）

關聯

• context 截斷在預設輸出不揭露：PromptRenderer 宣稱 always disclosed，實際僅 --explain 可見 #154 —— context 截斷未揭露。不同問題：那個降低品質，本 issue 靜默丟掉內容。共通點是「失敗不可見」。