orange @[email protected]

DirectShowじゃなくDirectSoundが何かしてるっぽい挙動っぽさ？＞＜

DirectShowでwavファイル再生したら精度めちゃくちゃって出た＞＜； なぜ？＞＜；

thunder?><

！？＞＜

・・・よく考えたら当たり前なのかも？＞＜（WASAPIに32bit整数で送って、32bit精度で鳴ってなかったらむしろWindowsがぶっ壊れてる＞＜；）

TuneBrowserしゅごい！！！＞＜ ちゃんと32bit整数の精度でmp3を再生してる！！！！＞＜

オレンジが作ったこの精度チェックする仕組み、他アプリの音量とかも監視した上で（＝他のアプリの音が鳴ってたら正しくチェックできないから）、いいタイミングで自分自身の再生精度が正しいのかセルフチェックし続けるメディアプレイヤー作れそう＞＜
これなら「Windowsはリミッター云々で音悪い」って文句言ってる人も納得しそう？＞＜；

1. WASAPIループバック録音する(32bit floatのはず＞＜)
2. 各サンプルを集計する＞＜（16bitなら65536種類以下になるはず＞＜）
3. さらに集計したサンプル間の差を集計する＞＜
4. もし整数なデータのみを再生(普通は16bit)のみをしているのであれば、全てのサンプルの差が整数倍にしかならないはず＞＜

全部整数倍だった → すばらしい！＞＜

一部違ってた → 別の音が混じって鳴ったか、そもそも整数な音声データでは無い（例えば正しくmp3を再生した）か、音デカすぎてリミッターに引っかかった

これつまり、精度の測定もせずにビットパーフェクト再生とか言ってんじゃねーよ！＞＜ と言えるツールが出来たと言える＞＜（だだしあくまでWindowsのオーディオエンジンの中でであって、デバイスドライバとかハードウェアがどう処理するかは別＞＜（例えばこのまま16bitでDACに送れば16bitの精度では当然再生出来ない＞＜））

Perfect Precision!><
WASAPI共有モードが完全な精度で再生できている事（1枚目）と、デカすぎる音（わりと不評な）標準リミッターが動いた（結果鮮度が落ちた）事の検出（2枚目）もできた！＞＜ オレンジしゅごい！＞＜（自分で言った）

ここちょっとずるい＞＜；
"WASAPI共有モードで普通に再生するだけで"
普通に含まれない再生方法もあって「クリッピング寸前の爆音」かつ「16bit再生」の場合には、Windows音悪いよ論者の言うとおり音が変化する＞＜
回避する為には、プレイヤー側で32bit float化して音量調整してからWASAPIに送ればいい＞＜（そうすれば数学的に16bitのデータをbitパーフェクト再生と全く同じであると言える完全な精度で正しく再生できる＞＜）

Windowsの音声処理すばらしい！！！！＞＜ 誰だよ音質悪いとか言い出したやつ！＞＜

つまり、オレンジの推測通り、もし32bit float入力対応のDACを持っているのであれば、WASAPI共有モードで普通に再生するだけで、ビットパーフェクト再生＞＜（と全く同じであると数学的に証明できるはず（っぽい＞＜（数学苦手＞＜；）））

オレンジテストアプリの出力抜粋＞＜

00 :0.000030518
00x2:0.000061035
01 :0.000061035
01x2:0.000122070
01 Multiple by Minimum:2.000000000
02 :0.000091553
02x2:0.000183106
02 Multiple by Minimum:3.000000000
03 :0.000122070
03x2:0.000244141
03 Multiple by Minimum:4.000000000
04 :0.000152588
04x2:0.000305176
04 Multiple by Minimum:5.000000000
05 :0.000183106
05x2:0.000366211
05 Multiple by Minimum:6.000000000

つまりこの「かなり正確に16bit音声を再生できるのでは？＞＜」の方が正しい可能性＞＜（まだ調査中＞＜）

https://mstdn.nere9.help/@orange_in_space/100783749083862654

ちゃんと16bitっぽい！＞＜；（WASAPI共有モード＆Windowsのミキサの精度すばらしい！＞＜；（オレンジのバグすばらしくない＞＜；））

具体的に言うと、バイト列から32bit float読む時に、4ずつじゃなく1ずつインクリメントしてた；；

馬鹿すぎてつらい；；