FAWCheck -> 判定FAW -> FAW.exe(fawcl.exe)で処理 -> L-SMASHでmuxだと
ファイルの再生時間の情報が12秒ほど長くなることが分かった。
そのためシークバーがおかしくなってしまう。
なぜなのかよくわからない。調査に時間がかかりそうなので、
とりあえず、mp4出力時、FAWCheckでFAWと出たら、外部muxerでmuxするように変更。
これで問題なく再生はできるけど、
FAWCheckのせいで怪しいファイルができている可能性はまだあるので、
気になる場合はFAWCheckをオフにしてください。(追記)FAWCheckの問題ではなかったです。
この問題を指摘してくださったRさまに感謝です。
ダウンロード>>FAWCheckの問題について詳しく。
問題は、
FAWCheckを行う->
FAWと判定され、fawcl.exe(FAW.exe)で処理される->
自動的にL-SMASHでmuxされる
という流れの時にのみ発生します。
この3つのうち、どれかが違っても問題は発生しません。
たとえば、FAWCheckをして、FAWでないと判定され、
neroaac等で音声エンコードが行われた場合などは問題ないようです。
ですが、はっきり言って原因がよくわかりません。
長くなりますが、さらに詳しく書くと…
FAWかどうかチェックする際に、
Aviutlから最大でwavを12秒ほど読んで判定しています。
ファイルの再生時間が12秒長くなっていますので、
間接的にはこのFAWCheckでwavを読むことが問題と考えられます。
しかし、FAWCheckをしたとしても、
aac一時ファイルの長さ情報に問題はあるようには見えません。
(真空波動研・MediaInfo両方で確認)
このaacファイルを--audiofileでx264_L-SMASHに読ませているだけなので、
本来はAviutlでwavを余分に読んだことは関係ないはずです。
どこでAviutlの「wavをこれだけ読んだ」という情報が音声の長さ情報として
エンコーダに渡ってしまっているのかわからないのです。
なお不思議なことに、FAWCheckをしても、
neroaacenc.exeによるエンコードの場合などでは
問題ない点など、よくわからないことだらけです。
ですが、難しそうな問題で時間がかかりそうなのと、
最近微妙に忙しいのでとりあえず、
FAWCheckでFAWと判定されたときは外部muxer(mp4box)を使用する。
という暫定的な処置にしました。
これで、とりあえず長さ情報に問題は発生しません。
今後もこの問題についてはいろいろと勉強・調査して、
この暫定的な処置のままでいいのか、あるいはもっといい方法があるのか、
あるいはFAWCheckを廃止したほうがいいのかなど判断したいと思います。
すごくインチキくさい単なる回避策なので、
「なんて適当なんだ。怪しいファイルができてたらどうするんだ」
のように、気になる場合はFAWCheckをしないでください。(追記)FAWCheckの問題ではなかったです。
