[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 06/06 15:25 / Filesize : 278 KB / Number-of Response : 907
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【ニコニコ動画】FLV/MP4作成スレ37【質問】



103 名前:名無しさん@お腹いっぱい。 mailto:sage [2008/03/18(火) 19:13:36 ID:f+yPfr+k0]
まず、圧縮音声のデコードについて簡単に説明してみる。
分かりやすくイメージで書くが、PCMのソース音源を数字で、圧縮後をアルファベットで書くと、
0123 4567→AB CD
というのが圧縮を表して、Aには01という音声が格納されていると思ってくれぇ。
これをデコードするときに、AB CDをデコーダに放り込んでも、一気に全部がデコードされて出てくるわけではない。
AB→__01 [23]バッファ
連続してデコードすると、このバッファにたまった分が吐き出されてくるので、問題なく再生できる。(※これをデコードディレイという)
CD→2345 [67]バッファ

AviUtlは、出力プラグインから指示されたオーディオのデコード命令を、独自加工して処理している。
この独自加工が音声破壊の原因で、たとえばPCMの数字3つ分ずつ処理するように動く。
012|345|678|901
PCMなら問題ないが、これを圧縮音源でおこなうと、最初の012を取得するために
AB→__01[23]
とデコードして、無音+0を取得する。つづけて345を取り出そうとBCをデコードしようとするが、バッファにデータが残っているので、
BC→2323[45]
とデコードして、323を取得してしまう。余分な3の部分がプチ音。あとはこの間違ったデコードの繰り返し。
この「数字3つずつ」という部分が、出力プラグインが指示するデコードサンプル数で決定するらしい。
AviUtl本体のWAV出力は、独自加工の部分が発生しない(というか元々組み込まれている)ので、ABCDEFGHI…と連続でコードされる。

x264guiは、作者さんが調査してある程度は対応できような事がreadmeに書いてあったけど、44.1kHzの音声の場合はサンプル処理で端数が
出るので、カットなんかするとデコードがおかしくなる場合もあるだろうね。
48kHzなら端数でないから大丈夫じゃなかろうか。







[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<278KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef