要約

  • codecs の省略は外側の申告がないことを示すだけで、Ogg 内にコーデック識別子を持つ論理ストリームがないとは示さない。
  • 申告、Skeleton、各ヘッダ、受信側能力、ストリーム別処理、最終表示を別々の証跡として扱う必要がある。

空欄がゼロ件に変換された

配信応答は audio/ogg だったが、codecs パラメータを含まなかった。資産管理は空欄を「コーデックなし」と正規化した。ところがファイルを開けば、音声とメタデータの論理ストリームがあり、それぞれの先頭ヘッダには識別子がある。

RFC 5334 において codecs は任意である。これは交渉や早期選別のために内部識別子を外へ持ち上げる方法であって、内部事実そのものではない。省略された申告から空のコンテナを推論することはできない。

この誤りは、未観測を否定に変える典型である。後段のシステムは「コーデックなし」という確定値を信じ、解析を省き、未知ストリームを保存せず、障害時にはデータが存在しなかったと報告する。最初にあったのは情報不足だけだった。

メディア型は主用途を選ぶ

RFC 5334 は Ogg を三つの用途へ整理する。複雑な多重化信号には application/ogg、視覚インターフェースを必要とする素材には video/ogg、音声が中心なら audio/ogg を使う。歌詞、メタデータ、カバー画像があっても音声中心という判断は維持できる。

したがって型名は内部ストリームの完全な列挙ではない。映像型に音声や時限テキストが含まれ、音声型に視覚的な補助素材が含まれる。外側の型は最初のハンドラを選ぶには有用だが、何を削除してよいかを決める権限にはならない。

application/ogg も「何でもよい」という意味ではない。複雑な構成を識別できるよう Skeleton が要求される。分類が広いほど、内部構造を曖昧にしてよいのではなく、むしろ明示的な在庫が重要になる。

Skeleton とヘッダは異なる観測面

Ogg の一つの物理ビットストリームは複数の論理ビットストリームを多重化できる。Skeleton は各ヘッダを先にデコードしなくても内容を識別するための目録を与える。application/ogg では必須、映像型と音声型では推奨である。

Skeleton がなければ何も存在しない、とはならない。特に audio/ogg と video/ogg では、実際の論理ストリームの先頭ページを調べる必要がある。反対に Skeleton があっても、その記載を処理できるデコーダがローカルにあるとは限らない。

外側の codecs、Skeleton の記述、実ヘッダの識別子は比較できる別々の証拠である。三者が一致すれば宣言整合性が高まる。一致しても、デコード成功や完全な提示までは証明しない。

未知ストリームを無視する設計

RFC 5334 は、識別した論理ストリームをデコードできない場合、それを無視し、理解できるストリームのデコードを続けることを推奨する。将来の拡張が古い受信機で全体停止を起こさないための互換性である。

この動作を単純な成功に丸めると、失われた機能が見えない。主音声が再生されても、字幕、ナビゲーション、同期情報、あるいは製品が必須とする補助データが消えた可能性がある。用途ごとに必須ストリームを定義し、各処理結果と照合すべきである。

一方、未知ストリーム一つを理由に全ファイルを不正とするのも RFC の一般原則ではない。厳格なアーカイブなら全保存を要求できるが、それはローカル方針であり、メディア型から自動的に導かれる結論ではない。

OggS と拡張子は能力表ではない

三種類は同じ OggS キャプチャパターンを共有する。これは Ogg ページらしさを示すだけで、主用途、論理ストリーム一覧、完全性、真正性、再生結果を示さない。全ファイルに同じ魔法値があるからこそ、そこから内部差を推論できない。

拡張子も同様である。RFC 5334 が複雑な用途に .ogx を勧めた背景には、歴史的な .ogg を Vorbis 音声だけだと期待する実装があった。拡張子は互換性の信号だが、解析結果ではない。名前を変えても中のストリームは変わらない。

Ogg 自体は汎用の署名や暗号化を提供しない。保護された内容を収容したり外部で保護したりはできるが、由来、許可、安全性は別の証拠で判断する。認識できるコンテナであることは、実行可能内容を動かす承認ではない。

情報源と証拠の限界

以下は標準、登録、後続仕様の事実を支える。現在の製品、ファイル、デコーダ、脆弱性、普及率、再生結果は証明しない。