ビデオと字幕 · 字幕ツールキット
SRT および VTT 以降: ASS、TTML、DFXP、および SCC 字幕が使用されます。
· 背景
字幕 ファイル形式 srt webvtt
SRT と WebVTT が Web を支配していますが、放送、アニメ ファンダム、ストリーミング配信では他の形式が使用されています。この記事では、状況をマッピングし、それぞれの形式が何のためにあるのか、また、焦点を絞ったツールキットがそのうちの 2 つだけをサポートしている理由について説明します。
プレーヤーが認識しない拡張子でいっぱいのフォルダー — プロのキャプション作業における形式の多様性
ローカリゼーション ハンドオフには、画面上に単語を表示し、内部構造をほとんど共有しないファイルが含まれる場合があります。単純なキュー リストもあれば、XML ドキュメント、詳細なスタイルを保持するもの、従来のブロードキャスト キャプション ストリームをエンコードするものもあります。見慣れない拡張機能をすべて「別の SRT」として扱うと、送信者がそれを選択するきっかけとなった機能が削除される危険があります。
最初の優先順位の問題は、どのコンバータがファイルを開くかではなく、そのファイルがどの配信システムに属しているかです。オリジナルを保存し、要求された宛先を特定し、その形式を理解するパーサーを使用します。 Subtitle Toolkit は、SRT と WebVTT のみを明示的に読み書きします。これは、普遍性の約束が果たされていないというよりも、境界です。
ASS および SSA — アニメ ファンサブの伝統に基づいたスタイルと位置の字幕
SSA とその後継の ASS は、メタデータ、再利用可能なスタイル、および時間指定されたダイアログ イベントのセクションを備えたスクリプト スタイルの字幕形式です。通常のSRTを超えた位置や見た目を表現できます。これらは、アニメのファンサブを含む、豊富なスタイルのコミュニティ サブタイトル ワークフローと強く関連付けられていますが、それらの関連付けは、すべての ASS ファイルをファンサブに変換したり、そのライセンスを定義したりするわけではありません。
SubStation 形式の中括弧で区切られたオーバーライド コマンドは、未加工の変換後も表示テキストとして存続することがあります。 ToolAcre のクリーンアップでは、位置決めオーバーライドなどのブロックをキュー テキストから削除できますが、ASS スクリプトの解析、スタイルの変換、カラオケや描画の動作の保持は行いません。プレーンテキストの派生ファイルをここに持ち込む前に、ASS 対応ツールで変換してください。
TTML および DFXP — ブロードキャストおよびストリーミング配信用の XML ベースのタイミング テキスト
TTML は、タイミング付きテキストを XML として表し、構造、名前空間、タイミング、およびプレゼンテーション情報を一緒に送信できるようにします。 DFXP は、同じタイムテキスト ファミリと、それを中心に構築された配信ワークフローで使用される名前です。これらのドキュメントは空行キュー ブロックではないため、SRT パーサーは矢印を検索して安全にドキュメントを回復できません。
ブロードキャストおよびストリーミング システムは、ブロード フォーマットよりも要件が狭い TTML ファミリ プロファイルを選択する場合があります。この記事では、.ttml または .dfxp ファイルごとに 1 つのプロファイル、標準バージョン、またはプラットフォーム マッピングを主張するものではありません。配信仕様が権限であり、変換では宛先が結果を受け入れて表示するまでマスターを保存する必要があります。
SCC および CEA-608 — 一部の配信者が依然として必要としている放送字幕のレガシー
SCC ファイルは、人に優しい SRT ブロックのリストではなく、CEA-608 データに関連付けられた放送字幕系統を表します。その内容と制約は、Web サイドカー テキスト以前のキャプション コマンドと送信モデルを反映しています。 SCC を要求するディストリビュータは、異なるサフィックスを持つ SRT ファイルではなく、その配信表現を要求しています。
リポジトリ ツールは SCC を読み取らず、CEA-608 をエンコードしません。また、放送局の適合性も検証しません。ソース キャプション プロジェクトを保持し、要求されたブロードキャスト ワークフロー用に設計されたソフトウェアを使用します。 SRT または WebVTT にエクスポートするのは、別の宛先がこれらのファイルのいずれかを実際に呼び出す場合のみです。
SBV、LRC など - プラットフォーム固有のニッチなフォーマット
SBV はプラットフォームのキャプション ワークフローで使用されますが、LRC は時間指定された歌詞によく使用されます。他の拡張機能は、タイミング、スタイル、または特定のアプリケーションに関するさらに多くの仮定をエンコードします。句読点、順序、およびメタデータによってパーサーがファイルを読み取る方法が決定されるため、時間とテキスト行の表面的な類似性だけでは、それらを交換可能にするのに十分ではありません。
この記事では、網羅的なレジストリを提供したり、1 つのサービスが常に 1 つの形式を受け入れると主張したりするものではありません。プラットフォームのサポート変更とプロフェッショナルな提供は契約に基づいています。特に変換によりレイアウトやスタイルが必然的に破棄される場合は、現在の変換先のドキュメントを読み、元のファイルを保持してください。
ツールキットが SRT と WebVTT のみを選択する理由 — Web の交換形式、およびその制限を文書化する誠実さ
焦点を当てたブラウザ ツールキットは、その変換モデルがキュー テキスト、開始ミリ秒と終了ミリ秒、およびオプションの設定文字列であるため、SRT と WebVTT を選択します。このモデルは、これら 2 つの形式の共通ブロック構造に直接マッピングされます。これには XML ツリー、再利用可能なスタイル シート、ブロードキャスト コマンド ストリーム、埋め込みビデオ トラックが含まれていないため、これらをサポートしているふりをすると、情報が黙って平坦化されてしまいます。
この制限はコンバーター レコードに記載されています。ASS および SSA、TTML、SAMI、およびコンテナーに埋め込まれたキャプションは処理されません。 WebVTT 内でも、NOTE、STYLE、REGION ブロックはスキップされます。正直なスコープにより、ユーザーはエクスポート後に特殊な機能が消えたことを発見するのではなく、損傷する前に停止できます。
要点: 地図を知ってからツールを選ぶ — 字幕ツールキットが風景の SRT と WebVTT 部分をどのようにカバーするか
マップを把握し、マスターを保存し、要求された目的地を理解するツールを選択します。 Subtitle Toolkit は、SRT と WebVTT の部分、つまり寛容なキュー解析、正規シリアル化、タイミング変更、テキストのクリーンアップ、構造検証をカバーしています。これはユニバーサルな字幕交換エンジンではないため、サポートされていない形式の名前を変更して安全な入力に変換することはありません。
専門アプリケーションがレビュー済みの SRT または WebVTT 派生物をすでに作成している場合は、その派生物をここにロードし、変換前にキュー数と問題を検査します。 ASS、TTML、SCC、またはその他のマスターをそばに置いて、失われたスタイルや配信メタデータを推測するのではなく追跡できるようにします。