ビデオと字幕 · 字幕ツールキット
字幕ファイルの「クリーニング」の意味: タグ、コード、および野良フォーマット
· 仕組み
字幕 テキスト処理 ファイル形式
字幕ファイルには、HTML のようなタグ、他の形式のスタイル コード、迷走 BOM、および混合行末などのジャンクが収集されます。この記事では、それぞれの種類の乱雑さの意味、それがどこから来るのか、そして単語に触れずにクリーンな手順でどのように除去するかを説明します。
画面上にキャプションに「{\an8}」と「<i>」が表示される - 汚れた字幕ファイルの目に見える症状
キャプションがタグに従わずにタグの文字を表示する場合、プレーヤーはそのマークアップを実装していないことを示しています。 SRT には書式設定の仕様がないため、サポートは従来どおりです。多くのプレーヤーは HTML のようなタグの小さなセットを尊重し、そのセットの外にあるものはすべてリテラル テキストとして描画されます。あるプレーヤーでは正しくレンダリングされ、別のプレーヤーでは中括弧が表示されるファイルは変更されていません。尊重されるタグのセットのみが持っています。
これが、掃除が表面的な整理整頓ではなく実際の作業である理由です。散らかっているのは、たまたま醜い装飾ではありません。これは、ある形式向けに書かれた指示を別のプレイヤーがダイアログとして読み取るもので、修正方法は、すべての単語をそのままにして指示を削除することです。
乱雑さの原因 — スタイルを多用した形式、OCR 出力、および独自のマークアップを追加するエディターからのエクスポート
ほとんどの混乱は変換を通じて発生します。 ASS や SSA などのスタイル重視の形式で作成されたファイルには、位置決めと外観のディレクティブがインラインで含まれており、タイミングを忠実にマップするコンバーターは多くの場合、これらのディレクティブをテキストとして渡します。キャプション編集者は、話者の識別と強調のために独自のマークアップを追加し、焼き付けられた字幕の光学式文字認識により、作者が入力したことのない句読点や二重スペースが発生します。
これらのソースはいずれも、独自の世界では不正な形式ではありません。 ASS オーバーライド ブロックは ASS で意味を持ちます。問題は、SRT には同等のものが存在しないため、ロスレスの変換により、命令が動作としてではなく文字として残るファイルが生成されることです。
タグの書式設定 — イタリック体、太字、およびフォントのタグ。どのプレイヤーがそれらを尊重し、文字通りに表示するか
山かっこタグは、小なりと次の大なりの間のすべてを削除する正規表現を使用して最初に処理されます。これには、斜体および太字のタグ、キュー クラスの注釈などの WebVTT クラス タグ、および話者に名前を付ける音声タグが含まれます。重要な特性は、これが HTML パーサーではなくテキスト置換であり、開始タグと終了タグを一致させようとしないことです。
このシンプルさには、知っておく価値のあるコストが伴います。不等号の発話など、実際に「より小さい」と「より大きい」が含まれる対話行では、それらの間のテキストが括弧とともに削除されます。これは対話ではまれで、技術的なキャプションでは一般的であるため、コードや数学について説明する資料のクリーニング パスの出力をスキャンする価値があります。
コードの配置とスタイル — ASS/SSA における {\an8} のようなコードの意味と、SRT におけるノイズとなる理由
中括弧コードは、左中括弧と右中括弧の間のすべてをカバーする 2 番目の置換によって削除されます。 SubStation 形式では、これらはオーバーライド ブロックであり、最も頻繁に見られるのは、焼き付けられたテキストと衝突しないようにフレームの先頭に行を移動するブロックです。フォント、色、回転、カラオケのタイミングを設定するものもあります。
SRT ファイルでは、これらは何も意味を持たないため、翻訳されずに削除されます。位置ディレクティブには、変換に相当する SRT がありません。この形式では単に配置が行われません。コードを削除すると、その行をフレームの先頭に配置するという作成者の意図が失われ、その喪失は現実のものですが、コードを閲覧者に表示するよりも望ましいです。
目に見えない乱雑さ - バイト オーダー マーク、CRLF と LF の混在した行末と末尾のスペース
目に見えない乱雑な部分は、解析中に早い段階で処理されますが、テキストの一部ではないため、分離する価値があります。ファイルの先頭にあるバイト オーダー マークは、他のものよりも先に削除されます。そうしないと、最初のインデックス番号に付加され、最初のキューが消費されるためです。 Windows ペアと単独の復帰の両方で復帰が正規化されるため、2 つのプラットフォームで編集されたファイルはブロックに正しく分割されます。
キュー内の空白はタグで処理されます。 2 つ以上のスペースまたはタブの連続は 1 つのスペースに折りたたまれ、すべての行が個別にトリムされ、行が再結合された後にキュー全体がトリムされます。文字エンティティは意図的にそのまま残されています。アンパサンド エンティティは、マークアップではなく、視聴者が見るべきコンテンツであり、アンパサンド エンティティをデコードするクリーナーは、命令を削除するのではなく、ダイアログを編集することになります。
動作例: 200-cue エクスポートのクリーニング - 何が変更され、何が残り、結果を確認する方法
大規模なエクスポートをクリーニングしても、見た目よりも変化は少なくなります。 200 個のキュー ファイルを例に挙げます。このファイルでは、コンバータがフレームの先頭コードに 60 個のキューを接頭辞として付加し、さらに 40 個のキューの周りに強調タグをラップしています。 2 つの置換によってコードとタグが削除され、空白パスによって削除によって残された 2 倍のスペースが縮小され、200 個のキューが同じ単語と同じタイミングを持つ 200 個のキューになります。
さらに 2 つのステップが重要です。コンテンツ全体が野良コードだったキューは、コードがなくなると空になります。空のキューは、空のブロックとして出力されるのではなく、別のパスで削除されます。これは、タイムスタンプがありテキストのないキューは、一部のプレーヤーがフラッシュとしてレンダリングするギャップであるためです。ファイルを書き戻すと、キューの番号が 1 から付け直され、キューが連続した状態に保たれるため、削除によってシーケンスに穴が残らないようになります。キュー数を比較し、元々エンティティが含まれていた行をスポットチェックして、結果を確認します。
これでカバーされないもの — テキスト自体、スペルまたは翻訳の書き換え。言葉はあなたのものです
クリーニングではマークアップが削除されますが、言語には影響しません。スペルの修正、略語の拡張、転写エラーの修正、翻訳は行われません。キャプションに間違った単語が表示されると、その後、正しい形式で間違った単語が表示されます。この境界線は意図的なものです。会話を黙って書き換えるツールを、理解できない内容に関して信頼することは不可能です。
また、構造は修復されません。ブロックにタイムスタンプが含まれていないファイルには、フォーマットの問題ではなく解析の問題があり、ファイルからタグを削除してもキューは生成されません。エンコーディングエラーも同様に対象外です。間違った文字セットでデコードされたファイルは、テキストが間違っている完全に整形式のキューを生成しますが、構造が何も壊れていないため、いくらタグを削除してもそれは検出されません。
要点: マークアップを削除し、意味を保つ — 字幕ツールキットのクリーンなステップが一般的な混乱をどのように処理し、放置されているものを文書化するかを説明します。
ルールはマークアップを削除し、意味を保持することです。山括弧タグと中括弧コードは、プレーヤーが無視するか出力する指示であるため、使用されます。二重スペースと行ごとのパディングは、削除または元のエクスポートのアーティファクトであるため、削除されます。エンティティ、句読点、すべての単語は残ります。それは、視聴者が読むことを意図しているものだからです。
字幕ツールキット コンバーターを使用してタグを多く含むエクスポートを実行し、出力を一目で信頼するのではなく、オリジナルと比較します。キューが本当に空だった場合を除いてキューの数が変わっていないことを確認し、エンティティを含む行にエンティティがまだ含まれていることを確認し、コードや数学について説明している行をスキャンして、山かっこで失われたテキストのテキストを調べます。