2020/08/05 (2020年08月 のアーカイブ)
MIDI (SMF) ファイルのレガシーなノウハウとか今後とか
どこかにこういうものはあるだろうと思っていたのに意外と見当たらなくて、いきなり MIDI-dump ユーティリティなんか作ったりしましたけど、SMFの扱いはそれなりに癖があるのでメモ。
https://github.com/g200kg/midi-dump
ちゃんとした規格は AMEI のページから見れます。
http://amei.or.jp/midistandardcommittee/MIDIspcj.html
すっかりレガシーなノウハウになってしまいましたが、これから初めて SMF を触ろうとしているなら、はまりやすいのはこんな所です:
- NoteOn のベロシティ 0 は NoteOff として扱う事。これと次のランニングステータスとの合わせ技でファイルサイズが小さくなる。
- ( 場合によっては処理が面倒な事になったりするのだが ) ランニングステータスをちゃんと処理するのを忘れないように。最近はデータサイズにあまり敏感では無くなったので忘れられがち。
- チャンクの構造はビッグエンディアンだけどベンドデータなんかはリトルエンディアンなので混同しないように。
- Track Name 等のテキスト系メタイベントのエンコーディングは基本無法地帯。日本で作られたMIDIファイルは s-jis 文字列が入っている事が多い。内容から自動認識するしかないが、CP1252 (ISO-8859-1) と S-JIS が混ざったりすると割とお手上げ。
- 読み込みの際に知らないタイプのチャンクはちゃんと読み飛ばす、チャンクのサイズはチャンクのlengthをリスペクトする事。XFフォーマットとか一部のMIDIファイルには追加のチャンクタイプが存在する場合がある。
- データの読み込みでメタイベント End of Track にエンカウントしたら以降のデータは無視する事。各トラックのデータは EOT の後ろにゴミデータが存在する場合がある。
と、ここまでは復習。
ここからは予習。
既に MIDI 2.0 規格が発表されているわけで、今後 MIDI ファイルも 2.0 対応になっていくはずですが、MIDI 2.0 での MIDI ファイルがどうなるかはまだ不明です。MIDI 2.0 は双方向通信でネゴシエーションするのが大きな特徴なのだけど、MIDIファイルは基本的に楽曲再生用シーケンスデータとして使われるという事を考えると、ネゴシエーションは実機での接続に任せて MIDI ファイルはネゴシエーション後にシーケンサーに読み込むためのデータという事になるのかなあ。知らんけど。
MIDI 1.0 に対する下位互換はありますが、MIDI 2.0 で拡張された分解能の向上なんかが使えないと意味がないので、本命はやはり MIDI 2.0 ネイティブの UMP をファイル化する方法ですかね。つまり今までバイトストリーム状態でランニングステータスなんかを使って割とせこせことサイズ削減していたのが、Uint32 ベースのパケットストリームを扱う感じでしょうか。1楽曲あたりのサイズは増えそうだけどそこは時代の流れですね。
UMP のパケットストリームに適当なデルタタイムが付いている感じだとして MIDI 2.0 で追加された JR タイムスタンプ (Jitter Reduction) との関係はどうなるのか?
とか、まだ色々面倒な事がありそうですが、そのうち仕様が出てくるのではないかと期待。
まあテキスト系メタデータにエンコーディング指定が付いててくれればそれだけで...
MIDI 2.0 の規格はまだ英語版ですが AMEI のページからダウンロードできます。
http://amei.or.jp/midistandardcommittee/MIDI2.0/MIDIspcj2.html
結構大きな仕様なので、どこから読めば良いのか戸惑い勝ちだけど、100から104に順番に行くのが正攻法ですかね。ただ CI の周辺は今までにまったくなかった概念なのでなんとなくもやっとして全体像がつかみにくいので MIDI 2.0 プロトコルの UMP のあたりの話の方がとっつきやすいかも知れません。
何にしても MIDI 2.0 の規格は MIDI 1.0 の知識がある事を前提として書かれているので、MIDI 1.0 の内容を知らずにこれだけ読んでも多分なんだかよくわからなくなります。
Posted by g200kg : 2020/08/05 12:38:14