アカウント名:
パスワード:
AACの256kbpsって20kHz以上は全てカットだったと思うけどその辺の仕様は変更したのかな？
>>AACの256kbpsって20kHz以上は全てカットだったと思うけど
新しいエンコーダは20kHz以上も通すようにした／デコーダはサンプリング周波数を示すタグを書き換えたデータを受け付けて20kHz以上も再生出来るように最初からちゃんと作ってある～という可能性がある非可逆圧縮の場合、デコーダのアルゴリズムは同じなのにエンコーダの改良で音質が向上するという不思議（？）なことが起こる（だからデコーダのアルゴリズムは公開されているが、エンコーダが非公開になっている場合がある）
H.264みたいに圧縮ストリームがビット単位で参照実装と一致しないと適合とはみなされない仕様でもそういう最適化の余地あるの?
H.264みたいに圧縮ストリームがビット単位で参照実装と一致しないと適合とはみなされない
それはデコーダ側の問題ですね。だから、基本的には「同じ圧縮データをデコーダに入力した」場合は、「デコーダを替えても伸張結果は変わらない」ことになります。
でも、圧縮側では、たとえ可逆圧縮でも、伸張結果が同じになる圧縮符号がただ一通りとは限りません。効率よく圧縮されたデータもあれば、効率の悪いデータもありえる。例えば、GIF画像なんかで、LZW特許問題が出たころには、「LZWデコーダで伸張できる非圧縮データ」とか「LZWデコーダで伸張できるランレングス圧縮データ」を使ったGIF画像が結構出回ってました。これらなんかは、どれも伸張すればまったく同じデータですが、圧縮サイズは全然異なっているわけです。
H.264などのような動画圧縮の場合、可逆圧縮である「動き予測」という時間方向差分抽出の処理が非常に重く、またこの部分の出来不出来によって、圧縮後のサイズは大きく変わります。
さらに、ビットレート固定で考えた場合、可逆圧縮な部分での圧縮効率に違いが出ると、その後の非可逆圧縮部分に影響が出ます。可逆圧縮部での圧縮効率が良い場合、非可逆圧縮部であまり情報を捨てなくても所定のビットレートにできますから、結果として再現率が高い、高画質な映像になります。一方、可逆圧縮部での圧縮効率が悪い場合、非可逆圧縮部でたくさん情報を捨てないと所定のビットレートにできませんから、結果として再現率が低い、低画質な映像になります。そういった「エンコーダによる画質の違い」が出てきます。
そのうえ、非可逆圧縮では、圧縮側には「どの情報を捨てるか」の選択の余地があるわけです。MP3やAACなんかは「心理学的に人間の耳には認識されにくい部分の情報を捨てる」ことで非可逆圧縮してますから、その部分のチューニングとして、エンコーダによっては最適化というよりも「味付け」「方向性」の違いが出てきます。
以上のような点から、「エンコーダを替えたら、伸張結果が出力が変わる」とか「エンコーダを改良したら高画質/高音質になる」とかいうのはごく当たり前の話になります。
ちなみに、H264でデコーダ側でビット単位での正確さを求める理由ですが、それは動き予測/動き補償の処理に原因があります。動画圧縮でのエンコーダ側の「動き予測」に対応するのが、デコーダ側の「動き補償」によるデータ伸張処理なわけですが、動き補償では、不可逆圧縮されたデータの伸張結果を元に、「時間方向差分からの元画像の再現」を行います。そして、その出力である画像は、また別時刻の画像を伸張する動き補償処理の入力として使われることになりますので、不可逆圧縮の伸張結果が正確さに欠けるデコーダ実装では、その誤差がどんどん蓄積されていってしまいます。そのため、「デコーダによっても不可逆圧縮なデータの展開結果が変わらない」ことを保証できているということが非常に重要なのです。
要は「H.264でビット単位で参照実装と一致を求められるのはデコーダの実装(#2108893で言うところのデコーダのアルゴリズムは同じ)であって、エンコーダは改良や味付けの余地がある」ってことですよね。
ただまぁ世の中でデコーダ扱いされてる物の中には参照実装に一致するデコーダの後段でエフェクト掛ける奴もあるわけで。エンコーダもその実装の一部(フィードバックに使うデコーダ)は参照実装との一致が求められてるんですよね。それをエンコーダも参照実装との一致が求められてると呼んでいいのかは疑問ですが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
AACの仕様 (スコア:0)
AACの256kbpsって20kHz以上は全てカットだったと思うけど
その辺の仕様は変更したのかな？
Re: (スコア:0)
>>AACの256kbpsって20kHz以上は全てカットだったと思うけど
新しいエンコーダは20kHz以上も通すようにした／デコーダはサンプリング周波数を示すタグを書き換えたデータを受け付けて20kHz以上も再生出来るように最初からちゃんと作ってある～という可能性がある
非可逆圧縮の場合、デコーダのアルゴリズムは同じなのにエンコーダの改良で音質が向上するという不思議（？）なことが起こる
（だからデコーダのアルゴリズムは公開されているが、エンコーダが非公開になっている場合がある）
Re: (スコア:0)
H.264みたいに圧縮ストリームがビット単位で参照実装と一致しないと適合とはみなされない仕様でもそういう最適化の余地あるの?
Re:AACの仕様 (スコア:2)
それはデコーダ側の問題ですね。
だから、基本的には「同じ圧縮データをデコーダに入力した」場合は、「デコーダを替えても伸張結果は変わらない」ことになります。
でも、圧縮側では、たとえ可逆圧縮でも、伸張結果が同じになる圧縮符号がただ一通りとは限りません。効率よく圧縮されたデータもあれば、効率の悪いデータもありえる。
例えば、GIF画像なんかで、LZW特許問題が出たころには、「LZWデコーダで伸張できる非圧縮データ」とか「LZWデコーダで伸張できるランレングス圧縮データ」を使ったGIF画像が結構出回ってました。これらなんかは、どれも伸張すればまったく同じデータですが、圧縮サイズは全然異なっているわけです。
H.264などのような動画圧縮の場合、可逆圧縮である「動き予測」という時間方向差分抽出の処理が非常に重く、またこの部分の出来不出来によって、圧縮後のサイズは大きく変わります。
さらに、ビットレート固定で考えた場合、可逆圧縮な部分での圧縮効率に違いが出ると、その後の非可逆圧縮部分に影響が出ます。
可逆圧縮部での圧縮効率が良い場合、非可逆圧縮部であまり情報を捨てなくても所定のビットレートにできますから、結果として再現率が高い、高画質な映像になります。一方、
可逆圧縮部での圧縮効率が悪い場合、非可逆圧縮部でたくさん情報を捨てないと所定のビットレートにできませんから、結果として再現率が低い、低画質な映像になります。
そういった「エンコーダによる画質の違い」が出てきます。
そのうえ、非可逆圧縮では、圧縮側には「どの情報を捨てるか」の選択の余地があるわけです。MP3やAACなんかは「心理学的に人間の耳には認識されにくい部分の情報を捨てる」ことで非可逆圧縮してますから、その部分のチューニングとして、エンコーダによっては最適化というよりも「味付け」「方向性」の違いが出てきます。
以上のような点から、「エンコーダを替えたら、伸張結果が出力が変わる」とか「エンコーダを改良したら高画質/高音質になる」とかいうのはごく当たり前の話になります。
ちなみに、H264でデコーダ側でビット単位での正確さを求める理由ですが、
それは動き予測/動き補償の処理に原因があります。
動画圧縮でのエンコーダ側の「動き予測」に対応するのが、デコーダ側の「動き補償」によるデータ伸張処理なわけですが、動き補償では、不可逆圧縮されたデータの伸張結果を元に、「時間方向差分からの元画像の再現」を行います。
そして、その出力である画像は、また別時刻の画像を伸張する動き補償処理の入力として使われることになりますので、
不可逆圧縮の伸張結果が正確さに欠けるデコーダ実装では、その誤差がどんどん蓄積されていってしまいます。
そのため、「デコーダによっても不可逆圧縮なデータの展開結果が変わらない」ことを保証できているということが非常に重要なのです。
Re: (スコア:0)
要は「H.264でビット単位で参照実装と一致を求められるのはデコーダの実装(#2108893で言うところのデコーダのアルゴリズムは同じ)であって、エンコーダは改良や味付けの余地がある」ってことですよね。
ただまぁ世の中でデコーダ扱いされてる物の中には参照実装に一致するデコーダの後段でエフェクト掛ける奴もあるわけで。
エンコーダもその実装の一部(フィードバックに使うデコーダ)は参照実装との一致が求められてるんですよね。
それをエンコーダも参照実装との一致が求められてると呼んでいいのかは疑問ですが。