WhisperJAV：用 VAD 夾具與場景切分，壓制 Whisper 在成人影片音軌上的幻覺
ASR/STT subtitle generator. Uses Qwen3-ASR, local LLM, Whisper, TEN-VAD. Noise-robust for JAV
秒懂
- 它是什麼？
- WhisperJAV 把已知的 Whisper 失效模式當成設計前提：場景切分、VAD 限縮、防禦性解碼與日文後處理。本文從機制、安裝、模式差異到限制逐項檢查，說明它適合誰、不適合誰。
- 適合誰用？
- 如果你的素材是長篇、低訊噪比、非語音人聲密集的日語音軌，而且你接受在本機跑模型、自行承擔 VRAM 佔用與模型下載成本，WhisperJAV 的 VAD 夾具加場景切分是針對這類失效模式設計的合理做法。若你的素材是乾淨訪談、多人會議或非日語內容，這些日文導向的後處理規則不會帶來對應好處，改用一般 Whisper 前端即可。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 3 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解決的不是辨識率，而是辨識在特定音軌上的崩壞方式
把 Whisper 用在 JAV 音軌上，問題通常不出在「聽不清楚」，而是出在模型聽得太有自信。README 把失效拆成三點：音訊的低訊噪比與大量非語音人聲（呼吸、喘息）頻譜逼近真實日語音節，例如 fu，模型會在有聲音但沒有詞的地方生出詞；長篇錄音在靜音或節奏性呼吸的段落上注意力崩解，填進重複或憑空發明的文字；而直覺上的「先去噪再辨識」會把分辨子音所需的高頻細節一起帶走。第三點是這個專案最值得記住的立場：前處理不是越多越好。目標讀者是手上有一批日語長片、不想把媒體上傳雲端、且願意在本機跑模型的人。它不處理翻譯品質，也不處理字幕排版美學，產出就是 SRT 或 WebVTT。
資料流：場景切分先於 VAD，VAD 先於 ASR
README 的流程圖寫得很直白：音訊抽取、場景偵測、語音增強（選用）、VAD 語音分段、ASR、後處理、輸出 .srt。順序本身就是設計主張。場景偵測依媒體特徵切出預測場景，目的是讓下游的 VAD 與 ASR 拿到「DNA 相近」的區塊，而不是把不同錄音環境混成同一條流。VAD 再在每個場景內找出真正有語音的位置，只把那些片段餵給模型，並加上經過測量的 padding，README 稱這是對抗非語音幻覺的主要防線。最後是日文導向的清理：以語尾助詞（ね、よ、わ、の）、相槌（うん、はい）與方言（關西腔等）為判斷依據的句子重組、幻覺與重複移除、純狀聲詞行移除（真正的對白由證據檢查保護）、時間修補（文字長度與字幕時長明顯不符時，把開始時間往前拉、結束時間不動，主控台會回報重計了幾個行），以及場景邊界重疊的處理。
ChronosJAV：把文字生成與時間軸拆成兩件事
這個專案對「模型自己給時間戳」並不信任，理由是這個領域表現最好的幾個辨識器（anime-whisper、Qwen3-ASR 及其日語微調版本）本身不產出可靠時間戳。ChronosJAV 因此把兩者分開：VAD 提供時間骨架，模型只負責文字。自 v1.9 起時間戳預設直接取自 VAD 幀，不載入對齊模型，README 說可省下約 1 GB VRAM；設定中仍保留 Qwen forced-aligner 模式做詞級對齊。這個解耦同時解釋了為什麼新模式能接進來而不必重建流程：任何能把音訊轉成文字的元件都能插進去。代價是時間精度上限由 VAD 決定，而不是由聲學對齊決定；如果你要的是卡拉 OK 級別的詞級時間軸，就得回頭開 forced-aligner。
安裝與實際指令
安裝路徑有兩條。Windows 安裝檔會建立桌面捷徑；不想用 GUI 的話，命令列入口是 whisperjav-gui 與 whisperjav。README 給的例子包括 whisperjav video.mp4 走預設值、whisperjav video.mp4 --mode balanced --sensitivity aggressive，以及 whisperjav /path/to/folder --output-dir ./subtitles 處理整個資料夾。輸出格式用 --output-format both 可同時產生 SRT 與 WebVTT，預設是 SRT，字幕檔會落在影片旁邊。輸入只要 FFmpeg 讀得動就行，MP4、MKV、AVI、WMV、MP3、WAV、FLAC 都列在文件裡。另外有 Colab 與 Kaggle 的 notebook 版本，分別對應 expert 與 parallel 兩種設定。要注意的是，README 只交代了指令與旗標，並沒有列出模型下載大小、首次執行的耗時或各模式的實測速度，這些得自己量。
模式與敏感度：選項很多，但差異集中在引擎與前處理量
八個模式大致可分成三類。balanced（Faster-Whisper，預設）、fidelity（OpenAI Whisper，最慢最徹底）、fast（OpenAI Whisper 加場景偵測）、faster（Faster-Whisper，最少前處理，適合乾淨音訊）是經典管線，差別在速度與前處理深度。qwen（ChronosJAV，Qwen3-ASR）與 anime-whisper（ChronosJAV）屬於文字優先的現代辨識器，走前述的 VAD 供時間軸路線。transformers 讓 HuggingFace 上的 Whisper 模型（例如 Kotoba）進來，crispasr 則是自備 CrispASR 建置的外部模式，README 明確標為實驗性。敏感度是獨立於模式的另一個軸：conservative 減少誤判、適合吵雜內容，balanced 居中，aggressive 抓更多小聲對白、適合耳語或 ASMR 類素材，README 也說這是多數基準調校的目標。
限制與不適用的情況
README 自己承認「結果仍隨來源音訊品質變動」，而預設值是對照基準調出來的，意思是換一批素材就可能要重調。純狀聲詞行移除雖然有證據檢查保護真實對白，但這類規則本質上是啟發式，遇到以喘息為主、對白極少的段落，誤刪與漏刪的風險同時存在，而文件沒有給出可調的門檻值。時間修補只把開始時間往前拉、結束時間不動，對「字幕早於語音」是合理修正，但若問題其實是結束時間太早，這個策略幫不上忙。場景偵測依媒體特徵切分，遇到整片單一場景、或場景轉換極頻繁的素材，切點品質就取決於偵測器而非專案邏輯。最後是領域綁定：後處理規則圍繞日語語尾、相槌與方言設計，拿來處理中文、英文或多人會議錄音，這些規則不會帶來對應好處，反而多一層可能誤傷的過濾。
替代方案與方法論差異
最直接的替代是直接用 Whisper 家族的官方或社群前端，把整段音訊丟進去拿時間戳。差別在架構而非模型：WhisperJAV 把時間軸的責任交給 VAD，模型只輸出文字；一般前端則讓模型自己產生時間戳，於是模型在模糊音訊上的注意力崩解會同時污染文字與時間。另一個方向是自建管線，用 silero-vad 或同類工具做分段、再接自己選的 ASR，彈性最大，但日文句子重組、幻覺過濾、狀聲詞行移除這些後處理得自己寫，而這正是 WhisperJAV 花最多篇幅描述的部分。若你只是要快速轉錄一段乾淨日語訪談，兩者都不必，官方 Whisper 前端就夠。
維護、授權與升級成本
授權是 MIT，對商業或內部使用都相對寬鬆，但這裡不構成法律意見，實際條款仍以倉庫的 LICENSE 為準；另外要留意各模式會拉進不同的模型權重，那些權重各自的授權與 MIT 無關，需分開確認。維護節奏從版本紀錄看得出來：v1.8.13 處理 anime、qwen 與 ollama 的改進，v1.8.14 是品質強化與錯誤修正，v1.9.0 加入 FireRedVAD、QwenASR 微調、CrispASR 與字幕時間改進。功能推進快，代表升級不是無痛：v1.9 把時間戳預設改成取自 VAD 幀，這會改變既有輸出的時間行為，如果你先前依賴 forced-aligner 的詞級對齊，升級後得回設定裡重新開啟。外部模式（crispasr）自備建置，等於把相容性維護的責任分攤給使用者。
編輯結論
如果你的素材是長篇、低訊噪比、非語音人聲密集的日語音軌，而且你接受在本機跑模型、自行承擔 VRAM 佔用與模型下載成本，WhisperJAV 的 VAD 夾具加場景切分是針對這類失效模式設計的合理做法。若你的素材是乾淨訪談、多人會議或非日語內容，這些日文導向的後處理規則不會帶來對應好處，改用一般 Whisper 前端即可。動手前先確認三件事：你的 GPU 能否同時容納所選模式與 ChronosJAV 的 VAD 流程，你的 FFmpeg 能否解出音軌，以及先用 --mode balanced 配 --sensitivity conservative 跑一小段，比對 SRT 中的重複行與純狀聲詞行是否被清掉，再決定要不要換到 qwen 或 anime-whisper。
社群筆記