藤本健のDigital Audio Laboratory
第1054回
生成AIと一緒に音楽プレーヤー「DAL Player」を鍛え直す。24bitの壁とGitHub初公開まで
2026年8月24日 08:00
先月の連載で、ChatGPTとOpenAIのコード生成AI「Codex」を使い、わずか30分でASIO対応の音楽プレーヤー「DAL Player」を作った話を紹介した。C#/.NET 10/WPF/NAudioという構成で、Ver0.1で最小限の再生機能を実装し、Ver0.2でASIO Control Panelボタンを追加。ただし異なるサンプリングレートのWAVへ切り替えるとアプリがクラッシュするバグが見つかり、これを次回の課題として持ち越していた。
今回はその続報である。単にバグを直しただけでなく、想定していなかった原因にたどり着き、最終的にはソースコードだけでなく実行可能な形でGitHubに公開するところまで進んだ。
AIと一緒に開発を進めていく過程で、思っていたのと違う方向に話が転がっていくのもまた面白い。約3時間かけて、AIとやり取りした過程を紹介していこう。
まず環境復旧から始まった
第2回に着手しようとしたところで、まず準備が必要だった。というのも、いろいろなソフトやハードを使って実験をする筆者は最低でも月に1回、多いと毎日のようにPCをフォーマットしてまっさらな状態にしてしまう。
正確にはAcronisのTrueImageでバックアップしておいた環境に戻すのだが、当然前回のDAL Player Ver0.2を開発した後に、PCを初期化しているので、開発環境がすべて消えている。そもそもCodexをどうやってインストールしたかも忘れてしまっていた。
もちろんプロジェクトの［source］フォルダはまるごとバックアップしてあったので、ChatGPTに相談しながら、新しいChatGPTデスクトップアプリ(現在はCodexがこの中に統合されている)と、Visual Studio Community 2026を入れ直し、バックアップを元の場所に戻すところから再開した。
ここで気を使ったのが、前回Codexが作った少し特殊なGit構成だ。
［.git］が通常のディレクトリではなく、［repo-ultimate］という場所を参照するポインターファイルになっていた。これが壊れていないかを、まずCodexに読み取り専用で調査させることにした。
結果は上々だった。ソースコード一式はもちろん、Gitのコミット履歴も［main］ブランチも、Ver0.2のタグも、すべて無傷で残っていた。NuGetの［NAudio］パッケージだけは標準キャッシュから消えていたが、これは復元時に自動的に取得できるものだ。
実際にNuGet復元とDebugビルドを試すと、警告・エラーともゼロで無事に成功。改めてビルドされたDAL Player Ver0.2を起動させてみると、前回同様に動作することが確認できた。ここでようやく、前回終えた地点まで戻ってこられたことになる。
もちろん、そんな難しいことを筆者が理解した上で、調査し、復旧させたのではない。
ChatGPTに「それからどうするの？」と相談して、「Codexに以下のプロンプトを投げなさい」と指示されて、それにしたがっただけだ。
感覚的には、ほとんど何も考えず、ChatGPTに言われるがままに操作をしている印象で、AIと二人三脚とはいえ、AI様と人間の主従関係が完全に逆転している感じだ。
3本立てで進めることに決める
環境が整ったところで、今回何をやるかをChatGPTに相談した。やりたいことは大きく3つあった。
- 前回見つかったサンプリングレート切替時のクラッシュを直す
- GitHubにソースコードを公開する
- WAVだけでなくMP3やFLACなど他のフォーマットにも対応させる
ほかにも、いろいろと使いにくいところがあるので、その点も向上させたいし、さらにプレイヤーとしての機能は向上させたいところ。
ただ、ChatGPTからは、「(1)クラッシュ修正→(2)GitHub公開→(3)フォーマット拡張」の順番が自然だという提案があった。いきなり機能を足すより、まずVer0.2で見つかった問題を潰してから公開したほうが、最初に読者に渡すバージョンとして安心だという理屈である。これはもっともなので、そのまま採用することにした。
クラッシュの原因はサンプリングレートではなかった
まずはクラッシュ修正から着手する。
Codexに、Ver0.2のコードを調査させたところ、［AsioOut.Stop()］を呼んだ直後に［Dispose()］していた点が怪しいという指摘があった。
NAudioの設計では、［Stop()］の完了は［PlaybackStopped］イベントで確認するのが本来の作法で、その完了を待たずに次のASIOインスタンスを作ろうとすると、ドライバー側の再設定処理と競合する可能性があるという。
そこで……
- ［Stop()］を［StopAsync()］に変える
- ［PlaybackStopped］を待ってから破棄する
……といった修正をCodexに依頼し、Debugビルドは無事成功。さっそく実機で、44.1→48→96kHzと切り替えながらテストしてみた。
もちろん、こうしたやりとりも、筆者の頭で理解して行なっていたのではなく、AIに言われるがままのやりとりではある。
ところが、だ。実際に何本もWAVファイルを試していくと、様子がおかしい。うまく再生できるものと、できないものがある。
傾向を探ってみると、どうやら「24bitのデータでうまくいかないケースが多い」ことに気づいた。しかも「必ずしも24bitがすべてダメというわけでもない」という、なんとも据わりの悪い結果になった。そこで、筆者がテスト結果をメモしてChat GPTに渡したのが以下の結果だ。
- 44.1kHz/16bit → OK
- 48kHz/24bit（Pro Tools書き出し）→ NG
- 96kHz/32bit → OK
- 96kHz/24bit → NG（アプリは落ちないが無反応になり、以降別のファイルも再生できなくなる）
- 各種レコーダー由来の24bitファイル → いずれもNG
つまり、当初「サンプリングレートの切り替えが原因」だと思っていた見立ては、どうやら的外れだったらしい。
SOUND FORGEでの実験が決め手になった
上記の結果をCodexに伝えると、WAVヘッダーの構造的な違い(Extensible形式かどうか、有効ビット数の扱いなど)を疑う分析が返ってきた。ただ、憶測だけで直しに行くのは避けたい。そこで、実際に手を動かして切り分けることにした。
やったことはシンプルだ。再生できない24bitのWAVファイルを波形編集ソフトであるSOUND FORGE Proで読み込み、サンプリングレートは変えずにビット深度だけ32bitにして書き出す。それをDAL Playerで再生してみる、という実験である。
結果は明快だった。
48kHz/24bitの再生できなかったファイルを32bitに変換すると、あっさり再生できた。96kHzの24bitファイルでも同じ結果だった。同じ音源、同じサンプリングレートで、ビット深度を変えただけで再生可否が入れ替わる。
これは、サンプリングレートではなく、24bit PCMをASIOへ渡す経路そのものに問題があることをかなり強く示す結果だった。
この実験結果を踏まえてCodexに再調査を依頼したところ、実際に提供したPro ToolsおよびSOUND FORGE書き出しのWAVファイルのヘッダーを解析し、いずれも正常なWAVE形式のPCMであり、ファイル自体に破損はないという報告が返ってきた。
問題は、24bit PCM(1サンプル3バイトのpacked形式)を、WaveFileReaderからAsioOutへそのまま渡していた、DAL Player側の再生経路にあるという結論に至った。
24bit→32bit floatへの正規化で解決
修正方針は、WAVから読み込んだ音声データを、ASIOへ渡す前に32bit IEEE floatのIWaveProviderへ変換するというもの。サンプリングレートやチャンネル数、再生時間はそのまま維持し、変わるのはASIOに渡す直前のサンプル表現だけである。
16bit・24bit・32bitのWAVをすべて同じfloat経路に統一することで、ビット深度による扱いの差を吸収する狙いだ。
Codexによる実装後、Debugビルドは警告・エラーともゼロ。実機では、Pro Tools書き出しの48kHz/24bit、Sound Forge書き出しの96kHz/24bit、各種レコーダー由来の24bitファイル、さらに16bit・32bitのファイルも含めてすべて正常に再生できることを確認した。異なるサンプリングレート間の切り替えも問題ない。
「サンプリングレートを変えると落ちる」と思っていた話が、掘り下げてみると実は「24bit PCMの扱いに問題があった」という展開になったわけで、この経緯自体、AIと一緒に手探りでバグを追いかける様子として、なかなか興味深い記録になった。
これによってバグフィックスしたDAL Player Ver0.3が完成。ここまで確認できたところで、CHANGELOGとREADMEを更新し、［Release v0.3 - Fix ASIO playback and 24-bit WAV support］というコミットメッセージとともに、［Ver0.2］のタグはそのまま残しつつ［v0.3］のタグを新たに作成した。
いよいよGitHubへ公開
Ver0.3が固まったところで、次はGitHubでの公開である。
筆者もGitHubのアカウントは以前から持ってはいたが、実際に自分で公開することなど初めて。ここもChatGPTと相談しながら行なうことにした。
ChatGPTに言われるがままに、まずGitHubへログイン後（10）、空のPublicリポジトリ「dal-player」を作成し、そこへ［main］ブランチと［v0.2］［v0.3］のタグをpushした。GitHubへの認証はGit Credential Manager経由のブラウザ認証で、特につまずくことなく完了した。
ただし、ここで一つ気づいたことがある。GitHubにpushしたのはソースコードとREADME、LICENSE、CHANGELOGなどであり、ビルド済みの実行ファイルはリポジトリには含まれていない。
［.gitignore］で［bin］や［obj］を除外しているためで、これ自体はGitHubの一般的な運用としては正しいらしい。実行ファイルを配布したい場合は、別途「GitHub Releases」に載せるのが定石だ、という。
「ごく小さなプレーヤー」がなぜこの分量に？
そこで配布用のビルドを作ることにしたのだが、ここでも一悶着あった。
まず、Visual StudioやNET Runtimeが入っていない環境でも動かせるように、と依頼してできあがったのが「self-contained」版だ。.NET 10 Windows Desktop Runtime一式を同梱する方式で、これなら読者側は追加のインストール作業なしにそのまま実行できる。
ところが、できあがったフォルダを見て驚いた。ファイル数465、展開後のサイズは約165MB。ASIO再生とWAVファイルを開くだけの、ごく小さなプレーヤーにしては、あまりに大仰な分量だったのである。
そこで比較のため、もう2種類のビルド方式を試してみた。
| 配布方式 | ファイル数 | ZIPサイズ | NET Runtime |
|---|---|---|---|
| Framework-dependent | 11 | 約0.31MB | 別途インストールが必要 |
| Self-contained | 465 | 約72.5MB | 不要 |
| Self-contained Single-file | 1 | 約68.2MB | 不要 |
Framework-dependent版は驚くほど小さいが、利用者のPCにあらかじめ.NET 10 Desktop Runtimeが入っている必要がある。一方、Self-contained + Single-file版は、.NET Runtimeを丸ごと抱え込んだ約165MBの実行ファイル1個にまとまる。ファイル数で言えばこちらのほうが圧倒的にシンプルで、読者に案内する分には扱いやすい。
結局、「ダウンロードして展開したら［DAL Player.exe］を起動するだけ」という手軽さを優先し、Single-file版を正式な配布物として採用することにした。
念のため、Visual StudioやNET Runtimeを一切インストールしていない別のPCへこのZIPだけを持ち込み、そこで起動からASIOドライバーの認識、24bit WAVの再生、ASIO Control Panelの表示まで一通り動作することを確認した。
わずかなオーディオプレーヤーが、.NET Runtimeを内包した途端に165MBへ膨れ上がるというのは、AIによるコーディングの話とは別に、現代の.NETアプリケーションの配布事情そのものを垣間見るようで、これはこれで興味深い発見だった。
GitHub Releasesで正式公開
最後に、GitHubの「Releases」画面から手作業でv0.3のリリースを作成した。タイトルは「DAL Player v0.3」とし、ASIO再生や16/24/32bit PCM対応などの機能一覧、そしてSingle-file版であることやSHA-256のハッシュ値を説明欄に記載。検証済みのZIPファイルを添付して公開した。
これで、DAL Playerは単なるソースコードの置き場ではなく、誰でもダウンロードしてそのまま試せるソフトウェアとしてGitHub上に存在することになった。一般ユーザーへの案内には、以下のURLを使えばよい。
次回はフォーマット対応へ
今回は、環境復旧から始まり、「サンプリングレート切り替えのバグ」だと思っていたものが実は24bit PCMの扱いの問題だったという意外な展開を経て、最終的にGitHubでの正式公開までたどり着いた。
ChatGPTとの相談、Codexへの指示と実装、そして実機での地道な検証という組み合わせは、前回にも増して「人間とAIの共同作業」らしい進め方になったと思う。まあ、主人はAIだが…。
WAV以外のフォーマット対応や使い勝手の向上、MP3やFLACへの対応、そしてASIOだけでなくWASAPI Exclusiveなど、Windowsオーディオまわりのテーマとも絡めて発展させていきたい。
DAL Playerを実験ツールとして育てていくこの企画、ときどき進めていくつもりだが、今後もお付き合いいただければと思う。
リクルートに15年勤務した後、2004年に有限会社フラクタル・デザインを設立。リクルート在籍時代からMIDI、オーディオ、レコーディング関連の記事を中心に執筆している。以前にはシーケンスソフトの開発やMIDIインターフェイス、パソコン用音源の開発に携わったこともあるため、現在でも、システム周りの知識は深い。 著書に「コンプリートDTMガイドブック」(リットーミュージック)、「できる初音ミク&鏡音リン・レン 」(インプレスジャパン)、「MASTER OF SONAR」(BNN新社)などがある。またブログ型ニュースサイトDTMステーションを運営するほか、All AboutではDTM・デジタルレコーディング担当ガイドも務めている。Twitterは@kenfujimoto。