WhisperJAV：JAV音声向けに Whisper の失敗モードを前提から組み直した字幕生成ツール
ASR/STT subtitle generator. Uses Qwen3-ASR, local LLM, Whisper, TEN-VAD. Noise-robust for JAV
ひと目でわかる
- これは何？
- WhisperJAV は日本語アダルトビデオの音声から SRT 字幕を生成する Python 製ツールで、シーン分割、VAD による区間制限、日本語向け後処理という3点で Whisper 系モデルの幻覚とタイムスタンプ崩れに対処する。MIT ライセンスでローカル実行のみ。
- 誰に向いている？
- 導入を検討すべきなのは、Windows 上でローカル処理を前提にし、FFmpeg が読める形式の長尺日本語音声を扱い、幻覚除去とタイミング補正の挙動を自分で確認できる利用者だ。逆に、クラウド API で完結させたい場合や、話者分離・多言語字幕・リアルタイム処理を求める用途には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Whisper が JAV 音声で壊れる3つの理由を仕様として扱う
README は、このツールが解こうとしている問題をモデル選定の話ではなく音響特性の話として書いている。第1に、JAV 音声は SNR が低く、呼吸や喘ぎといった非言語発声の密度が高い。そのスペクトルが日本語の音節（README の例では fu）に似ているため、モデルは存在しない語を聞き取ってしまう。ささやきから叫びまでの音量変動と、学習コーパスにない役割語も前提を崩す。第2に、長尺の録音では曖昧な区間が続いたときに注意が崩壊し、反復や捏造テキストで空白を埋める。README はこれを Whisper 系モデルの文書化された失敗モードとして引用付きで挙げている。第3に、前処理の逆説で、無条件のノイズ除去やボーカル分離は子音の識別に必要な高域を削り、かえって悪化させる。JAV データでのファインチューニングも、良質なデータセットが乏しいため過学習し当たり外れが大きくなりやすいと説明されている。対象読者は、この3点を自分で検証できるだけの音源と計算資源を持ち、クラウドに媒体を上げたくない人である。
音声抽出から .srt までの流れと、VAD がタイムスタンプを決めるという設計
パイプラインは README の図によれば、音声抽出、シーン検出、任意の音声強調、VAD による音声区間分割、ASR、後処理、SRT 出力という順に並ぶ。シーン検出はメディアの特性から予測した境界で切り、下流の VAD と ASR が似た性質のチャンクを受け取れるようにする。音声強調は既定で無効で、前処理の逆説を踏まえてシーン単位で限定的に使う位置づけになっている。ここで重要なのは、VAD が単なる前処理ではなく、モダンなパイプラインでは字幕タイムスタンプの供給元になっている点だ。ChronosJAV ではテキスト生成とタイミング決定を別工程に分け、時間の骨格は VAD が、語はモデルが担当する。v1.9 以降は既定でアライナーモデルを読み込まず VAD のフレームからタイムスタンプを取るため、VRAM が約 1 GB 減る。語単位のアラインメントが必要な場合は設定で Qwen forced-aligner モードを選べる。anime-whisper や Qwen3-ASR 系の日本語ファインチューンは単体では信頼できるタイムスタンプを出さないため、この分離は回避策ではなく前提の組み替えである。
処理モードと sensitivity の組み合わせ方
モードは balanced（Faster-Whisper、既定）、fidelity（OpenAI Whisper、最も低速で網羅的）、fast（OpenAI Whisper とシーン検出、混合品質向け）、faster（Faster-Whisper、前処理最小、クリーンな音声向け）、qwen（ChronosJAV、Qwen3-ASR）、anime-whisper（ChronosJAV、アニメ・JAV 向けに調整された対話）、transformers（HuggingFace の Kotoba など）、crispasr（外部の CrispASR ビルドを持ち込む実験的枠）の8つ。sensitivity は全モードに適用され、conservative、balanced、aggressive の3段階で、aggressive はささやきや ASMR 系の音声で小さい対話を拾う方向に振られており、README によればベンチマーク作業の多くがこの設定を目標に調整されている。注意したいのは、モードと sensitivity が独立した軸ではないことだ。fast や faster は前処理が軽いぶん、aggressive にすると非言語発声を語として拾う余地が増える。逆に conservative はノイズの多い素材で偽陽性を減らすが、小声の対話を落とす。README 自身が「結果は元音声の品質で変わる」と書いており、モード表は性能保証の一覧ではない。
後処理が実際に何を捨て、何を残すか
後処理は日本語固有の工程で、README は5つを挙げている。終助詞（ね、よ、わ、の）、相槌（うん、はい）、関西弁などの方言パターンを意識した文の再グループ化。幻覚と反復の除去。音のみの行の削除。タイミング修復。シーン境界の重複解消。このうち最も挙動が読みにくいのは音のみの行の削除で、喘ぎや呼吸だけの仮名行を落とすが、実際の対話は evidence check で保護されるという。つまり判定は文字列の見た目ではなく根拠の有無に依存しており、その閾値は README には書かれていない。タイミング修復は、テキストに対して長すぎる字幕の開始時刻を手前側に寄せ、終了時刻は動かさない。コンソールは何行が再調整されたかを報告するので、自分の音源でこの数字を追えば後処理がどれだけ介入したかは把握できる。シーン境界の重複解消は、シーン分割と VAD を別々に行う構造から必然的に生じる重複を処理する工程である。
導入コマンドと設定の入口
GUI は Windows インストーラのデスクトップショートカット、または whisperjav-gui で起動する。CLI は 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 で指定する。README には Colab と Kaggle のバッジがあり、notebook ディレクトリに WhisperJAV_colab_edition_expert.ipynb と WhisperJAV_kaggle_parallel_edition.ipynb が置かれている。ローカル実行を掲げるツールでありながら Colab と Kaggle の導線があるのは、GPU を持たない利用者を想定したものと読めるが、その場合「クラウドに媒体を上げない」という前提は成立しない。この点は README 内で説明されていない。
向かない場面：話者分離も翻訳もリアルタイムも対象外
README が扱う範囲は単一トラックの日本語音声から字幕を出すことに限られる。話者分離、すなわち誰が話したかの識別には触れていない。翻訳も同様で、出力は認識した日本語のテキストであり、aitranslate というトピックは付いているが README に翻訳工程の説明はない。リアルタイム処理の記述もなく、feature-length の録音を前提にした設計である。もうひとつの制約は音源依存性で、README は「魔法ではない」と明記し、既定値は ground-truth ベンチマークに対して調整されていると述べるにとどまる。したがって、収録環境が大きく異なる音源や、BGM が対話と同程度の音量で重なる音源では、後処理の evidence check がどれだけ機能するかを事前に予測できない。crispasr モードは実験的と明記されており、外部ビルドを持ち込む前提のため、安定運用の選択肢としては扱いにくい。
代替との違い：WhisperX 型のアラインメントではなく VAD を骨格にする
一般的な Whisper 系パイプラインは、ASR モデルにタイムスタンプを出させ、必要なら別のアラインメントモデルで語単位に整える。WhisperX などが代表で、モデル側のタイムスタンプ品質がそのまま字幕品質に効く。WhisperJAV の ChronosJAV はこの順序を逆にし、VAD が時間の骨格を先に決め、モデルには語だけを出させる。v1.9 以降はアライナーを読み込まないため、アラインメント用モデルのぶんの VRAM が不要になる。代償は、VAD が検出しなかった区間には字幕が原理的に付かないことだ。アラインメント方式ならモデルが語を出した位置に字幕を置けるが、VAD 方式ではその語が VAD の外にあれば落ちる。ささやきや長い間の多い素材で sensitivity を aggressive に振る必要があるのは、この構造上の帰結である。もうひとつの違いは、音声強調を既定で切っている点で、ノイズ除去を最初に挟む構成とは思想が逆になる。
維持コストとライセンス、導入前に確認する3点
リポジトリは MIT ライセンスで、archived ではない。リリースは v1.9.0（FireRedVAD、QwenASR finetuned、CrispASR、字幕タイミング改善）、v1.8.14（品質強化とバグ修正）、v1.8.13（anime、qwen、ollama の改善）と続いており、2026 年 8 月から 9 月にかけて更新が続いている。MIT はソフトウェアの利用条件を定めるもので、処理対象の映像や音声そのものの権利、あるいは ASR モデル側のライセンス条件については何も述べていない。モデルを差し替える構成である以上、同梱または取得する各モデルの条件は別途確認が必要で、ここで法的判断はしない。維持コストの面では、モードごとに異なるエンジンとモデルを読み込む設計のため、依存の更新はモード単位で影響範囲が分かれる。導入前に確認すべきは、balanced と qwen を同じ音源に当てた出力差、aggressive で quiet な区間がどう拾われるか、そして sound-only line removal が実 dialogue を誤って落とさないかの3点である。いずれも手元の音源でしか判定できない。
編集部の結論
導入を検討すべきなのは、Windows 上でローカル処理を前提にし、FFmpeg が読める形式の長尺日本語音声を扱い、幻覚除去とタイミング補正の挙動を自分で確認できる利用者だ。逆に、クラウド API で完結させたい場合や、話者分離・多言語字幕・リアルタイム処理を求める用途には向かない。試す前に確認すべきは、README が示す balanced と qwen の出力差、--sensitivity aggressive で quiet な区間がどう拾われるか、そして後処理の sound-only line removal が自分の音源で実 dialogue を誤って落とさないかである。この3点は手元の音源でしか判定できない。
コミュニティノート