orange @[email protected]

そうなのか、 24-bit integer は IEEE 754 の 32-bit float に劣化なく入るのでそれなら普通に 32-bit float 使えばいいですね

わざわざハイレゾで海苔なのは中指立てていこうなってところですが、まぁそれ以外は買ってくれる皆さんがやっすいｲﾔﾝﾎﾎだったりするのでもうしょうがないですよねというお気持ちになってる。いや…最近の人そもそも音楽ちゃんと買ってるのか…？

サンプル単位でスケールファクタを用意したとして、結局いずれにせよ最終的にデータ全体にかかる係数は必要になるというのはまあハイという感じ (救いがない)

サンプル単位でやるか音楽データ単位でやるか程度の差ですね

まあそれが float じゃんといえばまったくその通りなんですけど

本来それこそ scale factor としてのリプレイゲインによって解決されるべき問題なんですよね…… (元の音はクリップしない範囲でとにかく大きくしておいて、本来意図された縮小スケール情報と再生側でのボリュームをそれに掛けることで最終的な音量を得る)

まあそりゃ正論なんですけど、「馬鹿デカい音で録音するな」が通るならそもそも float そんなに必要なさそう (よほどのダイナミックレンジが欲しい音楽を除けば)

https://mastodon.cardina1.red/@lo48576/101880401145237418
山の方が精度欲しい理由、「傾斜の激しいゼロ付近のサンプル点は、山の頂点付近に比べて数が少ないから」と表現するべきかもしれない

まあこれたぶん深く考えていくと最初からフーリエ変換して周波数成分だけ持っとけという話になって、最終的に mp3 (without 高周波カット) はいいぞ的な話になりそうなんですが

小さい部分が表現しやすいのはたしかに良い性質なんですが、大きな音を表現するとき、雑で良い部分の精度が高くなって、綺麗に表現されてほしい部分 (山の頂点付近) で精度が低くなるというのは、なにか別の小数点数表現が必要とされているような気がしないでもないですね (気にしすぎかもしれない)

基本的に IEEE 754 とかの浮動小数点数では、小さな数ほど精度が良くて、大きな数ほど精度が悪いという性質があるわけですが、音楽において音波のピーク部分の山の頂点と圧力ゼロ部分の激しい傾斜、どちらに精度が欲しいかというと当然山の頂点の方 (なぜならそちらに誤差があるとノイズとして高周波成分が生えてくるから) なので、 float が持つ精度の減りかたと欲しい精度の乗り方が逆なんですよね