音は流れているのに無音になる
副調整室のスピーカーは正常に鳴っていた。だが配信画面に切り替えた瞬間、視聴者コメント欄が「音が出ません」の一言で埋まった。時刻は本番開始から4分後だった。
この事故の厄介さは、卓のオペレーターには何も見えていなかった点にある。モニターミックスは別の経路から音を取っていたため、実際に配信されているIP出力の音声ストリームだけが無音になっていることに、誰も気づけなかったのだ。
「音が出ない」という一言は、現場では原因がまったく違う3つの状態を一括りにしてしまう。ここを分けずに対処すると、正しい原因にたどり着くまでに本番時間を無駄に食われる。
IPで音声を送るとき、無音になる経路は3つしかない。まず、パケットそのものが届かなくなる「伝送断」。次に、パケットは正常に届いているのに中身の音量がゼロに近い「信号無音」。最後に、正しい音は存在しているのに別のフローやチャンネルに入ってしまっている「経路誤り」だ。
RTPのシーケンス番号は16ビット、つまり0から65535までしか数えられない（RFC 3550）。AES67・SMPTE ST 2110-30のレベルAでは1パケットあたりの時間は1ミリ秒で、48kHzサンプリングなら1パケットに48サンプルが入る（AIMS Alliance「AES67-SMPTE ST2110 Commonalities and Constraints」2019年版）。つまり1秒間に1000パケットが流れる計算になり、シーケンス番号は65.536秒ごとに一巡する。この一巡を考慮せずに単純な差分比較でロス検知ロジックを書くと、65秒に1回誤検知が起きる設計ミスに直結する。
一方、レベルB・Cのように125マイクロ秒パケットタイムを使う場合は、1秒間に8000パケットが流れ、シーケンス番号は8.192秒ごとに一巡する。同じロジックのまま伝送プロファイルだけ切り替えると、誤検知の頻度が8倍に増える。ここを知らずに複数拠点で異なるプロファイルを混在させている現場は珍しくない。
無音の原因を切り分けるコツは、水道の比喩で考えると腹に落ちる。水道の水が出ない理由は3つしかない。水道管そのものが破裂して水が来ていない場合、水道管はつながっているが元栓が閉まっている場合、そして水は来ているのに配管ミスで別の部屋に流れている場合だ。IP音声の無音もまったく同じ構造をしている。ネットワークを疑う前に、まずこの3つのどこで止まっているかを見極める必要がある。
対処法は存在する。伝送断はシーケンス番号とタイムスタンプの連続性を見れば分かる。信号無音はパケットの中身、つまり実際のPCMサンプル値のレベルを監視しないと分からない。経路誤りはフロー単位のルーティング状態と実際の出力を突き合わせないと発見できない。3つの監視ポイントをそれぞれ別の技術で持つ設計を組めば、次に同じ事故が起きたとき、原因の見当を数十秒でつけられるようになる。
この記事の有料部では、3つの監視ポイントをどう実装するかをステップごとに解説する。伝送断検知のしきい値設計、信号無音を判定する具体的なdBFS値と持続時間の組み方、そしてチャンネルマッピング誤りを本番前に発見するチェック手順まで、実務でそのまま使える形で示す。あなたの現場のシステムに、今日から組み込める監視項目を持って帰ってほしい。
この設計を知らないまま本番を迎えると、無音事故の原因調査だけで貴重な数分を失う。副調整室のスピーカーが鳴っているという理由だけで「大丈夫」と判断してしまう事故は、送出系統を分けて監視していない限り何度でも繰り返される。次の現場で同じ事故を防ぐ具体的な手順が、この続きにある。
コメント