新しいものを表示

わりと意味がわからないけど、それって、謎の音がでかすぎるデータをDACに入るまでそのまま届けろっていってるのと変わらないよ?><; しかも、はみ出てる(クリッピングしてる)から、元の波形とは違う波形だよ?><;

orange さんがブースト

まあデコード側で動的にサンプル見てやってダイナミックゲインかければ再生時にクリッピング阻止できるかもしれないけど、それやると曲全体として一貫した(本来想定されている)ラウドネスにならないのではという気持ちがあるので、そういうアグレッシブな最適化はデフォでしてほしくない

ていうか、サンプリングなんだから「音量なんて雑な発想でスケール決めるな><# データ上は最大値が1.0(に対してさらにヘッドルームあけた状態)になるようにしろ><# 」って言ってる><

orange さんがブースト

デフォのスケール(倍率)が大きいのは WAV とかのリプレイゲイン非対応プレイヤーが多いような形式と合わせるためではという気持ち(実態を知らないので適当)

今まで知識足りなくて『ゲイン値』と言うものが(ファイル全体を通して?><)あるのかと勘違いしてたけど、そうじゃなく正確にはスケールファクターって言って各フレームごとに(?)あるらしい・・・><

ていうかわかりやすくfloat(32bit PCM)で例えると、普通にデコードしたら「1.0超えちゃった」って時に、「まあいいか1.0で」になってる><;(=それをデコード時のクリッピングと言う かも?><) のでおかしい><;と言ってる><

orange さんがブースト

そうであるとすれば、メジャーな非可逆圧縮の(一般的な想像のような現象としての)クリッピングは、フーリエ変換されたデータから時間・サンプルの PCM 的データに変換する段階で、変換先のサンプル型の範囲(たとえば int )に収まらないことが原因で発生すると考えるのが自然

スレッドを表示
orange さんがブースト

修正不可能な形で発生するにしても周波数ごとのクリッピングだろうし、つまり「特定の音域が本来よりも多きくならない」というような形で現れるのでは

スレッドを表示

mp3さん「この周波数成分がこんな感じで、こんな係数で入ってるので、そういう風にデコードしてね!!」
正直なデコーダさん「あいよ!」
1.0超えた><;

という話><;

orange さんがブースト

周波数成分ごとにデータ持ってるなら尚更、修正不可能なクリッピングって発生しづらいのでは……?

内部がfloatだろうがint16だろうが関係ない><; float(の場合は1.0)でもint16でも最大は最大><;

orange さんがブースト

たとえば WAV であっても内部表現は float であったりすることもできるはずで、非可逆音源であることとサンプルを表現するデータ型がスケールすることは別の話では

orange さんがブースト

元音源が本当にクリッピングしているのであれば、小さくしたところでノイズが目立たなくなるだけでクリッピングはなくせないし、元データにもいろいろあるのだろうというテキトーな想像をしている

スレッドを表示

ちなみにオレンジがクリッピングしてる!!!><っていってるのは、最終的に最大値を超えてるか検出してるんじゃなく、同一値がある程度並んでる事を検出してる><(当たり前だけど><;)

非可逆音源ってPCMそのまんまじゃなくDCT?><してるデータじゃん・・・?><

orange さんがブースト

有限精度のデータであればどんな原理であれクリッピングは発生しうるわけですが、たぶんそこまでクッッッッソ巨大なサンプルは普通入ってこないということでは(しかも浮動小数点数とかであれば尚更)

mp3gain(ソフトウェア)で適切な値にゲイン書き換え(してるような操作を)すれば、mp3の各フレームのスケール値を書き換えてくれるので、普通のデコーダでもクリッピングしない><(のでいちいちそうしてるのでめんどくさいから自前でどうにかしたくて調べてた><)

orange さんがブースト

ていうか、非可逆圧縮音源って、仕組みからの推測だけど、理屈の上ではフルスケールを超えたサンプルが発生しちゃうじゃん?><
それってつまり、そのままデコードすると最大値を超える=クリッピングしちゃうじゃん?><
そうなった後のデータの音量下げても(音は小さくなるけど)意味無いじゃん?><

古いものを表示
:realtek:

思考の /dev/null