楽器の削減と sf3 化でファイルサイズ削減
Web 上でサウンドフォントを使うには、極限までファイルサイズを削減する必要があります。 まずたいていのサウンドフォントはローカル実行を念頭に置いているので、バンクセレクトを考慮した不要な楽器データが含まれています。 Web 上では 128音＋ドラムしか使わないので、不要な音源を削除すると少しコンパクトになります。 さらにダウンサンプリングを行い、sf3 の圧縮レベルを LOW にすれば、もっと小さくなります。 ただし楽器ごとに必要な周波数は異なる上、たいていの楽曲で使われるピアノは高音質なケースが多いです。 そのような特徴を考慮すると、ダウンサンプリングは極力しないほうが良いと思っており、実際していません。sf3 形式についても無駄に知識を持ってしまいました。 sf3 形式は今のところ Ogg Vorvis 形式しか選択できないようです。 音を圧縮できない sf2 と比較すると大きな進歩ですが、Ogg Vorbis だと低ビットレートに弱いです。 今後の進化にはまだまだ期待できそうです。 たとえば Opus に対応したら音質・圧縮率・再生負荷、いずれもさらに改善できそうです。 サウンドフォントはまだまだひっそり進化しそうなので、 fluidsynth をベースにした js-synthesizer は、着眼点も良い気がします。
ちなみに最終的な完成品は Cloudflare Pages に置けば通信量の問題が発生しません。 jsDelivr に置く手もあるかなと思ったのですが、JavaScript とあまり関係がないのでひとまず自重しました。 Cloudflare Pages に置くためには 20MB 以下になるようにファイルサイズを整えます。
サウンドフォントのファイルサイズが極端に違う理由
上記の方法でサウンドのファイルサイズを削減できることもわかりました。 しかしそれでもファイルサイズが大きすぎて、Web上では使えないサウンドフォントが多いことに気付くと思います。 ファイルサイズが大きくなると単純にメモリ使用量が大きくなるので、ラグの原因にも繋がります。 逆にファイルサイズが極端に小さいサウンドフォントもあるので、そちらが何をやっているのかを知ることが大切です。まずは楽器を 128 用意せずに他の楽器に転用しているケースや、サンプリング周波数が低いケースがあります。ただこれは本質ではありません。 ファイルサイズの小さなサウンドフォントは、すべての波長を保存するのではなく加工処理でサイズを削減しています。 これがファイルサイズの秘密です。 具体的には、サウンドフォントは一定時間が経過した後はループ再生するような処理をしています。 ループ時間を長くすればするほど圧縮効果が望めますし、 ループ処理をうまく使えば MP3 などのエンコーディングより効率が良くなるのは、なんとなく予想できます。 つまりファイルサイズが奇妙に小さなサウンドフォントは、 おそらく既存の音声フォーマットの限界を超えた圧縮を実現しています。
これはなかなか面白い話で、サウンドフォントはきちんと作り込むと、既存の音声フォーマットよりずっと圧縮効果が望めることがわかります。 そして今はただのループ表現ですが、減衰係数なども考慮してもっと真面目に考えれば、まだまだ圧縮効果は望めそうです。 ただ現時点でそんなことに興味を持つ人はいないので、期待はできないでしょう…。 仮に来るとしたら、AI を利用して超高圧縮フォーマットの研究をする時にでも日の目を浴びるのかなあ。
サウンドフォントを楽器ごとに分離して再生
波形の加工処理を深くしていないサウンドフォントに加工処理をするのはさすがに大変です。 そのようなサウンドフォントのファイルサイズ問題は一定量どうしようもないところがあります。 しかしまだまだ削減の余地はあります。それは楽器別サウンドフォントを作り、1楽器ずつ読み込む方式です。 複雑な MIDI でも使っている楽器はせいぜい 20 ですから、ロードする楽器を削減するだけで通信量を 1/6 以下にできます。 もちろん GeneralUser GS などにもこの方式は適用でき、超強力です。 この方式を使うと十分に小さなサウンドフォントなどはダウンサンプリングも不要で、通信量だけが激減します。 ファイルサイズも MP3 よりずっと小さくなります。
分割サウンドフォント (.sf3) + MIDI で得られるメリットはとても大きいです。 1楽器ずつ読み込めば、特定の楽器の音質だけ上げたいと思ったときに容易に切り替えられるようにもなります。 ちなみにこれまでも fluidsynth や timidity をローカルで使えばできたことではありますが、 これまでは塊としてのサウンドフォントに焦点が当てられていたので、割と世界観が変わります。 楽器ごとにサウンドフォントを作ると、他のサウンドフォントと容易に組み合わせることができます。
ファイルサイズ比較
再生に必要なファイルサイズがどれくらい変わるか、ファイルサイズの比較実験をしてみました。 たとえば GeneralUser GS 1.471 (30MB) を使ってビットレート 192kbps で、 ネフェシエルの OP を MP3 エンコードすると 3.9MB になります。 しかし分割サウンドフォント (.sf3) + MIDI は 1,453KB しか必要としません。 ちなみに再生に必要な JavaScript 3.2MB を考慮すると合計 4.7MB なので、 1曲あたりの通信量だと若干負けてしまうのですが、大差はありません。 2曲以上の再生では通信量が圧倒的に有利で、分割サウンドフォントはどんなに再生しても 9.9MB を上回りません。 すべての楽器 9.9MB ロードした後は、1〜100KB 程度の MIDI ファイル以外には通信量を必要としないので、もはや MP3 は比較にもなりません。 たとえば様々な楽器で構成される同じくらいのサイズの MP3 を 100曲再生した場合、最低 25 倍は効率が良くなります。 現実的にはロードする楽器はそれほど多くないので、50倍くらいの差になると思います。 さらに楽器が少なければメモリ使用量も非常に少なく抑えられ、爆速な上に超軽量です。 しかもエンコードで劣化させずに再生するので音質も綺麗です。 ここまで圧倒的に MIDI が有利だと、MP3 を使う利点は音を不変にしたり楽器以外を利用するケースしかない気がします。1つのサウンドフォントだけだと特性がわかりにくいので、色々なサウンドフォントでも確認してみました。 ネフェシエルの OP がエンコードで出力される MP3 のファイルサイズは 3.9MB で変わらないので、再生に掛かるサウンドフォントの通信量だけが重要になります。 トータルファイルサイズが 3.3MB の TimGM6mb を使った場合は 500KB、 トータルファイルサイズが 30.0MB の SGM-V2.01 (Magenta.js と同様) を使った場合は 8.0MB、 トータルファイルサイズが 77.0MB の Live HQ Natural SoundFont GM V2.5.1 を使った場合は 17.3MB、となりました。 この数値を見ると、GeneralUser GS くらいのファイルサイズのサウンドフォントで再生するのが良いように思います。 リアルさを求めても個人的にはそれほど音質自体は変わらず、TimGM6mb は聞き慣れているせいか意外と好きだったりします。 単純に好きな音色かどうかだと思います。 ちなみに TimGM6mb でも耐えられるなら、100曲再生したときに MP3 の最低 68倍の通信効率があります。 Live HQ Natural SoundFont GM V2.5.1 だと 100曲再生しても大差はありませんし、さすがに 100曲再生することは少ないと思います。 リアルさを徹底的に求めるなら MP3 エンコード、通常再生なら MIDI と使い分けるのも良いかも知れません。
特定の楽曲に必要なコストだけでなく、楽器ごとのファイルサイズでも考えてみます。 というのも特定の楽器だけファイルサイズが大きいケースが結構あるからです。 特にリアルさを求めたサウンドフォントでは、よく使われるピアノのファイルサイズが大きいことが多いです。 ファイルサイズがバラバラすぎるサウンドフォントは予期せぬラグが発生することになるため、少なくともデフォルトには使いにくいと思います。 手元のリストを確認したところ、MuseScore General、SGM-V2.01、SGM-v2.01-NicePianosGuitarsBass-V1.2、FatBoy、Alex's_gm_v1.3、Airfont 380 final あたりはファイルサイズがバラバラすぎてデフォルトには使いにくそうでした。
ビルド
あとは上記の未来を実現するために、無料で利用しやすいサウンドフォントをまとめた リストから、 微妙なものを省いてビルドするだけです。ちなみに不採用リストを理由付きでまとめると以下。 基本的な条件として、変換後の総ファイルサイズが 100MB を超えたら Web には適していないので除外するつもりです。 また1ファイルが 10MB を超えたときも Web には適していないので除外しました。 さらに頻繁に更新するのは大変で、バイナリファイルで管理がしにくいため、なるべく枯れたものを採用します。 具体的な基準としては1年更新がない状態で高評価のものを採用予定です。 10MB over のものはダウンサンプリングすれば使える気もしますが、どれもリアルさを求めたサウンドフォントばかりです。 特徴が失われてしまうので、非サポートのほうが良いかなと思っています。- Musyng Kite 10MB over
- Daindune's Montage 10MB over
- DSoundFont 音質が微妙…
- Phoenix GMGS v1.5 まだ更新がありそう
- Patcharapon_HNY2023 まだ更新がありそう
- ColomboGMGS2 SoundFont v.12.6 まだ更新がありそう
特性を活かして作ったアプリ例はこちらです。
アプリの作り方は以下も参考にしてください。
0 件のコメント:
コメントを投稿