ブラウザ内ローカル処理

ブラウザ内ローカル処理とは、音声ファイルのデコードや処理をユーザー端末のブラウザ内で完結させる方式のことです。libsonare の各デモは、解析、ミキシング、リアルタイム FX、マスタリングレンダーのためにソース音声をサーバーへアップロードしません。

これは libsonare のもうひとつの軸であり、本格的な DSP を提供しつつ、ユーザーの音声を設計レベルで秘匿に保つための仕組みです。

ローカルで完結する処理

ブラウザデモでは以下がブラウザ内で実行されます。

• ファイルデコードはブラウザの Web Audio API または WASM の Audio.fromMemory* ヘルパーで行う。
• 解析、レンダリング、ミキシング、リアルタイム FX は、デモに応じてページ、Web Worker、AudioWorklet 上で動く。
• DSP は libsonare の WebAssembly モジュール内で動く。
• WAV 書き出し、JSON レポート生成、可視化用データの生成もブラウザ内で完結。
• ソース、レンダリング結果、リファレンス、設定はローカルオブジェクトとして保持。

ネットワークから取得するもの

ページ本体、JavaScript バンドル、WASM ファイル、フォント、アクセス解析スクリプトは、通常の Web サイトと同じくネットワークから読み込まれることがあります。これは、音声を処理のためにアップロードすることとは別物です。

コードが読み込まれた後の音声処理経路自体は、すべてローカルで完結しています。

トレードオフ

ローカル処理の利点:

• アップロード待ちがない。
• サーバー側にファイルが保管されない。
• クレジットや順番待ちが発生しない。
• 端末の外に出せない素材でも扱いやすい。

制約:

• 長尺ファイルはユーザー端末の CPU・メモリ性能に依存する。
• モバイルブラウザでは制限が厳しい場合がある。
• 対応コーデックは OS／ブラウザによって差がある。
• 端末側でレンダリングできなかった場合のサーバーフォールバックはない。

押さえておきたいポイント

機密性の高い素材を扱うときも、通常のページと同じようにコードや WASM はネットワークから読み込まれます。重要なのは「読み込み後の音声処理の段階で、ソース・リファレンス・解析バッファ・レンダリング結果がアップロードされない」設計になっていることです。

大きなファイルでレンダリングが遅いときは、サーバー側の混雑ではなく、手元の端末の CPU・メモリが上限に達している可能性が高いです。短い区間で挙動を確認する／別ブラウザを試す／デスクトップ環境で実行する、といった対処が現実的です。

実装メモ

デモは、必要に応じてデコード済みソース、レンダリング後の WAV、JSON レポート、リファレンス音源、エクスポート設定に object URL を作成します。これらはリモートのファイルではなく、ブラウザのローカルメモリ上のデータを指す URL です。差し替え時やコンポーネントのアンマウント時には revoke してメモリリークを防ぎます。プレビュー再生・WAV 書き出し・レポート保存はいずれもこの仕組みの上に乗っているため、音声ファイルがネットワーク経由でやり取りされる経路は持っていません。

レンダリング、リファレンスマッチング、重めの解析タスクは、必要に応じてモジュールワーカーで動きます。libsonare の WASM が重い処理を実行している間も、UI スレッドをブロックしにくくするためです。

リアルタイム FX では、音声コールバック用に AudioWorklet 系の実行を使います。

ワーカー内で例外が起きた場合も、UI 側で扱いやすいエラーオブジェクトに整形してから返します。長尺ファイルで失敗しても、ページ自体が固まらないようにするためです。

関連: エラー復旧, マスタリング品質チェックリスト, WASM