-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement Kotoba-Whisper #1476
Implement Kotoba-Whisper #1476
Conversation
@ooe1123 現在は、longformの場合、音声全部をencodeしてから、チャンク全部をdecode、最後に重複削除してテキスト変換しているかと思います。 これを、通常のwhisperと同様に、音声をチャンク分割し、チャンク単位でencode/decodeし、途中結果をテキスト表示は可能でしょうか? decode後の重複削除が前チャンクしか見ない場合は、1チャンク遅延をしてもよいかなと思います。重複削除が後チャンクを見る場合は、途中結果をprintしつつ、最後に綺麗なテキストをまとめてprintでも大丈夫です。 |
これを行っているのが、chunk_lengthパラメータかと思いますが、
longformの実装はtransformersを元にしており、詳細なアルゴリズムについては理解できていないため、独自に機能を追加するのは残念ながら私には難しそうです。 |
検討、ありがとうございます。 1. preprocess -> chunk_iter -> feature_extractor (全音声が処理されるまでロックされる) 通常のwhisperのコードベースではなく、現在のtarnsformerベースの方が良いと思います。 |
@kyakuno chunk_lengthオプションでは、audioをチャンク分割して(オーバーラップ部分あり)からfeature_extractorを行っていて、 feature_extractor処理前に分割を行う場合、チャンクサイズやオーバーラップのサイズについてどうするべきか、分からない不安要素があるように思います。 ご要望の、
この実装をのせる場合、longformの実装ベースというよりは、chunk_lengthオプションでの実装を拡張する形でよいのではないかと思いましたが、認識にズレはありますでしょうか? |
feature_extractorにつきまして、実体的には、STFTを行なっているようなので、HOP_LENGTH単位で呼び出しを行えば、分割実行を行なっても出力は一致しそうな印象でした。 そのため、generate関数に、
を入れれば、
のように逐次、表示されたので、これで十分そうです。 |
M2 MacのBLASで88secの音声を変換するのに必要な時間。
|
@ooe1123 opset=17でLayerNormalizationが導入されていまして、Transformer系はopset=17で動作させた方が高速になっています。 |
承知致しました。 |
すみません、よろしくお願いします🙇 |
267sec -> 211secに改善しました。 |
opset17
opset11
|
#1455
のPRです。