前 8 - 09 p ｜ 
もくじ i ｜ 次 8 - 11 n 
WAV、MP2などの音声ファイルを、AC3形式に変換。 AC3のエンコードは、一般に高額な機材を必要とするようなイメージがありますが、 「フリー」で行うこともできます。
TVやビデオのデジタル・キャプチャでは、音声としてWAVやMP2（Mpeg Layer2）がよく使われます。 CDをリッピングした場合、44100Hzの16ビットWAVが得られます。 こうした任意の音源をAC3形式（ドルビーデジタル）に変換してみましょう。 得られたAC3はそのままオーディオファイルとすることも、動画の音声成分とすることもできます。
192Kbps程度のレートでは、MP3、AAC、Vorbisのいずれも十分な音質を持っているので、 通常、PC用の動画では、WAVなどで与えられた音源をどうしてもAC3にしたいということは、あまりないと思います。 むしろAC3を変換元にして別形式に変換することが多いでしょう。 しかし、知識として、AC3を変換先とする「逆変換」ができることを知っておいて損はありません。
AC3形式の音声ファイルを作成できると、DVDのオーサリングなどで役立つことがあるかもしれません。
dspguruから、BeSweet（執筆時点での安定版はv1.4、ベータ版はv1.5b21。どちらでも可）と、BeSweetGUIの最新ベータ（執筆時点ではv0.6b83。安定版b61よりもウィザード機能がある最新版を推奨）、さらにプラグインのコーナーから AC3enc（BS_AC3 v0.1）をダウンロードします。
BeSweetGUIv0.6b83.zip（バージョンアップで書庫名は変わる可能性があります） のなかみを、任意のフォルダに解凍します。そのフォルダのなかに BeSweet というサブフォルダを作り（フォルダ名が違うと動作しません）、 そのサブフォルダのなかに BeSweetv1.5b21.zip （または BeSweetv1.4.zip ）のなかみを全部と、 BS_ac3enc.zip を解凍して出てくる ac3enc.dll を入れます。
以上で準備完了。
BeSweetGUI を起動し、
Wizardモードを選びます。
表形式のウィザードが現れたら、変換元にしたいファイル（必ずしもWAVでなくても良い）をドラッグ・アンド・ドロップで追加するか、または、Batch Mode のチェックを外し、ナビゲート・ボタンから変換元のファイルを指定します。
ファイルが追加されたら Next で次へすすみ、変換先のフォーマットを選択します。 ここではAC3に変換するのでAC3を選びます。同様にウィザード形式で設定を選びながら、Next、Nextと進んでいきます。 ステレオのAC3の場合、ビットレートは192あたりが一般的でしょう。FRC Presets は None のままとします。
すべて設定が済むと GO のボタンが現れるので、それをクリックすればAC3へ変換されます。 さらに高度な設定を行うには、この画面で More Options をクリックします。
得られたAC3音声は、VirtualDubMod を使って、ビデオファイルと結合して、 AVI、OGM、またはMKV形式で書き出すことができます。
1. BeSweetのウィザードは、AC3からの変換でもべんりです。
2. AC3音声の再生音量は、 AC3フィルターのプロパティで調整できます。 設定画面にはコントロールパネルのアイコンからもアクセスできます。
古いバージョンの BeSweet（ffmpeg）で作成したAC3は、一部のハードウェアとの再生互換性に問題があります。 この問題は、1.5b26 以降で解決されています。 （掲示板での質問 #1729）
このメモの内容は現在調査中で不確実です。 Sonic の AC3 エンコーダはこのメモの仮説を裏切りますが、 TmpgEnc の AC3 エンコーダはこのメモの仮説と合致します。 実装は処理系依存であろうと思われます。 音ズレが発生するかどうかはハッキリせず、むしろ発生しないのでないかと考えています。
BeSweet や ffmpeg でAC3エンコードを行うとき、 変換元のファイルが44100Hzであると、見かけ上、できたAC3ファイルは変換元より少し短くなり、音ズレが起きることがあります。
現象: 44100HzのWAVをBeSweetでAC3に変換すると、変換先のAC3が変換元のWAVより約0.25%短くなります。 （掲示板での報告1961）
確認状況: 手元でも再現できました。 末尾が切れているわけでないので、AC3は音がWAVより微妙に速くなっているのではないかと思われます。 そうだとすると、できたAC3と映像を合わせた場合、音声が少しずつ先走っていき、1時間後には約9秒ものずれになります。 また、48000の場合には、問題は発生しないようです。
BeSweet をお持ちのかたで、追試してみたいかたは、次のZIPをご利用ください。
demo.zip 1.5MB
なお「48000でも問題が発生する場合」があれば知らせてください。
原因: ac3enc.dll のバグである可能性がいちばん高いです。 FAQ に「ac3enc.dll はテスト目的のもので、出力はほとんど役に立たず、重要なエンコードには使わないこと」とまで断言されているからです。
解決方法: 48000では問題が発生しないようなので、上記ツールでAC3に変換する予定がある場合、 キャプチャーなどでは極力、音声を48000にすること、44100にしてしまった場合、仕方ないからアップサンプリングで問題が回避できる可能性があります。 アップサンプリングは音質的には無駄ですが、ファイルの終わりに近づくと秒単位でずれてくるよりはずっとましなので…。
状況: 一応開発側に報告しましたが「ac3enc.dllの出力はほとんど役に立ちません」とFAQで断言されている状況なので、 優先順位の問題など考えると、取り合ってもらえるか不明。 新しい情報が入ったら、お知らせしますが、あまり期待しないでお待ちください。
BeSweetなど、ffmpeg系（ac3enc.dll）でWAV→AC3エンコードを行う場合、 サンプル周波数が44100Hzだと、できたAC3は再生速度が本来より少し速過ぎて、音ズレが起きることがあります。
原因について、 掲示板の#1975にほぼ間違いない仮説が投稿されましたので、 それを元に、簡単に中間報告します。
いろいろなビットレートについての一般論にすると分かりにくいので、 以下では、44100Hz, 2ch のWAVを、192kbpsのAC3に変換する、という具体例で説明します。
44100Hzというのは、1秒あたり44100のサンプル（標本、データ）があるデジタル化のことです。
このメモは、現在までに分かっていること・推測されることを、とりあえずまとめたもので、 間違いが含まれる可能性があります。
割り切れない数などは、適当に四捨五入してあります。 この議論による音ズレ率の理論値は 0.229% ですが、観測値には若干揺れがあることが分かっているため、 「約0.25%」「約1.0025倍」と表現してます。
変換先のAC3は基本的にはデータ的に短くなってしまうわけではなく、 再生速度が約0.25%速過ぎるのが音ズレの原因です。 本来の約1.0025倍の速度で再生され、そのため映像とだんだんずれていきます。
ただし、ごくわずかですが、データの欠落もあるようです。
44100Hz, 2ch, 16bit, 10秒のWAVは、
44100×2×10 = 882000サンプル
であり、AC3化する場合、1536サンプルずつ（約35msずつ）を「1フレーム」に区切って、圧縮処理の単位にします。
882000÷1536 = 574.22フレーム
になりますが、ffmpegではフレームの端数を切り捨てて、574フレームにします。そのため末尾がほんのわずか（最大35ms程度）削れます。
これはこれで問題ですが、ここでの問題とは関係ありませんし、末尾はたいてい無音なので実害は少ないです。
（本来は、1536の整数倍になるようにサンプル数をパディングして、575フレームに切り上げるべきでしょうけど…。）
さて、1サンプルは1/44100秒、1フレームはその1536倍、つまり
0.0348299秒
なので、192kbpsに圧縮するためには、
1秒 : 192000 bits = 0.00348299秒 : χ bits
という計算から、
1フレーム（2チャンネル分） = 6687.3469 bits = 417.959 words … ①
の割合にしなければなりません。（ word は 16 bits のこと）
理論上データの最小単位は1ビット（この場合、実際には1ワード=16ビット）で、端数はつけられませんから、 1フレームが平均417.959ワードになるように、417-word のフレームと、418-word のフレームを適当に混ぜる必要があります。 417.959は、418より少しだけ小さい数ですから、だいたい418ワードにしておいて、少しだけ417ワードのフレームを混ぜてやればいいわけです。
具体的に、49フレームを周期に、417-wordのフレーム2個と418-wordのフレーム47個を繰り返すと、
49フレームあたり 417×2 + 418×47 = 20480 words
1フレームあたり 20480/49 = 417.959 words
となり、条件①を満たします。
417と418を混在させることを微視的に見ると、 35msを単位にビットレートが微妙にVBRになり、 「191.559kbpsの部分と192.019kbps部分があって、ABRで192kbpsが実現される」という状態です。 厳密に言えば、VBRをCBRとして再生することによる音ズレがありますが、せいぜい1ms程度であり、 30fpsの映像側の1フレームは33msなので、映像との同期において、事実上、問題ありません。
フレーム数が必ずしも49の整数倍でないことによる誤差も発生しますが、これも本質的には上と同じ議論となって、無視できる量です。
ffmpeg は、全フレームを 417 words = 6672 bits に固定するため、1フレームあたり、
0.0348299秒 : 6672 bits = 1秒 : χ bits
χ = 191559.375 bits
となって、実際には 191.559kbps CBR
でエンコードされます。
結果をくだいて言うと、
デコーダはファイルから毎秒192000ビットを読んで再生装置に送りますが、
実際には191559ビットで1秒分ですから、毎秒192000ずつだと再生速度が少し速過ぎることになります。
191559 / 192000 = 0.9977
なので、単純計算で、本来の長さの99.77%の時間で再生が終了してしまい、
理論値で変換元より見かけ上 0.229% 短いAC3になってしまいます。
1時間あたりでは -8.26秒 の音ズレです。
ちなみに、417.959にしたいのだから、固定で近似するなら418で固定したほうが誤差がずっと少ないはずです。
417ワードのフレームと、418ワードのフレームを2:47の割合で混ぜる必要がある。 ffmpegはそれをせず、全フレーム417ワードにする。 結果として、ビットレートが設定値より低くなり、設定値を信じてデコードを行うと、本来の速度の約1.0025倍で再生されてしまう。
この問題にはいくつかの側面があるが、さしあたっての疑問は、Sonicの実装が「417と418を混合する、というffmpegよりは手の込んだレート合わせをしているのに、 なぜ、その混合率が無意味なのか」であった。そして、恐らく混合率については厳密な仕様はなく、Sonicの実装はおかしかったのだろう。
TMPGEnc Sound Plug-in AC-3 で再試験したところ、ズバリの結果を得た。
Trying to parse: "amg.ac3" 417 words * 1 frame(s) 418 words * 24 frame(s) 417 words * 1 frame(s) 418 words * 23 frame(s) 417 words * 1 frame(s) 418 words * 24 frame(s) 417 words * 1 frame(s) 418 words * 23 frame(s) 417 words * 1 frame(s) 418 words * 24 frame(s) 417 words * 1 frame(s) 418 words * 23 frame(s) ...
1967氏が見事最初からいきなり言い当てた「49フレーム周期で2:47」そのものだ。 この配合でこそ、417と418を混合する意味があるのであって、理論値192.000kbpsとなる。
TmpgEnc のプラグインに敬意を表すとともに、 混ぜる意味も分からず「44100のときは417と418を混ぜるのか。よしじゃあ適当に混ぜておこう」的な実装を行い、 分析者をいたずらに混乱させ悩ませた Sonic には、腹を立てるものである。
天下の TmpgEnc の実装であるから、基本的にHW再生互換性にも問題はないはずであるが、 現在調べた限りでは、DVD等の規格では48000が義務のようで、44100は使えないようだ（もちろんデコーダが要求仕様より柔軟で、 実際には正しく再生できる可能性はある）。
foobar2000などで確認すると192kbps扱いされるが、 少なくともVDMで作ったAVIコンテナでは、次のように正しいレートが書き込まれる。 1961 AC3の音ずれについてを投稿した人は、 本当に音ズレしているのか（その場合、どういうコンテナでどういうマルチプレクサでどういうデコーダか）、 それともfoobarなどで数字だけ見て短くなっていると思ったのか、知らせてください。
[strf 18]: Audio Stream Format [wFormatTag]: Audio Format: 0x2000 (FAST Multimedia AG DVM (Dolby AC3) <0x2000>) [nChannels]: Number of channels: 2 [nSamplesPerSec]: Frequency of the sample rate (Hz): 44100 [nAvgBytesPerSec]: Average data rate (byte/s): 23968 → 23968 byte/s = 191.744 kbps
コンテナによっては、実効ビットレートが正しく設定されない（再生速度がおかしい）問題があるのかもしれない。 あるいはそういう問題はまったくなくても、情報取得ツールがレートを正しく取得できない可能性もある。
[ffmpeg/BeSweet] 作成した44100HzのAC3の音ズレの仮説ですが、 実例をさらに調べると（少なくともこのAC3エンコーダでは）こうでないことが判明。 1978 Re: [ffmpeg/BeSweet] 作成した44100HzのAC3の音ズレの謎めいた状態になっています。 なぜ謎めいているかというと、当初の仮説の方が理論的に明らかに良いからです。 ハードウェアとの互換性の問題などで117と118という周期を使っているにしても、問題は、これだと平均約417.5になり ffmpeg の417固定と同じ理由で音ズレしてしまうからです。417.95くらいになってほしいのですが。釈然としません。誰か助けて…！！
とりあえず他のレートでも117と118なのかとか、上の検証（Perlでごちゃごちゃ）が合ってるかとか、まだ調べることはあるのですが。
Windows Media Encoder のアイコンが梅干しに見えて困るという報告があります。
Windows Media Encoder は、Windows Media Player 9 Series のコンポーネントで、 狭義では wmenc.exe を指し、広義では wmeditor.exe などを含む Encoder コンポーネント全体を指します。
これらのツールのアイコンのまんなかにある赤いたまが、梅干しに見えてしまうと、 WMVを使おうとするたびに思い出して、生唾がわいて困ります。
この問題は日本の食材に関連するものであり、 梅干しを知らないユーザの脳では発生しません。 問題が発生した場合、 ResHacker.exe を起動して、アイコンリソースを任意のものと置換するか、または認識する側の脳を置換してください。
画像＝リソースハッカーでアイコンを変更した例
アホなねたを書いてすいません。
略語WMEも「梅」だ。
