orange @[email protected]

フォーラム、何者かみたいな情報書かなくていいんだろうか？＞＜；（こことツイッターのURLを一応書くべき？＞＜；）

mp3のデコード正しくない問題（ものすごく正当）からの、ビットパーフェクト信仰おかしい世問題への攻撃を経由して、ついでに「『Windowsのリミッタの動作正しくない』って言ってる人の方がデジタル録音の原理に理解がないんだよ」という認識の布教（？）、やりたいけど膨大すぎるし味方少ない・・・＞＜

あと、上から目線に見えてしまうじゃなくて上から目線だし、攻撃しているかのような面も、実際誤ったビットパーフェクト信仰を少数派（小数派？＞＜；）にしたいというのがあるのでアレ＞＜；
（クリッピングの問題でもマスタリングしたエンジニアをクビにすべきって言ってるし、音以外の話題の例で言うなら、ハイテク機の理念に理解がないエアラインパイロットを見下してる＞＜；）

書いてくるかも＞＜；

これ、もうひとつの問題として、受け入れられなかった場合、オレンジが問題提起する時の悪い代表例のひとつとしてあげるようになってしまうのがあれかも＞＜；

これを追加すればマシ？＞＜；
（でも、上から目線感がさらにアップっぽさも？＞＜；）

世の中の結構多くのソフトウェアでそうなのですが、
（例えばWMPやWinamp、プロ向けのソフトウェアではCakewalk (Sonar)やCubase 8（9.5では修正されたそうです）等）

難しい＞＜；（さっきの下書きそのままは、やっぱマズい？＞＜；）

これの話ね＞＜

例えばAdobe Audition 3.0なら32bitデコードに変えれば正しく読めるので、そこから煮るなり焼くなりすればいいかも＞＜
（なぜかデコード設定画面が、保存ダイアログでmp3で保存にしてオプションボタンを押すと出てくる『エンコーダオプション』にあるいう謎UIだけど＞＜；）

ていうか一番手っ取り早いのは、16bit intでデコードするアプリを捨ててまともなのでデコードすること＞＜（何度も書いてるけど例えばfb2kならちゃんとデコードできる＞＜）

オレンジのチェックデータ、聞かないでどう処理しているのかがわかるために作ったデータなのでわかってしまっている・・・＞＜

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

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

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

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

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

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

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

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