私は最近、iTunesのチャート上のトップ百ポッドキャストのMP3エンコード設定についての長い記事を書きました。 私の提案の1つは非常に物議を醸していました：Redditの人々はpodcastでVBRエンコーディングを使用しても大丈夫かどうかについて意見が一致しませんでした。
私はVBRが悪いと主張する人々の激しさに驚きました。 「使われるべきじゃない！””VBRから離れて滞在。”VBRを避けることを提案する人々の不足はありませんでしたが、それらの主張の背後にある物質の方法はほとんどありませんでした。
私は見つけることができるVBRに対するすべての議論を収集するために着手し、それぞれの背後にある主張を検証することが可能かどうかを判断
最初に、しかし、いくつかの背景。
あなたのクリックを保存するには、私はいくつかの簡単な背景を与えるでしょう。 MP3では、ビットレートを持っています。 ビットレートは、オーディオの一秒を格納するのにかかるビット数です。 128kbpsのMP3ファイルは、オーディオの一秒を保存するために128キロビットを取ります。 10秒の長さの128kbps MP3ファイルがある場合、ファイルを保存するには1280キロビットかかります。 シンプルだ
CBR、つまり定数ビットレートがどのように機能するかです。 ファイル全体には1ビットレートがあります。 これの欠点は、すべてのオーディオが同じように作成されるわけではないということです。 一部のオーディオは、保存するために少ないビットを必要とします（例えば、沈黙の瞬間）。 一部のオーディオは、より多くを必要とします。 一つのビットレートを持つことは、潜在的にあなたが必要としないオーディオの忠実度を格納するビットを無駄にしていることを意味します。 ここで、VBRまたは可変ビットレートが登場します。
VBRは、ファイルのチャンクを異なるビットレートでエンコードすることができます。 音楽の第二は160kbpsにジャンプするかもしれないが、ほぼ沈黙の第二は、40kbpsに押しつぶすかもしれません。 正しくされて、これは非常に相当な節約をもたらすことができる。
VBRに対する引数は何ですか？
ブッシュの周りを打つのではなく、飛び込んでVBRに対する議論を見て、それぞれの妥当性をテストしましょう。
これは本当であり、私は特に私の投稿でこれを呼び出します:
CBRファイルを使用すると、ジャンプ先を正確に計算できるため、前方または後方をスキップするのは簡単です。 VBRでは、10秒先にスキップすると、最大1280キロビットまでスキップすることになりますが、その10秒以内に品質が低下すると、それはあまりにも多くな
基本的に、単純な乗算ではなく、そのタイムコードに至るすべてのオーディオのビットレートを知る必要があるため、特定のタイムコードで再生を開始す
これを回避する方法があります。 長い、ずっと前に、人々はデコーダがどこにシークするかを把握することができ、メタデータがMP3に埋め込まれることを可能にする標準の数を作成しました。 私はこれについてもっと書くことができますが、事実上誰も標準を実装していないので、それは議論の余地があります。
タイムコードがオフになる量は、ファイル内でさらに進むにつれて増加することは注目に値します。 オーディオファイルの開始時に、品質がまったく非常に低下したことはほとんどありませんし、その差はわずか数ミリ秒である可能性があります。 しかし、数分後、それは数秒に成長します。 時間とアップした後、それは分以上に成長得ることができます。
いくつかのポッドキャストは非常に短いです。 一般的に15分未満のエピソードを持っているメモリ宮殿を、考えてみましょう。 私はVBRエンコードされたT.M.P.エピソードでシークがファイルの終わりまでに数秒以上オフになっていたことを聞いて驚く以上のものになるでしょう。 （私はこれを測定しますが、生のソースオーディオにアクセスせずに正しく行うことは不可能です）
他のポッドキャストは、実際には堅牢なシーク機能を必 ASMR podcast、ほとんどダイアログがない、またはまったくダイアログがないpodcast、およびホストとしての愚かなjabberを持つpodcastは、ビデオゲームをプレイするために、特定のタイムコードを正確に求める能力を必要としません。 これは、ポッドキャストの非ゼロ数が作るために喜んでいるトレードオフです。
相対シークもVBRエンコーディングの影響をほとんど受けません。 ポッドキャスト私の弟私の弟と私はVBRエンコーディングを使用しており、それは非常に良い精度で三十秒で先にスキップし、十秒で戻ってすること これには技術的には正当な理由があります: ただ、ファイルの先頭から求めているように、それはあなたが先にスキップしている時間の小さな塊の間に非常に多くの品質が低下することはほと 30秒先にスキップすることは、実際には31秒先にスキップすることを意味するかもしれません。 不正確さの量は、あなたが相対的なシークでは、通常は非常に小さい過去をスキップしているオーディオの量によって決定されます。
VBRは実際にはファイルを小さくしません。
これは半分真実です。 VBRファイルの平均ビットレートがCBRファイルの固定ビットレートと同じ場合、VBRはCBRとほぼ同じサイズのファイルを生成します。 VBRはまた、ビットレートを変更しない場合（つまり、エンコーダーがランダムノイズなどの品質を下げることを選択しない場合）、CBRファイルと同じサイズのファ
ファイルにランダムノイズのみが含まれている場合を除いて（なぜあなたはあなたのポッドキャストでそれを公開していますか？）サイズの違いは、VBRファイルがCBRファイルよりも全体的に等しいかそれ以上のオーディオ品質を持つことになるという明白な警告を持っています。
: あなたは十秒のファイルを持っています。 前半はほぼ沈黙で、後半は高忠実度の音楽です。 これを128kbpsでCBRとしてエンコードすると、1280kbになります。 それをVBRとしてエンコードし、エンコーダが前半を64kbps、後半を192kbpsで仮符号化すると、ファイルサイズはまだ1280kbになり、平均ビットレートはまだ128kbpsにな 品質を比較すると、しかし、我々は沈黙は、それが必要とするビットのみを使用しており、より多くのビットが音楽に専念していたので、VBRファイルは、はるか
エンコーダーの設定を調整することにより、VBRエンコードされたファイルの平均ビットレートを効果的に下げ、品質が同等のCBRエンコードされたファイルとほぼ一致するようにすることができます。 理論的には、これはファイルサイズの全体的な削減につながります。 ただし、何をしているのかを知らずにVBR設定を選択すると、VBRを使用して得られるファイルサイズの利点を簡単に無効にすることができます。
VBRファイルに正しい期間が表示されません。
デフォルトでは、いいえ、VBRファイルの期間はバイト長で計算され、過大評価されます（シークが機能しないのと同じ理由で）。 ただし、TLENフレームを使用してID3タグにオーディオの持続時間を指定するだけで、持続時間が修正されます。 一部のデコーダはTLENフレームを正しく読まないが、それらはほとんどなく、遠く離れており、誰かがポッドキャストを消費する可能性のあるアプリやデバ
Adobe Auditionのようなエンコーダは、壊れたVBRエンコードされたファイルを生成します。
これは私がオンラインでいくつかの場所で言及しているのを見つけたもので、Adobeのフォーラムの投稿に戻っています。 詳細を読まずに、この問題の周りにFUDのクラウドを作成するのは簡単です。 これはdurationに関する最後の主張に直接関係していることが判明しました：Auditionは単にTLENデータを追加していませんでした（容疑者）。
更新：Adobe Auditionでこの問題を再現できなかったことに注意したいと思います。 以前のバージョンに問題が存在していた可能性がありますが、それはもはやそうではないようです。 このセクションを更新して、Adobe Auditionに問題があるとは思わないことをより明示的に述べました。adobe Auditionに問題があるとは思わないことを確認しました。 手を差し伸べるためのTwitter上の@audiblychuckに感謝します。
私はこれがポッドキャスターの責任であり、リスナーの問題ではないという議論をしたいと思います。 これは、ID3タグを追加するのは簡単だし、オーディションは、このレースで唯一の馬ではありません。 舞台裏では、AuditionはFraunhofer MP3エンコーダを使用しています。 Adobeのフォーラムの投稿は、2012年にリリースされたAudition CS6についても言及しています。
Adobeがこれを修正しなかったとしても、インターネット上の多数の投稿はツール（Mp3Val、Mp3Diagなど）を推奨しています。）それはこの問題を検出し、修正します。 FfmpegとLAMEの両方が正しく他のほとんどのオーディオ編集ソフトウェアは、デフォルトで正常に動作することを意味し、適切なID3タグを追加します。
ほとんどすべての現代のMP3デコーダは、VBR MP3ファイルの正しい持続時間を決定するためにTLENID3タグを必要としません。
VBRは、特定のデバイスでは動作しません。
これを裏付ける逸話的な証拠がある。 デバイスのサポートに関するHackerNewsコメントスレッドを見つけました。 ここでは、十年以上前からの経験について話して、議論のルートコメントです:
結局のところ、誰もが現代のデバイスを使って聞いているわけではありません。 私たちはVBRをしようとしたとき、彼らのMP3再生ハードウェア/選択のソフトウェアが適切にVBRファイルをサポートしていなかったので、人々のかなりの数 彼らはこれが問題であることを認識していませんでした。 彼らはちょうどそれが皆のために正常に動作していた間、ファイルが破損していたことを訴えました。
あるコメンターがEigerMan F20に問題を抱えていました:
これについての私のお気に入りのバグは、VBR Mp3Sをサポートしていた_ancient_MP3プレーヤー（EigerMan F20）にありました…不完全に。 それは特定のビットレートで領域をデコードすることをサポートしていなかったので、それは黙ってそれらをスキップし、私の部分で極端な混乱につ
別のコメンターが彼のNomad Jukebox3でより良い運を持っていました:
私は私のNomad Jukebox3がVbrをサポートしていることをかなり確信しています。
hydrogenaudioのユーザーは、DVDプレーヤーで不運でした2006:
私のDVDプレーヤー（Samsung HD-860）はmp3vbrファイルを再生しません。 それは約2歳であり、HDMI出力が付属しています。
同じスレッドの別のコメンターが彼の車にトラブルを抱えていました:
私の友人は新しい2008Pontiac G5を購入しました（これは基本的にGrand Amですが、彼らは以来G5に名前を変更しました）、それは工場出荷時にインストールされたmp3-CD ユニットはVBRファイルを正常に再生しますが、mp3内のすべてのフレームは128kbps以上でエンコードする必要があることを発見しました。
私は十年以上前から車やMP3プレーヤーについての記事をコピーして貼り付けることはありません。 人々が言及しているデバイスのほとんどは、2017年からの完全なポッドキャストエピソードを保持することさえできません！
私のウェブの残りの部分での研究は同様の結果をもたらしました。 私はVBRファイルを再生するために失敗した最後の十年で作られたデバイスの単一のレポートを見つけることができませんでしたが、これは私を驚か ウィキペディア上の未承認の主張は述べています:
2006年現在、CBRエンコードされたファイルのみをサポートするデバイスは、現代のポータブル音楽デバイスとソフトウェアの大部分がVBRエンコードされたファそれとは逆の証拠がなければ、デバイスの互換性がVBRに対する有効な議論であるとは思わない。
デバイスでVBRの互換性の問題が発生した場合は、それについて聞いてみたいと思います。 手を差し伸べてください！
FirefoxはVBRをサポートしていません。
これはもはや真実ではありません。 FirefoxはVBRファイルをサポートしています。 私はmacOSとWindows10の両方で自分自身をテストしました。 Firefoxは、独自のMP3デコーダをバンドルするのではなく、ホストプラットフォームのオーディオデコーダを使用してMP3を再生します。 Windowsでは、上記で説明したタイムコードの問題のために、ファイルがミッドストリームの再生を停止したとされています。 これはもはやまったくそうではないようです。 ファイルは、切り捨てやシークの問題なしで、うまく再生されました。
専門家はVBRを使用しないと言います。
私はvbrを避けるためになぜ彼らのアドバイスのためにポッドキャスト当局や他の業界の専門家に紹介されました。 私はこれらの人々が出した議論に興味がありました。
更新：執筆時点で、私の分析のコードのバグは、VBRを使用しているとして、iTunesのトップ100ポッドキャストで15ポッドキャストを誤って識別しました。 実際には、唯一のVBRエンコーディングを使用しています。 この番号は、ロブ-ウォルチとの私の通信で引用されました。
私が最初に連絡を取るように言われたのは、Libsynのpodcaster relationsの現在のVPであるRob Walchです。 私は彼に電子メールを送り、彼はblogのポストへのリンクと答えた。 ここにその投稿の抜粋があります:
VBRは、MP3音楽ファイルを小さくするために作成された古い技術/ハックであり、ファイル共有の全盛期に人気がありました。 今日はそれのための必要はありません—利用可能な帯域幅とストレージは、今日は15と20年前とは大きく異なっています。 しかし、MP3のためのより重要なのは、ISO規格は、プレイヤーがそれをサポートする必要はありません。
規格(ISO/IEC11172-3:1993)によると、Section2.4.2.3
“可能な限り最小の遅延と複雑さを提供するために、デコーダは、レイヤIまたはIIのときに連続可変ビットレートをサポー ただし、フリーフォーマットでは、固定ビットレートが必要です。”
と
“レイヤIIでは、合計ビットレートとモードのすべての組み合わせが許可されているわけではありません。”
したがって、ほとんどのレイヤIIコーダーはVBRを念頭に置いて書かれていなかったでしょうし、レイヤII VBRはハックです。 それは限られた場合のために働きます。 それはMP3スタイルのVBRと同じ程度に動作するように取得することは、主要なハックになります。
要するに、光と大量使用の中でVBRの日は、1990年代後半とプレポッドキャスティングに戻って私たちの後ろの方法です。
これらの引数はすべて、上で説明したものと同じですが、いくつかの例外があります。 一つには、Robは帯域幅とストレージが安価であると主張しています。 これは事実ですが、ポッドキャストリッスンも近年爆発しています（2014年の彼のポスト以来でさえ）。 国際的には、特に新興市場では、帯域幅は、米国外のリスニングを増加させるための障壁となることができ、リスナーのために高価です。
彼はまた、MPEG ISO仕様を引用していますが、彼が抽出した引用は誤解されています。 MP3は”MPEG-2Audio Layer3″の略で、”Layer IIIはビットレートインデックスを切り替えて可変ビットレートをサポートしています”という引用は、MP3が可変ビットレートをサポートしていることを意味します。「私の理解では、MP3互換であり、VBR（仕様ごと）をサポートしていないことはできません。 “レイヤー2″についての第二の引用は、MP3とは完全に異なるコーデックであり、議論には無関係であるMPEG-2オーディオレイヤー2を指します。
私はこれらのコメントに答え、彼がこれらの主張を実証するのに役立つデータを持っているかどうかを尋ねました。 私が得た応答は少し…塩辛いでした。
Matt,
正直なところ—記事のタイトルはそれをすべて言った—VBRの最初と最後の単語。
VBRは死んでいる—それを押している人は風車と戦っているだけです。
CBR=良い
VBR=悪い
それは本当に簡単です—これ以上を作ろうとしないでください—VBRはプレイヤーと標準によって完全にサポートされていません。
あなたはVBRのためにプッシュしようとしている場合—その後、最終的には、この電子メールを振り返り、あなただけの私に耳を傾けたいと思います。 🙂
そして、すぐに続いて
こんにちはマット、
あなたがVBRを使用することを考えていたか、VBRを使用していて、私の記事を読んだ後、あなたは変更することこんにちは確信していません—あなたは本当に本当にこれを読む必要があります:
http://theoatmeal.com/comics/believe
彼の返事には苦い皮肉がありますが、Matthew Inmanのfine stripを読んで、backfire効果について見つけてみましょう。 私は詳細を提供するために再び彼を押して、別の肌寒い応答を受けました:
あなたの探求に幸運。
私はVBRを死んだ問題と考え、それが上がったときに目を転がします。 これが私が作った投稿の理由です。
数年ごとに醜い頭を上げているようです。
あなたが見た15％がわからない—私はトップをチェックした最後の時間は、それがあったことを示しています0%
http://podcast411.libsyn.com/will-increasing-your-bit-rate-equal-more-listeners
この記事を参照してください。この時点で
—それはVBR上の私の最後の返信です。
これに時間を無駄にするにはあまりにも多くの—私が作った投稿は、あなたが客観的にそれを見れば、あなたが必要とするすべての情報を提供します。
私は本当にあなたがCBRに移動することをお勧めしますし、あなたは何の問題もありません。
リンクされた投稿は、ロブのマントラを繰り返すだけです。「彼が主張している主張を裏付ける客観的な事実を指摘することなく、この問題に関するロブの意見は多くの水を保持しているとは言えません。