x264guiEx 1.55

要望の反映など。
・x264のメッセージの一行がものすごく長い場合、自動的に改行するようにした。
・音声設定にflacの設定を追加。

改行に関連してデフォルトログウィンドウサイズを調整(変更)。



ダウンロード>>

x264guiExの導入>




スポンサーサイト

コメントの投稿

非公開コメント

ありがとうございます

改行の報告をしたものです

使ってみたところ改行ができていることを確認しました
更新ありがとうございました

No title

x264guiEx.auoで音声をエンコ(qaac等で)すると、
Aviutlで音声を読み込んだ時と比べて
約0.07秒程音がずれるのは私だけでしょうか?
WAV出力だと全くずれないので気になります。
ソースはUtVideoCodecで可逆圧縮したAVIです。

No title

圧縮音声でずれるというのであれば、エンコーダディレイかな。
んー、でも0.07秒ずれるというのはしっくりこないな。qaacなら約0.04~5秒なら分かるんですが。Neroなら0.054~0.06秒くらい。faacなら0.02秒くらい。(44100Hz, 48000Hzを想定してます)

エンコーダディレイはMDCTを使用する音声コーデック(MP3, AAC, AC-3, Vorbis等)では必ず生じるものです。 
これを解決するためにMP3ではLameタグ、MP4に格納された音声ではiTunSMPBやedit listといったものががプレイヤーにこれだけエンコーダディレイがあるからスキップしてね-、という情報を送るための用途として考えられているんですが、FLVとかMKVとかの規格やソフトウェアの作者はこれを大体にして考慮してないので、ユーザーが意識して使用しているコンテナにエンコーダディレイを打ち消すディレイを設定しないと、エンコーダディレイの分だけずれたり、あるいはデコーダがペアとなっているエンコーダのエンコーダディレイを暗黙に想定してスキップして、想定と違うエンコーダが違う場合、結果としてずれるといったケースがあります。
libavcodecのAACデコーダは勝手にスキップしないので、スプリッタ次第では、コンテナに設定したものが正確に反映されます。

そこら辺をちゃんと設定出来ていて且つデコーダなりスプリッタ(demuxer)がそれらを正しく解釈できるのであれば、ずれるということは無いはずです。

No title

>muken氏
返信ありがとうございます。

>コンテナにエンコーダディレイを打ち消すディレイを設定しないと
私はそういった知識に乏しいのでお聞きしたいのですが、x264guiEx.auoでこれの設定は出来るのでしょうか?

No title

えーとですね、私自身はx264guiEx.auoを一切使っていないので、外部muxerを使用した場合の設定方法とかは分かりかねます。
外部muxerにオプションを渡せるなら、ディレイを設定するオプションを使用すれば可能でしょうが。

x264_L-SMASHならば、mp4/3gpp/mov形式で出力するならば、
1. 外部から既にエンコードしたものをインポートしてmuxする場合
--primingオプションを使い、音声サンプル単位で設定します。
この方法は、ユーザーがエンコーダがどれだけのエンコーダディレイを付加したのかを認識していないといけません。
LC-AACなら
iTunes, QuickTime: 2112
Nero: 2624
faac: 1024
等。
2. 内部エンコーダを使って直接muxする場合
x264cliが音声エンコーダから直接エンコーダディレイの大きさを教えてもらえるので、自動的にエンコーダディレイの大きさをセットします。
この方法は、ユーザーはどのエンコーダがどの程度のエンコーダディレイを持っているのか知る必要が無いので、使用できない理由がなければ一番楽です。

No title

>muken氏
返信ありがとうございます。

つまり、x264guiEx.auoでmp4を出力する際に、先に音声をqaacでエンコードし、それをx264(L-SMASH)の --audiofile "%{audpath}" --acodec copy でmuxした場合は、エンコーダディレイ分を打ち消すディレイが自動的に付加されているという認識で合ってますでしょうか?

No title

qaacでエンコードしたときに、qaacがエンコーダディレイの大きさの情報を付加している場合には、「はい」。
と、言いたいところなのですが、「いいえ」。
なぜならば、x264_L-SMASHはlibavformatまたはL-SMASHのimporterからAACのストリーム情報を取得するわけなんですが、libavformat側では未だにエンコーダディレイを取得する術を持っていませんし、L-SMASH importerはADTS AACを読んでmuxするわけですが、ADTS AACにはエンコーダディレイの大きさを示す機能が存在しません。

従って、qaacでエンコードしたときに、qaacがそのような情報を付加していない場合にも、至極当然に「いいえ」。

エンコードしたファイルフォーマットがエンコーダディレイの大きさを明示する機能を備えていない場合、あるいは規格でエンコーダディレイの大きさを規定していない場合では、エンコーダディレイをユーザーが意識せず設定する方法は、エンコーダがmuxerに直接その大きさを教えてあげる以外の方法はありません。
エンコードしたストリームにエンコーダディレイが書かれてない、エンコーダとmuxerの連携が取れていない、のであれば、手動で指定してあげる必要が出てきます。

例えば、qaacでLC-AACで既にエンコードしたものをx264_L-SMASHに渡す場合では
--audiofile "%{audpath}" --acodec copy --priming 2112
というようにエンコーダディレイ(priming samples)をこちらが手動で教えてあげなければなりません。

No title

>muken氏
返信ありがとうございます。

無事に音ずれすること無くmuxすることが出来ました。
ありがとうございました。

No title

flacの対応ありがとうございました。

No title

前に音ずれを聞いた者です。
rigaya氏、muken氏に聞くのは筋違いではありますが。
qaacで音声だけをエンコする際、qaacのオプション --delay でエンコーダディレイを付加させると思うのですが、この時、2112分のディレイをどう記述していいのかが分かりません。
ただ単に --delay 2112 と記述するだけだとmsとして認識されるので。
そもそもmsで記述するしか方法が無いのかな。

No title

qaacの--delayを見てみたのですが、これはエンコーダへの入力時に落とす(負)か無音を挿入するか(正)のオプションのようですね。
ですので、エンコーダディレイを打ち消す用途には使えません。

qaacはデフォルトでiTunSMPBを書き込みますから、サポートしているdemuxerやプレイヤーならエンコーダディレイはそのままでも打ち消せるでしょう。
しかし、大抵のdemuxerやプレイヤーはiTunSMPBをサポートしてないので(ffmpeg/libavもサポートしてません)、再生時に役に立つかというと、ビミョー、としか言えません。

ですので、edit listを付与してエンコーダディレイを打ち消すようにするのがよろしいと思います。
不完全ながらサポートしているdemuxerやプレイヤーがiTunSMPBよりは存在します。
MP4Boxなら
MP4Box -delay -44 -add input.m4a -new output.m4a
ここで-48は2112を48000Hzを仮定してmsに直したモノです。
2112 * 1000 / 48000 = 44
44100Hzなら
2112 * 1000 / 44100 ≒ 48
となります。
頭を落とすので負の値をここでは指定します。

No title

>muken氏
返信ありがとうございます。

とても分かり易い説明なのですが、ちょっと疑問に思った部分があるのでお聞きします。

>ここで-48は2112を48000Hzを仮定してmsに直したモノです。
この-48は48000Hzを仮定しているものと書いてありますが、その下に書いてある
2112 * 1000 / 44100 ≒ 48
を見るとHzが矛盾しているように感じたのは私の勘違いでしょうか?

No title

ぶほ。
誤植です。ついでにMP4Boxのオプションも誤植しました。トラックのIDを示さないといけないのでした。
(なお、-add input.m4a#audio:delay=hogehoge でも出来ますが、 公式のビルドがバグっているのでパッチをあてているビルド以外で使用するのは止めましょう)

MP4Boxなら、
MP4Box -delay 1=-44 -add input.m4a -new output.m4a
ここで __ -44 __ は2112を48000Hzを仮定してmsに直したモノです。
その直前の 1 は -delay を施したいトラックのIDです。
MP4Box -info input.m4a
で、どのトラックがどんなIDを持っているのか調べることができます。

サンプル数で表されたエンコーダディレイをmilliseconds(ミリ秒, ms)の近似値で算出する計算式は、
エンコーダディレイ[milliseconds] = (エンコーダディレイ[サンプル数]) * 1000[milliseconds] / サンプリング周波数[Hz = サンプル数/seconds]
となります。[]内は単位。

従って、44100Hzの場合では、2112サンプルのエンコーダディレイをmillisecondsの近似値で出すには
2112 * 1000 / 44100 ≒ 48
となります。

No title

>muken氏
返信ありがとうございます。

>で、どのトラックがどんなIDを持っているのか調べることができます。
それを試してみたところ、エラーが出て調べることが出来なかったのでMediaInfoでIDを調べることにしました。

結果殆ど音ずれが無い音声が出来ました。
本当にありがとうございました。
プロフィール

rigaya

Author:rigaya
アニメとか見たり、エンコードしたり。
連絡先(@を半角にしてください!)
rigaya34589@live.jp
github

最新記事
最新コメント
カテゴリ
月別アーカイブ
カウンター
検索フォーム
いろいろ
公開中のAviutlプラグインとかのダウンロード

○Aviutlプラグイン
x264guiEx 2.xx (ミラー)
- x264を使用したH264出力
- x264guiExの導入>
- x264.exeはこちら>

x265guiEx (ミラー)
- x265を使用したH.265/HEVC出力
- x265.exeはこちら>

QSVEnc + QSVEncC (ミラー)
- QuickSyncVideoによるH264出力
- QSVEncCはコマンドライン版
- QSVEncC 導入/使用方法>
- QSVEncCオプション一覧>

NVEnc + NVEncC (ミラー)
- NVIDIAのNVEncによるH264出力
- NVEncCオプション一覧>

VCEEnc + VCEEncC (ミラー)
- AMDのVCEによるH.264出力

ffmpegOut (ミラー)
- ffmpeg/avconvを使用した出力

自動フィールドシフト (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: aji様

エッジレベル調整MT (ミラー)
- エッジレベル調整の並列化/高速化
- SSE2~AVX対応
- オリジナル: まじぽか太郎様

バンディング低減MT (ミラー)
- SSE2~AVX2による高速化版
- オリジナル: まじぽか太郎様

PMD_MT (ミラー)
- SSE2~FMA3による高速化版
- オリジナル: スレ48≫989氏

透過性ロゴ (ミラー)
- SSE2~FMA3によるSIMD版
- オリジナル: MakKi氏

AviutlColor (ミラー)
- BT.2020nc向け色変換プラグイン
- BT.709/BT.601向けも同梱

○その他
x264afs (ミラー)
- x264のafs対応版

aui_indexer (ミラー使い方>)
- lsmashinput.aui/m2v.auiの
 インデックス事前・一括生成

auc_export (ミラー使い方>)
- Aviutl Controlの
 エクスポートプラグイン版
 エクスポートをコマンドから

aup_reseter (ミラー)
- aupプロジェクトファイルの
 終了フラグを一括リセット

CheckBitrate (ミラー, 使い方, ソース)
- ビットレート分布の分析(HEVC対応)

チャプター変換 (ミラー使い方>)
- nero/appleチャプター形式変換

エッジレベル調整 (avisynth)
- Avisynth用エッジレベル調整

メモリ・キャッシュ速度測定
- スレッド数を変えて測定

○ビルドしたものとか
L-SMASH (ミラー)
x264 (ミラー)
x265 (ミラー)

○その他
サンプル動画
その他

○読みもの (ミラー)
Aviutl/x264guiExの色変換
動画関連ダウンロードリンク集
簡易インストーラの概要

○更新停止・公開終了
改造版x264gui
x264guiEx 0.xx
RSSリンクの表示
リンク
QRコード
QR