ずっとそれを言ってる＞＜；
orange
さんがブースト
そうであるとすれば、メジャーな非可逆圧縮の(一般的な想像のような現象としての)クリッピングは、フーリエ変換されたデータから時間・サンプルの PCM 的データに変換する段階で、変換先のサンプル型の範囲(たとえば int )に収まらないことが原因で発生すると考えるのが自然
mp3さん「この周波数成分がこんな感じで、こんな係数で入ってるので、そういう風にデコードしてね！！」
正直なデコーダさん「あいよ！」
1.0超えた＞＜；
という話＞＜；
orange
さんがブースト
周波数成分ごとにデータ持ってるなら尚更、修正不可能なクリッピングって発生しづらいのでは……？
内部がfloatだろうがint16だろうが関係ない＞＜； float（の場合は1.0）でもint16でも最大は最大＞＜；
orange
さんがブースト
たとえば WAV であっても内部表現は float であったりすることもできるはずで、非可逆音源であることとサンプルを表現するデータ型がスケールすることは別の話では
orange
さんがブースト
元音源が本当にクリッピングしているのであれば、小さくしたところでノイズが目立たなくなるだけでクリッピングはなくせないし、元データにもいろいろあるのだろうというテキトーな想像をしている
ちなみにオレンジがクリッピングしてる！！！＞＜っていってるのは、最終的に最大値を超えてるか検出してるんじゃなく、同一値がある程度並んでる事を検出してる＞＜（当たり前だけど＞＜；）
非可逆音源ってPCMそのまんまじゃなくDCT？＞＜してるデータじゃん・・・？＞＜
orange
さんがブースト
有限精度のデータであればどんな原理であれクリッピングは発生しうるわけですが、たぶんそこまでｸｯｯｯｯｿ巨大なサンプルは普通入ってこないということでは(しかも浮動小数点数とかであれば尚更)
mp3gain（ソフトウェア）で適切な値にゲイン書き換え（してるような操作を）すれば、mp3の各フレームのスケール値を書き換えてくれるので、普通のデコーダでもクリッピングしない＞＜（のでいちいちそうしてるのでめんどくさいから自前でどうにかしたくて調べてた＞＜）
orange
さんがブースト
ていうか、非可逆圧縮音源って、仕組みからの推測だけど、理屈の上ではフルスケールを超えたサンプルが発生しちゃうじゃん？＞＜
それってつまり、そのままデコードすると最大値を超える＝クリッピングしちゃうじゃん？＞＜
そうなった後のデータの音量下げても（音は小さくなるけど）意味無いじゃん？＞＜
orange
さんがブースト
たとえば float64 のデータを int32 にデコードするとかだと、元データはクリッピングしてなくてもデコード後にクリッピングするし、リプレイゲイン適用によってクリッピングを防ぐこともできるはず
orange
さんがブースト
replay gain 適用するとクリッピングしなくなったデータ知ってるし、やっぱりあれデコード先の型とかの問題なんですかね
△これになってた
○この問題が発生する
＞＜；
少なくともNAudioで作ってるアプリをreplaygainに対応した言って相談してた人への返答はこれになってた＞＜
「replaygainとかいうのあるらしいけどさ＞＜ デコード時にクリッピングしてるデータをデコードした後から音量下げても何の意味も無いじゃん？＞＜ どういう事？＞＜」
「replaygainとかいうのあるらしいけどさ＞＜ デコード時にクリッピングしてるデータをデコードした後から音量下げても何の意味も無いじゃん？＞＜ どういう事？＞＜」って思ったんだけど、foobar2000はそうじゃ無いっぽい・・・？＞＜（ていうかデコーダのつくりが特殊？＞＜）
（Windows標準のACMデコーダ（DirectShow経由でも）とかWinampの標準デコーダでは普通に（？）クリッピングする＞＜）
mp3ってそのままでコードするとクリッピングするデータが作れてしまうの規格上おかしくないの？＞＜って話を何度か書いてて
（ https://mstdn.nere9.help/@orange_in_space/99660379898354133
）、先ほど気づいたんだけど、foobar2000でデコードするとクリッピングしない・・・＞＜（なぜ？＞＜；）
- ＠orange_in_space
2017年 4月に登録
