WhisperJAV：把 Whisper 的幻觉问题当成工程问题来解
ASR/STT subtitle generator. Uses Qwen3-ASR, local LLM, Whisper, TEN-VAD. Noise-robust for JAV
秒懂
- 它是什么？
- 这个项目不训练新模型，而是围绕 Whisper 系模型在长音频、低信噪比日语语音上的已知失效点做流水线改造：场景切分、VAD 夹取、防御式解码与日语后处理。它的价值在于承认模型会出错，并把出错的位置一个个堵上。
- 适合谁用？
- 如果你手上有大量低信噪比、带大量非语言人声的日语长音频，且愿意在本地跑 GPU 推理，WhisperJAV 的 VAD 夹取与日语后处理比裸跑 Whisper 更值得先试；如果你的音频本身干净、时长很短，或者你只是需要一次通用语音转写，直接调用 Faster-Whisper 更省事，多出来的场景切分和过滤步骤只会增加调参面。上手前先确认三件事：你的显卡显存能否容纳所选模式（qwen 模式在 v1.9 之后默认不加载对齐模型，文档称可省约 1 GB 显存），你的音频是否需要 aggressive 灵敏度（该档位针对耳语与 ASMR 类内容调参），以及你是否接受 .srt 作为唯一交付格式。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 3 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它要解决的不是识别率，而是识别在什么地方崩掉
通用语音识别模型是在干净、经过整理的语音上训练的。JAV 音频几乎站在这个假设的对立面。README 把这种错配拆成三条：声学层面，信噪比低，非语言发声（呼吸、喘息、呻吟）密度高，其中一些频谱与真实日语音节相似，比如 fu，模型会因此听到并不存在的词，再加上从耳语到喊叫的极端音量起伏，以及训练语料里没有的戏剧化角色语；长音频层面，这类素材是正片长度而不是 30 秒片段，在长时间的模糊音频上模型的注意力会塌陷，开始重复或编造文本；预处理层面，直觉上的先降噪反而可能抹掉区分辅音所需的高频细节，而在 JAV 数据上做微调又因为好数据集稀缺而容易过拟合。
目标用户因此很明确：手上有本地日语长音频、需要字幕、并且愿意接受一套围绕已知失效点搭起来的流水线，而不是一个开箱即用的通用转写器。项目用 MIT 许可发布，主语言是 Python，媒体不上传云端，这是它相对在线转写服务最直接的区别。
音频到字幕的六段式流水线，以及每段在防什么
README 给出的流程图是线性的：音频提取、场景检测、语音增强（可选）、VAD 语音切分、ASR 模型、后处理，最后输出 .srt。每一段都对应上面某个失效点。
场景检测按媒体特征预测切点，把音频切成声学上同质的块。这样下游的 VAD 和 ASR 拿到的是相似来源的片段，而不是把安静对白和激烈场景混在一条流里。语音增强默认关闭，README 明确说它是按场景外科式使用的，理由就是前面那条预处理悖论。VAD 是整套设计的重心：它决定模型听到什么，在较新的流水线里还决定字幕时间戳从哪来。文档称这是防御非语音幻觉的主要手段。
后处理是日语专属的清理层，列出的动作包括：识别终助词（ね、よ、わ、の）、相槌（うん、はい）和关西方言等方言模式的句子重组；幻觉与重复去除；纯拟声行删除（只含呻吟或呼吸假名的字幕行会被丢掉，真实对白由证据检查保护）；时间修复（文本很短但时长离谱的字幕行会把起点前移，终点不动，控制台报告有多少行被重定时）；以及场景边界重叠消解。
这里的设计取向值得点出来：时间修复只动起点不动终点，说明作者宁可让字幕晚一点出现，也不愿意让字幕盖住后面的对白。这是个保守的选择，不是唯一正确的选择。
ChronosJAV 把文本生成和时间戳拆成两件事
这是整个项目里最值得单独看的一段设计。README 说，这个领域里一些最好的识别器，包括 anime-whisper、Qwen3-ASR 及其日语微调版本，本身不能可靠地产生时间戳。ChronosJAV 的做法是把文本生成和计时拆成两个阶段：VAD 提供时间骨架，模型只负责给词。
自 v1.9 起，时间戳默认来自 VAD 帧，不加载对齐模型，文档称这样可以省下约 1 GB 显存；如果需要对词级对齐，设置里仍保留 Qwen forced-aligner 模式。这个解耦带来一个实际的扩展性：任何能把音频变成文本的模型都能接进来，不需要重建流水线。
代价也在这里。时间戳精度上限由 VAD 帧决定，不再由专门的强制对齐模型决定。对字幕来说，这意味着断句边界更依赖 VAD 的判定质量，而不是模型对音素的细粒度判断。想要词级对齐就得把那一块显存加回来。
安装与运行：GUI、命令行和九种模式
GUI 是推荐路径，Windows 安装包会创建桌面快捷方式，或者直接运行：
whisperjav-gui
命令行用法在 README 里有三个例子：
whisperjav video.mp4 whisperjav video.mp4 --mode balanced --sensitivity aggressive whisperjav /path/to/folder --output-dir ./subtitles
输入格式取决于 FFmpeg 能读什么，文档列举了 MP4、MKV、AVI、WMV、MP3、WAV、FLAC 等。输出默认 SRT，也支持 WebVTT，用 --output-format both 同时产出两种。
模式表里列了九个：balanced（Faster-Whisper，默认，完整流水线）、fidelity（OpenAI Whisper，经典流水线里最慢最彻底）、fast（OpenAI Whisper 加场景检测）、faster（Faster-Whisper，最小预处理，速度优先）、qwen（ChronosJAV，Qwen3-ASR）、anime-whisper（ChronosJAV，动漫与 JAV 调优对白）、transformers（HuggingFace，Kotoba 等 HF Whisper 模型）、crispasr（外部，自带 CrispASR 构建，实验性）。
灵敏度对所有模式生效，三档：conservative 减少误报，适合嘈杂内容；balanced；aggressive 捕捉更多轻声对白，适合耳语与 ASMR 类内容，README 说这也是大部分基准调参的目标。选模式之前先想清楚你的音频属于哪一类，因为 balanced 和 aggressive 的差别不是精度高低，而是针对不同信噪比分布的取舍。
两遍集成与可替换组件：README 在这里截断了
README 里有一个 Two-pass ensemble 小节，但提供的材料在 Differ 这个词之后就截断了。因此两遍集成具体怎么投票、怎么合并结果、在哪些模式下启用，我无法从现有材料确认，这里不做推测。
能确认的是组件可替换这件事本身：README 说每个阶段都有若干可互换的 provider，完整清单连同各自的强弱项在 Mix-and-match strategies 一节里，而这一节同样不在提供的材料范围内。
对准备采用的人来说，这意味着两件事。第一，流水线的结构是稳定的六段，但每一段填什么可以换，这是它相对单体脚本的优势。第二，评估这个项目时不能只看默认模式的表现，因为默认组合只是众多组合中的一种，而文档把选择权交给了用户，也就把选择成本交给了用户。
它不擅长什么，以及什么时候该换别的工具
README 自己给了最诚实的一句：这些都不是魔法，是围绕已知模型弱点做的细致管道，默认值是在基准上调出来的，结果仍会随源音频质量变化。换句话说，当语音本身在音频里已经不可辨时，这套流水线不会凭空恢复它。
更具体的边界有三条。第一，后处理里的纯拟声行删除会主动丢弃只含呻吟或呼吸假名的字幕行，文档说真实对白由证据检查保护，但证据检查的判定边界是什么，材料里没有给出，这类过滤天然存在误删安静对白的风险。第二，语音增强默认关闭，说明作者认为它在多数情况下弊大于利，如果你指望靠它救回一段糟糕的录音，README 的立场是相反的。第三，crispasr 模式被标为实验性，且需要自带 CrispASR 构建，不是拿来即用的路径。
如果你的音频干净、时长在几分钟以内，或者你需要的只是通用语音转写而不是日语字幕，直接用 Faster-Whisper 或 OpenAI Whisper 更直接：WhisperJAV 多出来的场景切分、场景边界重叠消解和日语后处理，在这个场景下只会增加需要理解和调试的环节。它的设计前提是长音频加低信噪比，前提不成立时，这些环节的价值也就消失了。
作为对照，Faster-Whisper 走的是另一条路：它优化的是同一类模型在推理速度和显存占用上的表现，通过 CTranslate2 重写推理后端，但不对输入音频做场景切分，也不做 VAD 夹取和日语专属后处理。两者要解决的问题不同，Faster-Whisper 回答的是怎么更快地跑 Whisper，WhisperJAV 回答的是 Whisper 在这类音频上会在哪里出错、怎么堵。
维护节奏、许可与升级时要看的东西
仓库未归档，最近一次推送是 2026 年 9 月 5 日。发布节奏可以从三个版本看出来：v1.8.13（2026 年 5 月 5 日，anime、qwen、ollama 相关改进）、v1.8.14（2026 年 5 月 10 日，质量加固与缺陷修复）、v1.9.0（2026 年 8 月 15 日，FireRedVAD、QwenASR 微调、CrispASR、字幕时间改进）。从 1.8 到 1.9 之间隔了三个月，中间夹了一个以修复为主的补丁版本，说明这个阶段既有新组件接入，也有稳定性收尾。
升级成本主要落在两处。一是模式与组件的增减：v1.9.0 引入了 FireRedVAD 和 CrispASR，而 crispasr 目前是实验性，接入新 VAD 意味着默认行为可能变化。二是 v1.9 把时间戳默认改为来自 VAD 帧，这是一个会直接影响输出字幕时间轴的行为变更，从旧版本升级时值得单独对比同一段音频的前后输出，而不是只看识别文本是否一致。
许可方面，项目采用 MIT，属于宽松许可，允许修改与再分发。这里不做法律意见，但有一点是工程上而非法律上的：项目本身是 MIT，它调用的模型和工具链各有各的许可，Qwen3-ASR、Whisper 系模型、TEN-VAD、CrispASR 的授权条款需要分别确认，MIT 只覆盖这个仓库的代码。
项目提供 Colab 与 Kaggle notebook 入口，另有英文和简体中文文档站点。README 提到默认值是在与 ground truth 基准对照下调出来的，但具体基准数据不在提供的材料里，评估时应当用自己的素材跑一遍再判断。
编辑结论
如果你手上有大量低信噪比、带大量非语言人声的日语长音频，且愿意在本地跑 GPU 推理，WhisperJAV 的 VAD 夹取与日语后处理比裸跑 Whisper 更值得先试；如果你的音频本身干净、时长很短，或者你只是需要一次通用语音转写，直接调用 Faster-Whisper 更省事，多出来的场景切分和过滤步骤只会增加调参面。上手前先确认三件事：你的显卡显存能否容纳所选模式（qwen 模式在 v1.9 之后默认不加载对齐模型，文档称可省约 1 GB 显存），你的音频是否需要 aggressive 灵敏度（该档位针对耳语与 ASMR 类内容调参），以及你是否接受 .srt 作为唯一交付格式。不要指望它在源音频质量差到语音本身不可辨时凭空补出正确文本，README 自己写了结果会随源音频质量变化。
社区笔记