要約
- 回復ジャーナルは、失われた命令をすべて順に再実行する仕組みではない。長く残る演奏上の誤りを、限られた時間の乱れに収めることが目的である。
- 音を出し始める命令が欠ける場合と、止める命令が欠ける場合では、その後への影響が異なる。受信側には、遅れた発音を見送る判断も必要になる。
- 共通の履歴形式だけでは、初期状態、履歴の範囲、無音時の送信、楽器固有の挙動まで解決しない。規範的な要件と、実装指南に示された一つのアルゴリズムを区別する必要がある。
見つかった命令を実行しない理由
なくした音の情報が見つかった。では、その音を出せばよいのだろうか。ファイルの欠けた部分を埋める仕事なら、それで前進できるかもしれない。しかし演奏では、音が現れる時刻そのものが内容の一部である。拍を逃した発音を後から足すと、欠落とは別の間違いを作る。
2011 年 6 月の RFC 6295 に記された RTP MIDI の回復ジャーナルには、この事情が細部まで入り込んでいる。音符を扱う Chapter N の NoteOn ログは、元の命令が実行されるべき正確な時刻を持たない。Y ビットは、その音を鳴らすか見送るかについての助言を与える。過去の命令を今すぐ再生せよ、という絶対的な指図ではない。
受信側は、失われた発音を見送りながら、その命令があったものとして内部の回復用記録を更新することもある。耳には何も加えず、状態の整合性だけを取り戻す。復元できた情報量と、実際に増やすべき音の数は一致しない。
ここにあるのは回復の放棄ではない。何を回復の成功と呼ぶかを、通信の都合だけで決めなかった結果である。
音声ではなく、楽器への命令を運ぶ
RTP MIDI が扱う MIDI は、録音された波形ではなく、楽器に何をさせるかを表す命令である。音の開始、終了、音量の変更などが届き、受信先の音源やソフトウェアが、それまでの状態を使って音を生成する。命令が短いからといって、失った影響まで短いとは限らない。
2006 年 11 月の RFC 4695 は、すでに二種類の乱れを区別していた。一時的な乱れは、その出来事とともに過ぎる。NoteOn を失えば、一つの音が鳴らないが、その欠落は通常、その音の予定された長さを越えて続かない。
一方、NoteOff を失うと、終わるはずだった音が鳴り続けることがある。チャンネル音量の変更を失えば、その後の音がいつまでも大きすぎたり小さすぎたりする。後の命令や音源の特性で結果は変わるものの、自然に収束することを前提にはできない。
同じ一つのパケット損失でも、修復の優先順位は違う。この規格は、信頼性を単なる受信バイト数で測らず、失った命令が将来の演奏をどう拘束するかから考えた。
終わらない誤りを、終わる誤りに変える
回復ジャーナルの要求は、信頼できない転送路から再生される演奏に、無期限に残る乱れを生じさせないことである。通信中に一瞬も乱れないこと、すべての発音が正刻に戻ることとは違う。
基本となる RFC 3550 の RTP 自体も、確実な到着、順序どおりの到着、一定の遅延を保証していない。シーケンス番号やタイムスタンプは共通の観測材料を与えるが、欠けた番号だけを見ても、どの音を止めるべきかは分からない。
そこで MIDI 用のペイロード形式は、アプリケーションが必要とする履歴を運ぶ。受信側は、欠落の後に到着したパケットのジャーナルと、自分が知っている履歴を比較する。違いをもとに補正命令を実行し、音が止まらないなどの持続的な誤りを解消する。
この方式は、失われた各パケットの再送に依存しない。元の通信列を一つずつ復刻する代わりに、現在の楽器を安全な状態へ戻す。結果として生じた短い乱れは消えないが、その乱れが後の演奏を支配し続けることを防ぐ。
ジャーナルにも記憶の端がある
履歴はチェックポイントから始まる。現在のパケットを I、チェックポイントを C とすれば、対象は C から I−1 までの命令であり、I に含まれる新しい命令そのものは履歴に入らない。C と I が同じなら、この履歴は空である。
規格が任意の個数のパケット損失を回復できると述べるときも、その範囲はチェックポイント履歴の中に限られる。ジャーナル付きのパケットを受け取っただけで、どれほど長い断絶も埋まるわけではない。受信側には、今回の欠落を履歴が覆っているか確認する材料が用意されている。
さらに、Chapter N は普通の発音と停止の交互パターンを扱うための構造であり、過去のすべての発音を記録した演奏日誌ではない。同じ音高に複数の NoteOn が重なる使い方などには、Chapter E による追加の扱いが必要になる。鍵盤やドラムの例でうまくいくアルゴリズムを、別のコントローラーに無条件で移せない理由である。
音を止める処理にも限界がある。NoteOff とダンパーペダルの操作順を、ジャーナルだけから常に取り戻せるわけではない。受信側の自分の履歴が推定を助ける場合もあるが、分からなければ、ペダルによる持続音が誤って残ることを避ける側に判断する。短い不自然さを受け入れてでも、終わらない不自然さを防ぐという考え方がここにも現れる。
弾かない時間にこそ、通信が必要になる
2006 年の情報提供文書 RFC 4696 は、実装の難所を分かりやすい例で示す。NoteOff のパケットを失い、その後、演奏者が五秒間何もしなかったとする。次のパケットがなければ、受信機は番号の飛びを観測できず、音が余分に続く時間も長くなり得る。
これは実在の公演事故の報告ではなく、設計上の例である。送信側の静けさが、そのまま受信側の静けさを意味しないことを示している。
指南書は、MIDI 命令のリストが空の保護パケットを検討する。新しい音楽的動作がなくても、パケットは番号の進行と回復に必要な情報を届けられる。空の命令リスト、空のジャーナル、ジャーナルを使わない流は、それぞれ別の状態だ。
短い間隔で送り始め、静けさが続けば間隔を広げる例もある。ただし、示された時間を普遍的な規定値として扱ってはいけない。RFC 6295 の guardtime は、隣り合うパケットの最大間隔を設定する手段だが、文書中の典型的な範囲は強制的な上下限ではない。
何より、混雑を避ける責任が優先する。RFC 3551 にある共有網での公平性の考え方は、音楽の低遅延要求にも関係する。保護を急ぎたいという理由だけで、他の通信を押しのけて無制限に送ってよいことにはならない。
一つのアルゴリズムを、標準そのものにしない
RFC 4696 が紹介する NMP 受信機は、遅れた発音を見送り、それ以外の命令で持続状態を更新することがある。順序外パケットは無視する。すでにジャーナルから行った補正を、古い命令が重ねて実行してしまう危険があるからだ。
しかし、この文書は明確に非規範的な実装指南である。特定のネットワーク条件と限られた命令集合を想定し、再生用のバッファーを使わない例を説明している。指南書自身が、その設計はバッファー能力を求める一つの相互運用要件を完全には満たさないと断っている。
規範的な要求は、もっと広い実装の余地を残す。順序外パケットを処理して持続的な誤りを作ってはいけないが、常に捨てることだけが唯一のアルゴリズムではない。バッファーを持つ受信側なら、再生時刻まで回復処理を待つこともできる。欠落したと思ったパケットが、まだ間に合う形で到着する可能性があるためだ。
したがって、指南書の古いネットワーク観測を現在のすべての接続の性能と見なしたり、その例を全音源への適合保証に変えたりはできない。共有すべき意味と、現場で選ぶべきアルゴリズムを分けることが、この歴史を読む前提になる。
履歴を短くするには、受信側を知る必要がある
既定の閉ループ方針では、受信側からの進捗報告を利用してチェックポイントを進め、ジャーナルを小さくする。通常は RTCP の最高受信シーケンス番号が使われるが、合意された別のフィードバック手段も認められる。報告が示すのは通信上の進捗であり、聴衆が完璧な演奏を聞いたという証明ではない。
新しい受信側が途中参加すると、この省略が問題になることがある。音量の設定はずっと前に送られていて、最近の履歴には残っていないかもしれない。送り手は参加者を認識したら、持続的な誤りのない状態で始められるようにしなければならない。今のパケットを受信できることと、適切な初期状態を持つことは別である。
2017 年の RFC 8088 は、MIDI のような状態依存の強い記号的メディアに、要約された状態とフィードバックに基づく履歴の削減が役立つと説明した。この評価も、方式の設計上の特徴について述べたものであり、利用者数や市場での成功を測ったものではない。
登録された形式と、実際に聞こえた演奏
2011 年の改訂は 2006 年の形式を置き換え、図や構文などの誤りを修正した。著者たちがその修正対象に関する相互運用上の問題を把握していないと記したことは、すべての実装の正しさを認定する言葉ではない。同様に、文書中の当時の普及状況を、今の市場評価として引用すべきでもない。
IANA の audio/rtp-midi 登録 は、共通の名前、パラメーター、参照文書を提供する。それによって実装同士は形式を識別しやすくなるが、登録は演奏の遅延や回復結果を代わりに検査してくれない。
この仕組みの意味は、失った過去を全部取り戻すことではなく、過去の損失に現在を占領させないことにある。遅れた音を出さないという小さな判断には、リアルタイム通信の大きな限界が表れている。戻せるのは状態であって、同じ瞬間ではない。
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
