orange
さんがブースト
音がクリッピングするほどデカいのは、「リプレイゲインが適切でない」「デコーダが適切なリプレイゲインを適用しない」の2つがおそらく根本的な原因であって、前者についていえば仕様のデフォルト値を使っていることが悪いし、後者についてはデコーダが悪いので、いずれにせよ元データは(リプレイゲイン設定を除き)悪くないのではという気がする
訂正＞＜；
クリッピングってデータの欠損だよ！！！＞＜； 絵で24bitカラーで例えるなら、RGB各色が0xffを超えたり0x00を下回ったりしてる状態だよ？＞＜；
まちがえたよ＞＜；
orange
さんがブースト
喩えて言うならドット絵を jpeg で保存するようなもので、「見た目わからなければいいでしょ」とかそういう話ではなくて、元のドット絵という情報を劣化させるコーデックを使っていること自体が気に入らないという、そういう話
orange
さんがブースト
特に耳が良いわけでもないけど情報の欠損や汚染を拡大する処理にはうるさいオタクです
わりと意味がわからないけど、それって、謎の音がでかすぎるデータをDACに入るまでそのまま届けろっていってるのと変わらないよ？＞＜； しかも、はみ出てる（クリッピングしてる）から、元の波形とは違う波形だよ？＞＜；
orange
さんがブースト
まあデコード側で動的にサンプル見てやってダイナミックゲインかければ再生時にクリッピング阻止できるかもしれないけど、それやると曲全体として一貫した(本来想定されている)ラウドネスにならないのではという気持ちがあるので、そういうアグレッシブな最適化はデフォでしてほしくない
ていうか、サンプリングなんだから「音量なんて雑な発想でスケール決めるな＞＜＃ データ上は最大値が1.0（に対してさらにヘッドルームあけた状態）になるようにしろ＞＜＃ 」って言ってる＞＜
orange
さんがブースト
デフォのスケール(倍率)が大きいのは WAV とかのリプレイゲイン非対応プレイヤーが多いような形式と合わせるためではという気持ち(実態を知らないので適当)
今まで知識足りなくて『ゲイン値』と言うものが（ファイル全体を通して？＞＜）あるのかと勘違いしてたけど、そうじゃなく正確にはスケールファクターって言って各フレームごとに（？）あるらしい・・・＞＜
ていうかわかりやすくfloat(32bit PCM)で例えると、普通にデコードしたら「1.0超えちゃった」って時に、「まあいいか1.0で」になってる＞＜；（＝それをデコード時のクリッピングと言う かも？＞＜） のでおかしい＞＜；と言ってる＞＜
ずっとそれを言ってる＞＜；
orange
さんがブースト
そうであるとすれば、メジャーな非可逆圧縮の(一般的な想像のような現象としての)クリッピングは、フーリエ変換されたデータから時間・サンプルの PCM 的データに変換する段階で、変換先のサンプル型の範囲(たとえば int )に収まらないことが原因で発生すると考えるのが自然
mp3さん「この周波数成分がこんな感じで、こんな係数で入ってるので、そういう風にデコードしてね！！」
正直なデコーダさん「あいよ！」
1.0超えた＞＜；
という話＞＜；
orange
さんがブースト
周波数成分ごとにデータ持ってるなら尚更、修正不可能なクリッピングって発生しづらいのでは……？
内部がfloatだろうがint16だろうが関係ない＞＜； float（の場合は1.0）でもint16でも最大は最大＞＜；
orange
さんがブースト
たとえば WAV であっても内部表現は float であったりすることもできるはずで、非可逆音源であることとサンプルを表現するデータ型がスケールすることは別の話では
orange
さんがブースト
元音源が本当にクリッピングしているのであれば、小さくしたところでノイズが目立たなくなるだけでクリッピングはなくせないし、元データにもいろいろあるのだろうというテキトーな想像をしている
ちなみにオレンジがクリッピングしてる！！！＞＜っていってるのは、最終的に最大値を超えてるか検出してるんじゃなく、同一値がある程度並んでる事を検出してる＞＜（当たり前だけど＞＜；）
- ＠orange_in_space
2017年 4月に登録
