orange @[email protected]

マイクロソフトへのフィードバックって日本語でもまともに相手してくれるんだろうか？＞＜；

オレンジが前に作ったmp3再生環境チェックデータ、
https://github.com/orange-in-space/mp3-playback-check-audiodata
をWindows 11の（新）メディアプレイヤーで再生したら、正しくないデコードされてた！＞＜；
マイクロソフト、馬鹿＞＜
ちなみにWindows メディアプレイヤー従来版の方もダメでした＞＜

それだとオレンジが実験したとおり「内部（デバイスドライバにたどり着く前）でどう処理されたかをチェックするぞ！＞＜」が出来なくなっちゃう＞＜（つまりどの段階でデータが破壊されたかがわからなくなっちゃう＞＜）

そんな変な実装にするメリットを無理やり考えるなら、「ループバックは出力の監視測定用なんです！」って発想で出力監視をしやすくした？＞＜；

もしかして、ミックスするタイミング変えたのも勘違いである可能性がある・・・？＞＜；
勘違いだとするとミックスしたあと音量下げて出力デバイスのフォーマットにあわせて一度ビットレート変換してからそれをもう一度32bit floatに戻したものをループバックデータにしてる？＞＜；
でも、そんなメリットもよくわからないめんどくさい実装なんてするかな？＞＜；

色々試したけど、内部で整数で処理してるっぽい挙動してる・・・・＞＜
もしそうなら音質というか精度的には一長一短というか、まともなアプリとすごいオーディオインタフェースの組み合わせの場合はある意味音質低下なんでは感＞＜

もしかして、内部処理がfloatじゃなくなった・・・？＞＜；

あれ？＞＜；
24bitのデータ再生しても測定結果が24bitにならない・・・？＞＜；

オレンジが前に作ったオーディオが整数精度相当で再生されてるかチェックするアプリ使って、Win 11のメディアプレイヤーで普通に再生したら整数精度相当って出た＞＜；
何か間違って無ければ、つまりたぶんWindows 11のオーディオエンジンはオレンジが前にわざわざ作った整数精度相当のデータを破壊しないように音量調節する音声再生するやつと同じ状態になってる・・・？＞＜；

Beがもしハードウェアを諦めずなおかつつぶれないで生き残ってたら、Threadripper積んでコア数増えすぎて前面がCM-5みたいになってるモンスターマシンを売ってたんだろうか？＞＜；

12年くらい前？に作ったBeBoxのblinkenlights(BeBox本体前面についてるLEDバーグラフのCPU負荷計)を模したCPU負荷メーターアプリ、12論理コアのマシンで動かしたらデスクトップ両脇に6本ずつバーグラフが現れて21世紀っぽさ＞＜

オシロスコープミュージックを見るために作ったXYオシロスコープアプリも、オシロスコープ部分にスケール調整機能をつけなかったので爆音再生しないと見れなくなった＞＜；

手抜きして作るなら、オーディオプレイヤーをライブラリとしてつくって、そのクラス2個作って、同時に再生すればあんまりずれなさそうだし、同期は遅い方にあわせるなら雑になら空白サンプル、ごまかすならてきとうにサンプル複製して遅らせる機能をつけとけばなんとかなりそう＞＜

軽量なバイトストリーム用リングバッファ、.NET側で標準で用意してほしい＞＜；
(数ヵ月前になんか記事見つけて読んだけど、バイトストリーム用リングバッファってバグなしに実装するのかなり難しいらしい・・・＞＜(実際難しかったしバグあるかわからない＞＜))

セッションごとのループバックは音量調節する前のなのかな？＞＜；