><https://twitter.com/orange_in_spacehttps://pawoo.net/@orange_in_space
32-bit int を劣化なく表現するには仮数部 23-bit の float じゃ足りないし、 CPU での計算なら double の方が効率良いだろうし
なんで倍精度じゃないの?って意味だとしたら、たぶん速度の問題かも><
ところでソフトウェアの内部処理が 32-bit float ってどうなんです?なんか違和感あるんですが
オレンジ的にはfloatなら音でかすぎてもちゃんと表現できるから、目くじら立てなくても良いや><みたいな考え方><(なので、音圧競争を憎みつつ、WindowsのWASAPIのミキサ悪玉論にも「おかしい><# 」って言ってる>< )
ffmpegでvorbisとかaacは内部で浮動小数点数で扱われていたと思うんだけど、mp3がコーデックとしては浮動小数点数による波形を取り扱えるべきなのにデフォルトだと内部出力として整数に丸められてしまうのは互換性の問題なんすかね
https://twitter.com/OBSOLETE_STD/status/740864209538273283mp3floatに言及している画像付きツイートあった
ハイレゾと称して48kHz, 24bitで配信されているとある音声ファイルを384kHzでオーバーサンプリングした様子。ハイレゾ = 音割れが無いではない
“インターサンプルピーク:Inter Sample Peakとは | 偏ったDTM用語辞典 - DTM / MIDI 用語の意味・解説 | g200kg Music & Software” <https://www.g200kg.com/jp/docs/dic/intersamplepeak.html>
✗ 非可逆圧縮に飛びつく○ 可逆圧縮に飛びつく
浮動小数点数を基にしている音声コーデックで大半のソースで1.0–-1.0に収まっていないのをみて絶望して、非可逆圧縮に飛びつくのは賢い選択ではない。True Peakという言葉で調べてほしいんだけど、デジタルデータから連続データに直す時、サンプル間の差を補間したらそのサンプルを超える事があり、そのサンプルが整数最大値であった時は音割れとして表れてしまうわけだな。それを再現してみるには、ソースのサンプリング周波数を4倍したものでリサンプリングを掛けてみるといい
でも、W7、設計最高速度が275km/hなのが設計変更がさらに増えそうな点は厳しそう><;
普通に考えたらお下がりを編成組み替えて使うんだろうけど、もし新造で、まさかのW7ベースになったら、東海へのあてつけっぽくておもしろそう><><
><b(?)
ああいや、KbMPも使うけど最近のメインはiTunes/iOSです…KbMPではちゃんと再生できた
あれ?>< KbMedia Playerもどうにかすると正しくデコードできた気が>< ていうかオレンジの環境では出来るけど・・・><
KbMP使いです
あと、割れてる「気がする」じゃなく実際におかしいかどうかは、デジタルなクリッピングであればオレンジの解析アプリ使えば検出できる><自分で作る場合は、NAudioかなんかでWASAPIループバックさせて、同じ値がある程度以上大きい音で4サンプルくらい並んでる場面があるか探せばおk><
fb2kで聞くといいと思うよ!><
ところどころ音割れしてるように感じていた音声作品、mp3のまま聴いていたことを思いだして確認したらピーク超えてて:sokka:になっています。
混乱><
思考の /dev/null