orange @[email protected]

アプリを1ミクロンも褒めてないのはマズいような気がしなくも無い＞＜；（そもそもチェックしかしてない＞＜；（かといって精度に対する姿勢をこの状況でほめたら上から目線だよね＞＜「まだまだじゃのう・・・＞＜」だよね＞＜；））

これでどうだろう？＞＜；

（つづき）
整数にどうしてもこだわるのであれば24bit整数で処理するデコーダがあるらしいのでそれを使うといい感じかもです＞＜
一例（ただしGPLv2・・・＞＜；）
[URL]

mp3を正しくデコードできていない

mp3のデコードが正しく無いせいで、-1.0～1.0を越えるデータを正しくデコードできていません＞＜
おそらくデコーダ（ffmpeg?）から16bitで受け取って、その後音量に関する処理をしているようですが、
そもそもmp3は16bitでデコードできるようなフォーマットではありません＞＜
詳しくは私が作成したmp3チェックデータとその説明書を読んでいただけるとありがたいです＞＜
[URL]

また、整数でのデコードにこだわっている点についてですが、
[フォーラムURL]

（ソースコードを完全に追って無くて斜め読みなのは申し訳ないのですが）
ffmpegのmp3デコーダは内部32bit floatで処理しているようです＞＜
[ffmpegのソースコードURL]

そうであるのであれば輪をかけて、16bit整数でデコーダから受け取る事のデータ精度上の意味は全くありません＞＜
単にデコーダが勝手に決めた結果的に元データと全く無関係と言える精度に落とし込んでいる（しかも波形が破壊されている）だけです＞＜
（つづく）

音界隈のたぶんものすごく影響力が高すぎる専門家である藤本健さんにも殴りかかるポーズになる＞＜（Windows音悪いよ騒動の時はちゃんと殴りこみました！＞＜（？））

どう難しいかというと、オレンジがキレてしまう＞＜；

これ、TuneBrowserに限らずだけど、オレンジの意見って、『多数派であるmp3を整数でデコードできる（※1）と勘違いしてる陣営』をぶん殴る形になるし、延長でWindows音悪いよリミッタ動かすなよ陣営に殴りこむことになるし難しい＞＜；
（※1 16bit処理でで正しくという意味で＞＜ 例えば24bit intで正しくデコードするライブラリはある＞＜（使った事無いけど＞＜））

ffmpegのソース超斜め読みしたけど、mp3デコーダの内部32bit floatっぽさ？＞＜

そもそもmp3にビットパーフェクトも何もないし、真にbitパーフェクト！（？＞＜；）というのならそれこそデコーダで使用してる浮動小数点そのまま使えばいいじゃんね感＞＜（ffmpegの中身忘れたけど＞＜）

ていうか、たぶんメディアプレイヤー系のアプリ作ってる人でも大半が「mp3は16bit（かなんか）」って勘違いしてるんじゃないのって思うんだけど・・・＞＜

整数教徒っぽいから誤解を解くのが大変？＞＜； アプリ作者、根本的に間違ってるっぽさ＞＜；

「ほんとにデコードできるの？」「わざとどれでもおかしくなるようにしてない？」って人はfoobar 2000を使ってみるといいかも＞＜（初期設定の状態でも正しくデコードできるはず＞＜）

CakeWalk Sonarとかもmp3正しく読めない＞＜ Cubaseもダメだった気がする＞＜（ザクさんに試してもらったけど忘れちゃった＞＜； 古いバージョンは少なくともダメだった＞＜）

両方！＞＜（規格上越えちゃいけないかは知らないけど実際超えて表現できてしまうし越えてるファイルが大量だし、ていうかそもそも整数で表現されるフォーマットじゃないんだから、勝手に16bit intにして壊すのはデコーダがアホかも＞＜）

久しぶりにメール確認したら、北海道が大規模停電した時の情報ほしいメールをいまさら読んで申し訳なさ＞＜；（メールごくまれにしか確認しない＞＜；）