(57)【要約】【課題】高速な字幕作成及び様々な種類のデータ・シーケンスを配列するためのシステム及び方法を提供すること。【解決手段】一実施形態において、本システムは、ユーザからのパラメータ値を受信するように適応される入力モジュールと、格納されるパラメータが少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付けるようにパラメータを格納するように適応されるコンピュータ可読メモリと、少なくとも一つの特徴をデータ・シーケンスから抽出して当該データ・シーケンスから抽出された少なくとも一つの特徴に基づいてパラメータを調節するように適応される解析モジュールと、を含む。代替実施形態において、本システムは、ユーザが指定した時刻を事前データとして扱い、同時並行の及び以前に解析したデータ・ストリームから抽出される特徴を用いて、当該時刻を調節する。【選択図】図１
2010509859.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに対して関連付けるパラメータを更新する、コンピュータに実装される方法であって、
ユーザからパラメータ値を受信するステップと、
前記コンピュータに通信可能に接続されたメモリに前記パラメータを、格納される前記パラメータが少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付ける様式で、格納するステップと、
前記データ・シーケンスから少なくとも一つの特徴を抽出するステップと、
前記データ・シーケンスから抽出した前記少なくとも一つの特徴に基づいてパラメータを調節するステップと、を含む方法。
【請求項２】
ユーザから前記パラメータ値を受信するステップは、前記データ・シーケンスの表現を提示するステップを、さらに含む、請求項１に記載の方法。
【請求項３】
ユーザから前記パラメータ値を受信するステップは、前記イベントの表現を提示するステップを、さらに含む、請求項２に記載の方法。
【請求項４】
少なくとも一つの特徴を抽出するステップは、前記ユーザに情報を提示するために前記データ・シーケンスをフィルタリングするステップを、さらに含む、請求項２に記載の方法。
【請求項５】
前記パラメータ値を受信するステップは、コンピュータ可読媒体に保存されたパラメータ群を受信するステップを含む、請求項２に記載の方法。
【請求項６】
ビデオ・ビュー及びスクリプト・ビューの少なくとも一部としてのコンピュータ実行可能コードを含む、テキスト・データ・ストリームを実行するステップを、さらに含む、請求項３に記載の方法。
【請求項７】
リアルタイムに調節されたパラメータに応答して、前記ビデオ・ビューの前記提示を調節するステップを、さらに含む、請求項６に記載の方法。
【請求項８】
前記パラメータを受信するステップは、（１）前記データ・シーケンスの前記表現のいずれかの部分におけるマウスクリック、（２）前記データ・シーケンスの前記表現のいずれかの部分におけるマウスドラッグ、（３）キーの押下、及び（４）キーの解放の、少なくとも一つの形式においてパラメータを受信するステップを、さらに含む、請求項３に記載の方法。
【請求項９】
少なくとも一つの特徴を抽出するステップは、（１）前記データ・シーケンスの同時平行するストリームから特徴を抽出するステップ、及び（２）前記データ・シーケンスの以前に解析されたストリームから特徴を抽出するステップの少なくとも一つを、さらに含む、請求項４に記載の方法。
【請求項１０】
前記データ・シーケンスをフィルタリングするステップは、パーセバル（Ｐａｒｓｅｖａｌ）の関係及び窓関数を用いて前記データ・シーケンスにおけるエネルギーに基づく時間を算出するステップを、さらに含む、請求項４に記載の方法。
【請求項１１】
前記イベントは、（１）テキスト・アイテム、（２）オーディオ・イベント、及び（３）ビジュアル・イベントの少なくとも一つを含む、請求項３に記載の方法。
【請求項１２】
前記データ・シーケンスは、（１）オーディオ・シーケンス、（２）ビデオ・シーケンス、及び（３）テキスト・シーケンスの少なくとも一つを含む、請求項２に記載の方法。
【請求項１３】
前記パラメータの少なくとも一つは、前記シーケンスに対応する媒体時間である、請求項３に記載の方法。
【請求項１４】
（１）オリジナルの順方向再生シーケンス、（２）逆方向再生シーケンス、及び（３）相互の同期の少なくとも一つにおいて、前記ユーザに前記データ・シーケンスを提示するステップを、さらに含む、請求項１２に記載の方法。
【請求項１５】
第一のデータ・シーケンスに第二のデータ・シーケンスを非同期に提示するステップを、さらに含み、前記第一のデータ・シーケンス及び前記第二のデータ・シーケンスは、（１）異なる速度において、及び（２）別のデータ・シーケンスとは異なるオフセットにおいて提示される、請求項１２に記載の方法。
【請求項１６】
前記データ・シーケンスをフィルタリングするステップは、（１）前記データ・シーケンスから場面の境界を検出すること、（２）話声の境界を検出すること、（３）前記イベントの前記パラメータを所定の最小限の基本的分離に最適に分離すること、（４）前記ユーザの遅延又は前進した反応に基づいて前記パラメータを遅延させること、及び（５）前記ユーザの遅延又は前進した反応に基づいて前記パラメータを前進させることの少なくとも一つを、さらに含む、請求項４に記載の方法。
【請求項１７】
場面の境界を検出するステップは、ビデオ・キー・フレームを検出するステップを、さらに含む、請求項１５に記載の方法。
【請求項１８】
前記メモリに動作可能に接続される手段を介し、一以上の前記パラメータに基づいて、前記イベント及びデータ・シーケンスを表す識別情報（ｉｎｄｉｃｉａ）を前記ユーザに通信するステップを、さらに含む、請求項３に記載の方法。
【請求項１９】
前記識別情報に応答して、前記ユーザから追加パラメータ値を受信するステップを、さらに含む、請求項１７に記載の方法。
【請求項２０】
少なくとも一つのハードウェア装置の手段によって、前記ユーザに、（１）前記イベント、（２）前記データ・シーケンス、（３）前記方法によって生成される中間結果、及び（４）前記パラメータに対する変更の、少なくとも一つを提示するステップを、さらに含む、請求項１７に記載の方法。
【請求項２１】
電子機械装置の手段によって、前記ユーザから前記パラメータを受信するステップを、さらに含む、請求項１７に記載の方法。
【請求項２２】
少なくとも一つの特徴を抽出するステップは、前記データ・シーケンスのフローを同期するために前記データ・シーケンスをフィルタリングするステップを、さらに含む、請求項６に記載の方法。
【請求項２３】
少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付けるパラメータを更新するためのシステムであって、
ユーザからパラメータ値を受信するように適応される入力モジュールと、
コンピュータ可読メモリであって、前記コンピュータに通信可能に接続され、前記パラメータを格納するように適応され、前記格納されるパラメータは少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付ける、コンピュータ可読メモリと、
前記データ・シーケンスから少なくとも一つの特徴を抽出し、前記データ・シーケンスから抽出された前記少なくとも一つの特徴に基づいて前記パラメータを調節するように適応される解析モジュールと、を含む、システム。
【請求項２４】
前記入力モジュールは、（１）ビデオ・ビューを用いて前記データ・シーケンスの表現を提示し、（２）スクリプト・ビューを用いて前記データ・シーケンスの表現を提示し、及び（３）前記ユーザからの入力を受信するために前記スクリプト・ビューを介してメニューを提示するように、適応される提示モジュールを、さらに含む、請求項２３に記載のシステム。
【請求項２５】
ユーザから前記パラメータ値を受信するステップは、前記データ・シーケンスの表現を提示するステップを、さらに含む、請求項２３に記載のシステム。
【請求項２６】
ユーザから前記パラメータ値を受信するステップは、前記イベントの表現を提示するステップを、さらに含む、請求項２５に記載のシステム。
【請求項２７】
少なくとも一つの特徴を抽出するステップは、前記ユーザに情報を提示するために前記データ・シーケンスをフィルタリングするステップを、さらに含む、請求項２５に記載のシステム。
【請求項２８】
実行時に、少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付けるパラメータを、更新するための方法を実行する、コンピュータ可読命令を格納するコンピュータ可読媒体であって、前記方法は、
ユーザからパラメータ値を受信するステップと、
前記コンピュータに通信可能に接続されたメモリに前記パラメータを、前記格納されるパラメータが少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付ける様式で、格納するステップと、
前記データ・シーケンスから少なくとも一つの特徴を抽出するステップと、
前記データ・シーケンスから抽出した前記少なくとも一つの特徴に基づいてパラメータを調節するステップと、を含む、コンピュータ可読媒体。
【請求項２９】
ユーザから前記パラメータ値を受信するステップは、前記データ・シーケンスの表現を提示するステップを、さらに含む、請求項２８に記載のシステム。
【請求項３０】
ユーザから前記パラメータ値を受信するステップは、前記イベントの表現を提示するステップを、さらに含む、請求項２９に記載のシステム。
【請求項３１】
少なくとも一つの特徴を抽出するステップは、前記ユーザに情報を提示するために前記データ・シーケンスをフィルタリングするステップを、さらに含む、請求項２９に記載のシステム。
【請求項３２】
少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付けるパラメータを更新するためのシステムであって、
ユーザからパラメータ値を受信し、前記データ・シーケンスの表現を提示するように適応される入力モジュールと、
コンピュータ可読メモリであって、前記コンピュータに通信可能に接続され、前記パラメータを格納するように適応され、前記格納されるパラメータは少なくとも一つのイベントを少なくとも一つのデータ・シーケンスに関連付ける、コンピュータ可読メモリと、
前記データ・シーケンスから少なくとも一つの特徴を抽出し、前記データ・シーケンスから抽出された前記少なくとも一つの特徴に基づいて前記パラメータを調節するように適応される解析モジュールであって、前記少なくとも一つの特徴を抽出することは、前記ユーザに情報を提示するために前記データ・シーケンスをフィルタリングすることをさらに含む解析モジュールと、を含む、システム。
【請求項３３】
ユーザから前記パラメータ値を受信することは、前記イベントの表現を提示することを、さらに含む、請求項３２に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願への相互参照）
本出願は、２００６年１１月５日出願の米国特許仮出願第６０／８６４４１１号、発明の名称「高速字幕作成のためのシステム及び方法」、及び２００６年１１月１４日出願の米国特許仮出願第６０／８６５８４４号、発明の名称「高速字幕作成のためのシステム及び方法」に基づいて優先権を主張し、両者は全体を参照により本願明細書に援用する。
【０００２】
（技術分野）
本出願は、概して、コンピュータに実装されたマルチメディア・データ処理システムに関し、より具体的には、字幕及びさらなる一連のデータを伴う他のシーケンス等のイベントを生成、変更、配列、提示するためのシステム及び方法に関する。
【背景技術】
【０００３】
従来の字幕作成システムは、タイミング処理期間における非効率的労力に適切には対処しないため、本願明細書に記載のシステムの実施形態が求められている。従来技術に関する市販の字幕作成システムは、小規模で限定的なユーザ基盤を有し、主要には大きな放送設備の一部である。その費用及び複雑さは、ファン、研究者、フリーランス翻訳家の手の届くものではない。放送業界には、こうした市販システムが、オープンソース及びフリーウェア対応品よりも不安定であると主張する人もいる。
【０００４】
さらに、ユニコード（登録商標）、言語選択、共同翻訳、多言語フォント選択、又はテキストのスクロール等の“ｉｌ８ｎ”（国際化）機能を、完全に実装する公知のシステムはない。過剰な字幕作成ソフトウェアにより、字幕テキストに対する何百もの異なるファイル・フォーマットが発生した。
【０００５】
図１に示すように、従来技術に係る字幕作成ソフトウェア・システム１０は、ハードウェアによってキャラクタ・ジェネレータをロックする装置（ｇｅｎｌｏｃｋｓ、ジェンロック）に対するワークフローに基づく。市販システムの基本は、これと同じワークフロー及びジェンロック装置に基づいている。しかしながら、このワークフロー及びジェンロック装置用の技術は、全デジタル・ワークフローにより、約５年前に陳腐化した。こうしたツールを用いるならば、２５分のビデオ・シーケンスに字幕を作成すると、概算で４時間も要する可能性がある。
【０００６】
図１に示すように、従来技術に係るリニア・タイムライン・レイアウト１２は、その実装において簡単ではあるが、いくつかの欠点がある。まず、プレビュー／グリッド・サイズ領域は、字幕及びオーディオ波形に対する両者のプレビュー・ウィンドウの役割であるため、編集中には字幕の全てを見ることはできない。キーボード・ショートカットは扱いにくいか又は非機能的であり、波形プレビューの動作は、クリックにより時間を更新するときもあるが、そうならないときもあり、一貫性がない。最終的には、字幕は、表を下降する順序で単一ファイルに配列され、作者、キャラクタ、又はスタイルによる字幕の体系化又はフィルタリングの試みはなく、一度に複数の字幕セクションを一覧するオプションはない。図２から図３に示す、第二の従来技術に関連するシステム２０等の、他の従来技術に係るシステムは、レイアウト、多言語サポート及びビデオ・プレビュー・ウィンドウを変化させた機能セットを開示しているが、これらのシステムも同様に、同一又は同様の欠点を有している。例えば、オーディオ・タブ２２（図２）、ビデオ・タブ２４（図３）のいずれで動作しても、第二の従来技術に係るシステム２０は、リアルタイムにおけるレンダリングやビューは許容していない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
字幕付きの作品にトランスクリプト及び音声画像シーケンスを結合すると、話声の境界検出、音声学的音声配列、ビデオの場面の境界認識、キャラクタ（俳優又は話者）認識という、様々な別個の問題領域が発生する。
【０００８】
音声認識及び合成については、膨大な量の言語資料が研究されてきた。音声学的配列は、この広範なカテゴリーに該当し、こうした音声学的配列に対処する数多くのシステムが存在している。最近の他の業績としては、認識システムの能力の範囲に限界がある場合に対して、字幕作成システムが実装可能であることが示唆されている。
【０００９】
日本語は、この領域における顕著な複雑さを多く有している。音声学的配列のためのほとんどのシステムは、空想映画における日本語や他の言語の無限に近い言語資料よりも、むしろ限られた英語の言語資料に対して試験されてきた。日本語においては、英語よりも音節が少ない場合があり（日本語は、韻律単位（モーラ）又は音節ユニットが英語よりも少ない）、日本語は英語よりも速く話される傾向がある。さらに、音声学的配列のルーチンは、現実世界のメディア・クリップにおける複雑でノイズの多い波形を扱いがちである。本課題における文献では、研究者は、ほとんど常に、自分のシステムに対する入力データとして、単一で他に邪魔のない話者を設ける。音楽、効果音、及び他の話者を含むオーディオ・ストリームを用いることは、アルゴリズムとしての大きな挑戦であると言える。
【００１０】
同様に、日本のアニメーションは、発声の種類の少ない多様なキャラクタが登場する傾向がある。話者の間の多様性が小さいと、配列ルーチンが混乱する場合があり、類似した発声の２人が連続して又は同時平行して話していると、話者変化の検出を妨げる場合がある。字幕領域におけるトランスクリプト及び翻訳には、キャラクタ名により予めラベル付けが行われるが、これは部分的な解決にすぎない。キャラクタは事前に公知であるため、話声の署名検出を、所与の公知の良好なタイミングを付加された字幕と協動させることにより、分類アルゴリズムによって、これらの公知のサンプルからオーディオ・データを抽出し、未知のどの領域が所与のキャラクタと対応するか、別のキャラクタと対応するか、又はどのキャラクタにも対応しないかを決定することが可能であると考えられる。
【課題を解決するための手段】
【００１１】
高速な字幕作成及びデータ・シーケンス配列のためのシステム及び方法の様々な実施形態を、本願明細書に記載する。本願明細書に開示の本システムの実施形態は、字幕を作成する又は画面上にテキストを配置するユーザに、非常に時間を節約する結果を与える。このような高速字幕作成システムの実施形態は、他の字幕作成システムと比較して、ユーザが消費する字幕作成時間を短縮する。
【００１２】
とりわけ、本願明細書に開示の本システムの一実施形態は、全体として時間の節約を達成する三つの課題領域、すなわち、タイミング、ユーザ・インタフェース、及びフォーマット変換を課題とする。具体的には、本実施形態は、イベントにタイミング（字幕を含む）を設定するための、又は後の再生に対して画面上において字幕がいつ出現又は消失（他の種類のデータに対しては有効化及び無効化）するかを特定するための、新規なフレームワークを実装する。
【００１３】
同様に、本字幕作成システムの別の実施形態は、正確な字幕の時刻を迅速に生成して割り当てるために、ユーザの入力と組み合わせて、字幕、オーディオ、及びビデオ・ストリームに由来するパラメータを用いる、オンザフライ方式のタイミング設定システム及びパッケージ化アルゴリズム・サブシステムを含む。本字幕作成システムの実施形態を用いることにより、字幕作成者等のユーザは、可読性やスクリーン上のテキストの視覚的外観を向上するよう文字を編集することが可能である。さらに、ユーザは、本字幕作成システムのモジュール式シリアライゼーション・フレームワークを用いて、数多くのフォーマットの字幕を用意し、処理することもできる。
【００１４】
添付の特許請求の範囲は、本願明細書において具体的に開示されている、高速な字幕作成及び様々な種類のデータ・シーケンスの配列のための実施形態のシステム及び方法の特徴を示しているが、本システム及び方法の実施形態は、以下の詳細な記載を添付図面と組み合わせることにより、最もよく理解されると考えられる。
【図面の簡単な説明】
【００１５】
【図１】従来技術に係る、リニアなタイムラインを有する、第一の公知の字幕作成システムを示す図である。
【図２】従来技術に係る、第二の公知の字幕作成システムを示す図であり、第一の公知の字幕作成システムとは実装の詳細が異なる。
【図３】従来技術に係る、第二の公知の字幕作成システムの、別のビューを示す図である。
【図４】本字幕作成システムの実施形態の、上位レベルの概要を示す図である。
【図５】本願明細書に記載のオブジェクト、データ・フロー、及び観察サイクルを伴う、本字幕作成システムの実施形態を示す図である。
【図６】オンザフライ方式のタイミング・サブシステム及びパッケージ化アルゴリズムのサブシステムを含む、本字幕作成システムの実施形態を示す図である。
【図７】パッケージ化アルゴリズムのサブシステムのプリプロセッサ、プレゼンタ、及びアジャスタ・インタフェースの実施形態のプログラム・リストを示す図である。
【図８】本発明の実施形態におけるイベント（字幕）間の典型的な遷移を示す、文字又は注記に対応するイベント（字幕）を伴うタイムラインを、８Ａから８Ｈとして示す図である。
【図９Ａ】信号タイミング機能の中心的な開始、終了、及び隣接する信号の取り扱いの実施形態のコンピュータ・プログラム・リストを示す図である。
【図９Ｂ】信号タイミング機能の中心的な開始、終了、及び隣接する信号の取り扱いの実施形態のコンピュータ・プログラム・リストを示す図である。
【図１０】パイプライン・ストレージ２Ｄアレイ及びこのパイプライン・ストレージによる制御フローの実施形態を示す図である。
【図１１】本システムの実施形態における、パッケージ化アルゴリズムの調節期間の、オンザフライ方式のタイミング・サブシステムと、パッケージ化アルゴリズムのサブシステムとの間の動作及び相互作用のフローチャートを示す図である。
【図１２】本システムの実施形態における、ディスプレイ上に字幕スクリプトを伴う、スクリプト・ビューを示す図である。
【図１３】本システムの実施形態において、ビデオの再生を伴うビデオ・ビューを示す図である。
【発明を実施するための形態】
【００１６】
高速字幕作成システム１００の実施形態を、本願明細書に開示する。システム１００の実施形態は、オンザフライ方式でタイミングを設定するサブシステム、パッケージ化アルゴリズムのサブシステムを用い、適宜、以下の５つの特徴の組み合わせ、すなわち、プラットフォームの選択、スクリプト及びビデオ・ビューのユーザ・インタフェース、データ格納及び操作、ユニコードを介する国際化、並びに、ローカリゼーション及びリソースのタグ付けを含む。当業者であれば、パッケージ化アルゴリズムはオラクル又はソフトウェア・モジュールとしても知られていることを考慮する。
【００１７】
限定しないが、システム１００の実施形態は、プロフェッショナル、研究者、ファン、初心者の使用に適切である。通常は、ユーザが異なれば、異なる能力に対する必要性が重要となる。例えば、字幕作成を行うファンは、典型的には文字装飾及びアニメーション能力に関心があるが、字幕作成を行うプロフェッショナルは、データや時間フォーマットのサポート等の文字装飾能力は二の次であると認識している。システム１００の実施形態は、日本のアニメーションのコミュニティにおける字幕作成の特異性のいくつかを課題とするが、他の言語における媒体の字幕作成についても汎用化する。
【００１８】
図４に、スクリプト・ビュー１１０及びビデオ・ビュー１１２を含む、システム１００の実施形態の高レベルの概観を示す。図５を参照すると、システム１００の一実施形態であるアプリケーション・オブジェクト１０２は、実行及びデータ制御の基礎を形成するシングルトンである。このアプリケーションは、スクリプト・フレームへの参照及びそのビュー（以下、スクリプト・ビュー１１０と記載）、並びに、ビデオとパッケージ化アルゴリズムのフレーム及びビュー（以下、ビデオ・ビュー１１２と記載）を生成して保持する。ごく最近の字幕作成アプリケーションが、ビデオ又は媒体の提示をスクリプトに対する補助的な役割とする場合があることとは異なり、スクリプト・ビュー１１０とビデオ・ビュー１１２の両者は、システム１００の実施形態において等しく重要である。両者のビューは、別個のユーザ・インタフェースを有する完全なウィンドウである。ユーザは、自己が快適に思える任意のモニタ上において、これらのビューを任意の場所に置くことができる。
【００１９】
図５に開示する、システム１００の実施形態は、アプリケーション・プレファレンス１１５、ユーティリティ・ライブラリ１２０、ＶＭＲＡＰ９（符号１２５、以下同じ）、プレビュー・フィルタ・モジュール１３０、フィルタ・グラフ・モジュール１３５、及びフォーマット／変換／シリアライゼーション・モジュール１４０も含む。システム１００の実施形態は、ドキュメント１４５と協動してこれを変更することが開示される。
【００２０】
システム１００の実施形態が起動するときに、アプリケーション・オブジェクト１０２の一実施形態は、オブジェクト初期化をロードして実行し、システム１００及びシステム・プレファレンス格納から、保存されたプレファレンスを読み取る。次いで、アプリケーション・オブジェクト１０２はスクリプト・ビュー１１０及びビデオ・ビュー１１２をロードする。スクリプト・ビュー１１０からは、ユーザは、シリアライゼーション・オブジェクトを介するディスクからのスクリプトのロード、及びディスクへのスクリプトの保存を含み、イベント（字幕）及びスクリプト内データと直接的に相互作用する。スクリプト・オブジェクトは、個別に、イベントを含むスクリプトのデータを保持する。全てのモジュールは、スクリプト・オブジェクトと通信する。
【００２１】
システム１００の実施形態は、字幕、コマンド、コメント、注記、及びイベント・オブジェクト内の様々な種類の音声画像シーケンスをカプセル化する。コマンド等のテキスト・アイテムは、人間のユーザに対する文字形態のコマンド（例えば、“ジェンロックを作動させる”）でもよく、コンピュータが実行可能なコードでもよい。字幕等のテキスト・アイテムは、画面上の任意の場所に現れることができ（従ってスーパータイトルを含む）、手話又は点字を含む任意の言語でありうる。このイベント・データに加えて、イベント・オブジェクトは、タイミング及びこれに関連付けられる識別データを有する。後者のデータは、イベントの開始及び終了時刻、イベントについてのコメント等のメタデータ、イベントに関連付けられるスタイル及びグループ、イベント内に格納されるデータの種類（字幕、コメント、他）等を示す。
【００２２】
システム１００の実施形態は、タイミング情報がシーケンスとして適用されるデータを取り扱う。システム１００の実施形態において、シーケンスの最も共通したセットは、ビデオ・クリップに見られるような、オーディオ及びビデオを含む。しかしながら、イベント・オブジェクトに関しては、一組のシーケンスは他のデータ・ストリームを含むことが可能である。例えば、コンピュータが実行可能なコードを含むテキスト・データ・ストリームは、ビデオ・ファイルの一部として表れる。編集不可能な字幕を含む音声画像ファイルは、これらの字幕を、ユーザが通常に操作するイベント・オブジェクトよりもむしろ一種のテキスト・シーケンスとして符号化してもよい。
【００２３】
ビデオ・ビュー１１２において、ユーザは、ビデオ再生機構を用いて、媒体クリップをロードして再生する。システム１００の実施形態において、この再生機能は、フィルタ・グラフ及びカスタマイズされたフィルタによって管理される。フィルタ・グラフ及びフィルタの一つの実装としては、マイクロソフト社のＤｉｒｅｃｔＳｈｏｗ（登録商標）に見ることができる。より一般的には、フィルタは、ソース、トランスフォーム、又はレンダラである。データが、ソースからトランスフォームを介してレンダラまで接続された一連のフィルタを通過すると、次いで、レンダラはメディア・データをハードウェアに、すなわち、オーディオ及びビデオ・カード、最終的にはユーザに、送る。システム１００の実施形態は、フォーマットされた字幕をビデオ・ストリームの先頭にレンダリングする、プレビュー・フィルタ機構を提供する。高度にカスタマイズされたビデオ・レンダラは、ビデオ・チェーンの末尾に表れる。このレンダラは、ビデオを用意して提示するためのグラフィック・カードにおける３Ｄアクセラレーションを用いる、システム１００の実施形態に用いられる下層技術であり、図５及び図６に、ＶＭＲＡＰ９（１２５）として示す。しかしながら、別の実施形態において、ユーザに対してシーケンス・データを提示するための適切なインタフェースが存在するならば、３Ｄアクセラレーションは用いられない。
【００２４】
システム１００の実施形態において、フィルタ・グラフは、データのフローを制御して同期することにも関与する。この制御は、あるフィルタがアクセス可能な、参照クロック・ハードウェアを用いて行われる。参照クロックを用いるフィルタがオーディオ・レンダラであり、その参照クロックが用いられるならば、例えば、オーディオ、ビデオ、及び他のシーケンスの再生は、通常の媒体再生について期待されるものとしてユーザに提示することができる。この構成は、再生中のメディア・クリップを見て時間を計る、システム１００のユーザの実施形態について典型的なものである。
【００２５】
他の実施形態において、シーケンス処理は同期しないか、又は同じ速度ですらない。シーケンスは、逆行又はストリームあたりの再生オフセットが異なる場合も含めて、非同期かつ独立して動作する。いくつかの実施形態において、この処理は、ハードウェア参照クロックの助けなしに発生する。この構成は、例えば、ユーザが人間のユーザではなく、プロセッサ及び他のハードウェアの計算可能な最高速で、実施形態が動作しなければならない場合に、有用である。別の場合においては、人間のユーザは、ビデオ・ストリームや下記記載のパッケージ化アルゴリズムの可視化動作を見るよりも先行して、オーディオ・ストリームを聞きたい場合がある。ユーザは、対応するビデオ及び可視化動作が画面上に現れるときに、開始及び終了時刻をよりいっそう正確に示す場合がある。
【００２６】
図５に、前述のオブジェクト、並びに、システム１００の実施形態におけるアプリケーション・プレファレンス、ユーティリティ・ライブラリ、及び変換フィルタを示す。角の丸い長方形はオブジェクトであり、オブジェクトの重複は所有／被所有の関係を示す。一方向の矢印は、ポインタ参照するオブジェクトによってポインタ参照されるオブジェクトの、気づき（ａｗａｒｅｎｅｓｓ）及び操作を示す。気づきは、メモリ中にインスタンスを作成されたオブジェクトに対する参照又はポインタによって行われる。操作は、ポインタ参照されるオブジェクトを含む関数か、又はパラメータとしてポインタ参照されるオブジェクトを要求する関数に対する、ポインタ参照するオブジェクトのコードからのプログラム・コールによって行われる。例えば、本アプリケーションは、システム１００のイベントに応答して、スクリプト及びビデオ・ビュー１１２のオブジェクトを生成し、破壊する。
【００２７】
一方向の破線の矢印は、オブザーバ／サブジェクト関係を示し、プレビュー・フィルタは、スクリプト・オブジェクト内のイベントが変化するときに、更新を受信する。両方向の矢印は、二つのオブジェクト又はシステム間の相互の依存性を示す。システム１００の全体にわたるモジュールは、アプリケーション・プレファレンス及びユーティリティ・ライブラリを用いるので、具体的な接続は示さず、むしろ、これらのオブジェクトを雲形として示す。この文脈において、変換フィルタは、第一のクラスの関数オブジェクト、又はクロージャ（ｃｌｏｓｕｒｅ）であり、スクリプト・オブジェクト・エレメントを変換して、これをフィルタリングしてエレメント・サブセットとする。図５及び図６において、変換フィルタを＜ＴＦ＞として表す。変換フィルタの詳しい説明は後述する。
【００２８】
図６は、本願明細書に後述するように、オンザフライ方式のタイミング設定サブシステム１５０及びパッケージ化アルゴリズムのサブシステム１５５を用いる、システム１００のオブジェクト・モデルの実施形態の全体を示す図である。先端が円形のコネクタは、単一のオブジェクト（すなわち、パッケージ化アルゴリズム）が、異なるクライアントのオブジェクトに対して複数のインタフェースを露出する様子を示す。
【００２９】
システム１００の実施形態において、オンザフライ方式のタイミング設定サブシステム１５０及びパッケージ化アルゴリズムのサブシステム１５５は、イベント開始及び終了時刻の選択を、制御し自動化する。上述のように、最も洗練されたビデオ及びオーディオの処理アルゴリズム単独では、通常は、字幕作成の処理に求められる正確さの水準に達しない。特に、話声境界の検出アルゴリズムは、話声における休止や劇的効果のためのテンポの変化によって、過剰に多くの誤判定を生じる傾向がある。仮に、自動処理によって１００％の正確さで音声画像のキューを追跡することが可能であっても、人間のユーザは、聴衆よりも先に音声画像シーケンスを注視することにより、生成された時刻が最適であることを確認したいと望む場合がある。聴衆は、字幕が単に会話を追跡するだけではなく、映画やエピソードの芸術的映像を表すものであることを期待している。ちょうど、逐語訳が物語に対する暴挙であるように、内容にもよるが、機械的に追跡するのでは、画像によるやりとりのサスペンス、開放感、啓示を損なう場合がある。こうした制約は、ニュースやスポーツ等のテレビ放送に生放送で見出しを付けることとは異なり、一般的には、一時的な非同期は許容できると見なされる。生放送で見出しを付けることの目的は、音声映像シーケンスが特定の劇的な効果を保つために情報を同時通信することよりも、むしろ未加工の情報を受け取ることである。
【００３０】
システム１００の実施形態は、ユーザ指定の時刻を事前データとして扱い、同時並行するデータ・ストリームから、又はユーザの好みから、特徴を抽出するパッケージ化アルゴリズムに基づいて、この入力を調節する。ユーザ指定の時刻は、２つのサブシステムの外部にある、任意の処理によって提供される。ユーザは人間である必要はなく、ユーザは完全なタイミング設定の操作に対して存在する必要はない。別の実装においては、時刻は、まとめられ（すなわち、ユーザの入力から記録され）、ディスクに保存され、一つの大きな単一の調節の要求において再生又は提供されてもよい。上記のような代替実施形態のさらに完全な説明は、後続する。
【００３１】
図６に開示のように、パッケージ化アルゴリズム１５５におけるアルゴリズムは、オブジェクト内にパッケージ化され、インタフェース分離原則に従って、プリプロセッサ・アルゴリズム１６０、フィルタ・アルゴリズム１６５、プレゼンタ・アルゴリズム１７０、及びアジャスタ・アルゴリズム１７５という、一以上のインタフェースを露出する。図７を参照し、プリプロセッサ・アルゴリズム１６０、プレゼンタ・アルゴリズム１７０、及びアジャスタ・アルゴリズム１７５のためのシステム１００の実施形態から、Ｃ＋＋のリストを示す。システム１００の実施形態は、フィルタ・パッケージ化アルゴリズムのインタフェースとして、マイクロソフト社製ＤｉｒｅｃｔＳｈｏｗ（登録商標）のＩｂａｓｅＦｉｌｔｅｒを用いる。
【００３２】
アプリケーション・オブジェクト１０２は、これらのインタフェース参照の順序づけられたリストを、適切なサブシステムに配分する。これらのサブシステムは、アプリケーション・オブジェクトによって設けられた順番で、インタフェース上において適切なコマンドを起動する。
【００３３】
一例として、そのようなパッケージ化アルゴリズム、すなわち、さらに後述するビデオ・キー・フレームのパッケージ化アルゴリズムを考える。プリプロセッサ・インタフェース上でプリプロセス方法を起動することにより、パッケージ化アルゴリズムは、新規にロードしたファイルを前処理するか、又は新規にアンロードされたファイルを削除する。ビデオ・キー・フレームのパッケージ化アルゴリズムは、ファイルを開き、ファイル全体にわたってスキャンし、フレーム開始時刻によりソートされるマップにキー・フレームを加えることによって、ストリームを前処理する。性能の最適化として、ビデオ・キー・フレームのパッケージ化アルゴリズムは、ビデオ・ビューのロード及びメイン・フィルタ・グラフにおける再生が継続する間に、プライベート・フィルタ・グラフを用いてファイルをスキャンするワーカ・スレッドを起動する。
【００３４】
フィルタ・インタフェースは、その目的の一つがストリーム・データの解析であってもよいという点において、プリプロセッサ・インタフェースと類似している。しかしながら、他のインタフェースの一つにおけるイベントに応答して、ビデオ・ビュー１１２のフィルタ・グラフを通過するデータを変換するという、別のシナリオがありうる。媒体フィルタの一つの制約は、それが直接的にはフィルタ・グラフを操作できないことであるため、例えば、大きなバッファが、実質的に現在の媒体時刻の先にあるデータで、いつプリフィル（ｐｒｅ−ｆｉｌｌ）される可能性があるかを、コンピュータ資源が指示してもよい。グラフ内の全てのフィルタが、データの削除なしに大量のデータを生成して格納すると、このような大きなバッファをプリフィルしようとすることで、コンピュータ資源を使い尽くす場合がある。
【００３５】
ユーザにビデオを提示する前に、プレゼンタ・インタフェースが起動される。システム１００の実施形態において、プレゼンタ・インタフェースは、３次元レンダリング・バック・バッファが画面にコピーされる前に、起動される。システム１００の実施形態が、更新する画面の所定領域を提供する一方で、パッケージ化アルゴリズムは、３次元空間内の任意の点に描画してもよいビデオ・キー・フレームのパッケージ化アルゴリズムは、スクロール画面上のラインとしてキー・フレームをレンダリングするために、表示時刻の情報を用いる。パッケージ化アルゴリズムは、マルチスレッド化したオブジェクトであるため、デッドロックを防ぐ一方で、共有変数に対する同期アクセスには十分な注意が払われる。
【００３６】
オンザフライ方式のタイミング・サブシステムは、後述するが、ユーザ生成イベントのパッケージ化アルゴリズムに通知するために、及びパッケージ化アルゴリズムのパイプライン内の時間を調節するために、アジャスタ・インタフェースを用いる。システム１００のタイミング・サブシステムの実施形態は、まず、ユーザ生成イベントをパッケージ化アルゴリズムのパイプラインに対する構造体にコンパイルするので、種々の可能な字幕遷移シナリオをレビューすれば、タイミング処理システムの挙動に対する事例を構築する役に立つことになる。
【００３７】
オンザフライ方式によるタイミング設定中のイベントはリアルタイムで通過するため、ユーザには、多くの個別の信号を発行することによって、すなわち、一つの字幕が開始するか終了するときに、多くの個別のキーを押すことによって、反応を示す機会はほとんどない。字幕の間には、少なくとも８つの基本的な遷移があり、本願の実施形態の目的は、可能な限り多くのシナリオを削減又は消去しながら、シナリオに信号をマッピングすることである。以下の（Ａ）から（Ｈ）に列挙するシナリオのそれぞれは、８Ａから８Ｈにそれぞれ示す、小タイムラインを用いて理解することができる。これらの図において、字幕の話者は、名前がＡ及びＢであるキャラクタであり、このキャラクタに対する具体的な字幕は、キャラクタを指定する文字に添付される数字によって、リスト化されている。より形式的には、キャラクタに由来することが指定されたデータは、音声画像シーケンス等の他のデータ・ストリームとの何らかの同時並行する関係を有している。従って、キャラクタの発言は、効果音（“ポン！”“カーンと鳴るシンバル”）、音声又はビデオに見られるか又は分かるキャラクタの考え、及び姿の見えない話者によるナレーションを含むが、これらに限定されない。
【００３８】
８Ｆにおいて、文字Ｔは、音声画像シーケンスに関連付けられるが、翻訳者の注記として差し込まれる場合がある、ストリーム（例えば、スーパータイトルを含む）を指す。翻訳者は、実際には音声画像シーケンスにおけるキャラクタでも俳優でもないが、広義にはキャラクタと見られる場合もある。空白は、その時間には誰も話していないことを示す。右矢印は、時間ｔが右向きに進むことを示す。
（Ａ）キャラクタが独立して個別に話す場合。このシナリオには、一組の信号ペア、すなわち、イベントの開始及び終了時刻に対応する、開始（信号に対する遷移）及び終了（無信号に対する遷移）が必要である。
（Ｂ）キャラクタは独立して話すが、個別ではない場合。キャラクタは、一つの字幕として自然には表示できない、長い独白を話す場合がある。ユーザは、開始及び終了の信号を同時平行して送ることができてもよいが、この手順は紛らわしい場合がある。ユーザは、一つの字幕を停止し、同時に第二の字幕を開始することを意味する、隣接する信号の発行が便利であると思う場合がある。このため、開始、隣接、終了という３つの信号があってもよい。
（Ｃ）キャラクタが独立して話すが、あまり個別ではない場合。このシナリオは、人間の反応時間に与えられる２つの分離した信号セットを発行することが可能であってもよく、可能でなくてもよいこと以外は、シナリオ（Ｂ）に類似している。自然なポーズ位置で一時的に停止する話者であれば、このシナリオに適している。このシナリオを、シナリオ（Ｂ）として扱うならば、ユーザによる信号発生フェーズよりも、むしろ隣接フェーズによって、これらの時間を区別すべきである。
（Ｄ）キャラクタが不明瞭に話す場合。２人以上の話者間の激しい会話においては、開始及び終了時刻の信号を発生できない場合がある。しかしながら、話者を列挙する、翻訳又はトランスクリプト・ダイアログから、誰が話しているか（キャラクタＡであるかＢであるか）は分かる。この事前知識は、調節フェーズに対する強力なヒントとして役立つ場合があり、ユーザ信号生成フェーズに対しては、この知識は、信号が個別である必要はないことを意味する。従って、このシナリオは、シナリオ（Ｂ）に帰着する。
（Ｅ）キャラクタが、同一の字幕におけるダイアログ内で話す（典型的には、ライン開始点のハイフンにより区切られる）場合。複数のキャラクタが、正確に同一の時刻において正確に同一の発言を話すことはありそうにないが、一組の信号ペアを用いれば、字幕データにおけるイベントの組み合わせにより、このシナリオはシナリオ（Ａ）に帰着する。しかしながら、人間のオペレータが、話声における実際の遷移の箇所の誤判定を発行することにより、誤ることは起こりうる。例えば、Ａが話を止めてＢが話し始めるが、人間のオペレータは、Ａ及びＢの話が同一のイベント内にあることを見落とす。従って、一つ戻るという信号が望ましい場合がある。
（Ｆ）字幕のあるキャラクタがいない場合。キャラクタが話している間に、翻訳者の注記又は情報の要点が画面上に表れてもよい。しかしながら、通常は、こうした衝突は一時的にしか発生しない。空間上は、翻訳者の注記は、例えば、スーパータイトルとして画面上の他の場所にレンダリングされてもよい。この場合には、ユーザは何の信号も発生しなくてもよく、信号を無視してもよい。しかしながら、キャラクタのないイベントがタイミング設定中に提示されないようにフィルタリングするという、別のアプローチもある。
（Ｇ）衝突：キャラクタが互いに割り込む場合。このシナリオが発生する場合は、発生は非常に短時間であるが、大きな混乱を生じる。典型的には、ＡはＢが始める数ミリ秒以内に話し始める。調節フェーズ中の洗練された処理が、このシナリオを識別してもよい一方で、技術的及び芸術的理由から、衝突の保持は好ましくない。多くのＤＶＤプレイヤは、サブピクチャが衝突して提示されると、クラッシュ又は他の誤動作を生じる場合がある。シナリオ（Ｇ）を近接物、すなわちシナリオ（Ｄ）として扱うことは、認識の観点からは技術的には正しくないが、外部の技術的制約という観点から、実用的には正しい。芸術的側面においては、何人かの字幕作成プロフェッショナルは、聴衆が、おそらくは画面上の割り込み以上に、衝突を不愉快に思うことを報告している。字幕が空間的に衝突すると、音声画像シーケンスにおける中断を目にすることに加えて、視聴者の読み取りは中断される。このため、翻訳者又はトランスクリプト作成者は、このシナリオをシナリオ（Ｅ）に帰着する傾向がある。
（Ｈ）キャラクタが、字幕のない低い声を口にするか、又は話をする前に他の誤判定がある場合。この場合には、誤判定は、人間のオペレータ等のユーザからの誤判定の信号を導くであろう。しかしながら、このエラーは、信号の発行が遅すぎるよりは、むしろ早すぎることである。リスタート信号によって、このシナリオに対処してもよい。
【００３９】
これらの８つのシナリオの研究から、開始、隣接、及び終了という３つの主要な信号が出現する。さらに、戻る、再起動、及び次へという３つの任意の信号が出現する。
【００４０】
タイミング処理モードが起動すると、ユーザ生成イベントは、信号タイミング処理機能に向けられる。図９Ａ及び図９Ｂは、信号タイミング処理機能１８０のコアが、開始、終了、及び隣接の信号を取り扱う、システム１００の実施形態からのＣ＋＋（登録商標）実装を含む。信号タイミング処理は、隣接するイベントの、イベント・キューと呼ばれるキューを一時的に構築し、次いでパッケージ化アルゴリズムのパイプラインに対して、このキューを送る。より具体的な用語によれば、スクリプト・オブジェクトは、アクティブなイベント、字幕又は他の音声画像イベントに対する参照を格納する。ユーザが“Ｊ”又は“Ｋ”のキーを押すと、タイミング設定サブシステムはその時刻及びイベントを格納する。実際のキーはカスタマイズ可能であるが、本願明細書に記載のキーは、システム１００の実施形態におけるデフォルトである。これらのキーは、ＱＷＥＲＴＹ配列キーボード上において、右手をしばらく置いておくことのできる、最も自然なポジションに対応する。キーが解放されるときに、その時刻が終了時刻として記録され、後述するように、パッケージ化アルゴリズムの調節フェーズにキューが送信される。
【００４１】
他が押されている間に“Ｊ”又は“Ｋ”が押される場合は、信号タイミング処理は、この信号を隣接として解釈する。この時刻は、アクティブなイベントの終了及び次のイベントの開始に対応する隣接する時刻として記録され、後者は新規のアクティブなイベントに指定される。これらのキーの一つを解放しても無視されるが、最後のキーの解放は、上述のような終了信号を生成する。
【００４２】
前述の実施形態は、タイミング処理すべき全てのイベントが存在していること、及びタイミング処理すべき全てのイベントは、何らかの順序で信号タイミング処理機能に対して利用可能となっていると考えられるので、“Ｊ”及び“Ｋ”の機能は、適切な次のイベントを選択することが可能である。信号タイミング処理が用いるイベント・リストは、図６に示して後述する、イベント・フィルタを用いてカスタマイズすることが可能である。
【００４３】
さらなる実施形態は、タイミング処理中にイベントを生成する。ユーザが、終了等のイベント・リストの位置に達した場合には、例えば、“Ｊ”又は“Ｋ”を押すことにより、新規なイベント・オブジェクト生成の契機とする。次いで、新規なイベントを、イベント・リストの最後等において、スクリプト・オブジェクトに追加する。別の実施形態において、ユーザは、イベント生成の開始後、あるいはキー又は全てのキーの解放後に、イベント・データを入力している間は音声画像再生をポーズさせてもよい。ユーザがイベント・データを入力するため、イベント・データに対するプロンプトを有するポップアップ・ウィンドウが表れるか、又はスクリプト・ビュー１１０における関連イベントにフォーカスが移動する。ユーザが新規なイベント・データの入力を終了すると、再生及びタイミング処理は再開する。
【００４４】
また別の実施形態において、タイミング処理は、上記の概略のようなステップを用いて、単に時間情報を収集するが、イベントは生成せず、存在するイベントに対して入力された時間の正確な照合を要求しない。このような実施形態において、イベント生成は、例えば一連の時間の記録後等、後の時点に延期される。
【００４５】
システム１００の実施形態において、イベント・キューに対する変化を生じる全ての信号が、信号タイミング通知（ｎｏｔｉｆｙｓｉｇｎａｌｔｉｍｉｎｇ）機能をコールすることにより、信号タイミングは、アジャスタのパッケージ化アルゴリズムへの通知を行う。パッケージ化アルゴリズムは、パッケージ化アルゴリズムが実際に時間を調節する前に、リアルタイムでイベント・キュー内の変化に応答してもよい。例えば、パッケージ化アルゴリズムは、プレゼンタ・インタフェースを通じて、キュー内の、あるいはキュー内で続いて起こるイベント又は先行するイベントのリスト又は選択されたプロパティを表示してもよい。さらなる実施形態は、個別のパッケージ化アルゴリズムのインタフェースに対する、信号タイミング受信（ｓｉｇｎａｌｔｉｍｉｎｇｓｉｎｋ）インタフェース等の信号タイミング通知を、アジャスタ・インタフェースから分離するために、インタフェース分離原則を起動する。
【００４６】
２つのナビゲーションキーにより、“以前のイベントをアクティブに指定し、調節を動作することなく全ての格納されたキューを取り消すこと”（デフォルトでは“Ｌ”）、及び“次のイベントをアクティブに指定し、キューを消去すること”（デフォルトでは“；”）を指定する。上級者又は十分な知識のあるユーザは、“リピート”又は以前のイベントをアクティブに設定して信号を“開始”するために、“Ｈ”を用いてもよい。現在アクティブなイベントにおいて“開始”を再度合図するために、“Ｎ”も用いてもよい。しかしながら、一つのキー・ストロークを記憶することが困難である場合には、ユーザは、プログラムに関するほとんど全ての相互作用に対して“Ｊ”及び“Ｋ”を用いると考えられる。
【００４７】
“終了”の合図が行われると、イベント・キューは、パッケージ化アルゴリズムの調節に対する準備ができたと見なされる。システム１００の実施形態は、２次元アレイのパイプライン・ストレージ・エレメントを用意する。すなわち、そのアレイ・サイズは、アジャスタ・インタフェースと等しい数のステージ数と、イベント数に１を加えた数との積に対応する。このイベント範囲への１の加算は、終了時刻を処理するためである。しかしながら、代替実施形態においては、２次元アレイは用意されず、調節フェーズは、動的に生成される個々のパイプライン・ストレージ・エレメントを用いて動作する。このような代替実施形態においては、調節を行う他のパッケージ化アルゴリズムが時間を処理するので、調節を行うパッケージ化アルゴリズムは、候補時刻の過去又は将来の値に対してアクセスが制約されるか、又は全くアクセスしない。
【００４８】
システム１００の実施形態において、図１０に示すように、パイプライン・ストレージ・エレメント１９０のそれぞれは、当初の時刻、及び信頼性レベルに関する追加データを格納し、時刻を入れ替える。追加データとしては、以下が挙げられる。
（Ａ）当初の時刻からの標準偏差、
（Ｂ）入れ替えた時刻、
（Ｃ）入れ替えた時刻における信頼性評価、及び、
（Ｄ）検索するための最短及び最長の絶対値の時間を特定するウィンドウ。
【００４９】
各パイプライン・セグメントは、一つのイベント及び一つの時刻（開始、隣接、又は終了）、すなわち、図１０に示すイベント時刻ペア１９５に対応する一方で、パッケージ化アルゴリズムは、隣接する時間を、不均等な前回の終了と次の開始に分離してもよい。各ストレージに対するパッケージ化アルゴリズムは、現在のイベント及びステージに関して、パイプライン・ストレージを試験してもよい。パッケージ化アルゴリズムには、以前のステージから最良の既知の回数が提供されるが、パッケージ化アルゴリズムはパイプライン内の全イベントに対するアクセス権も有する。問題となっているパッケージ化アルゴリズムよりも前の全ての以前のステージは、キャッシュされた時間で埋められる。この過去のデータの記憶及びこれへのアクセスは、例えば、最適な字幕の期間を計算するときに有用であり、現在のステージに対する絶対値の時間は、以前のステージからの最適な時間に依存する。代替実施形態において、パッケージ化アルゴリズムは、パッケージ化アルゴリズムのアジャスタ・インタフェースを通じて、パイプライン内の全てのイベントを読み取り、これへのアクセスを書き込む。
【００５０】
パイプライン・ストレージは、さらに、パッケージ化アルゴリズム・サブシステムに対して、各ステージに対応するパッケージ化アルゴリズムのインタフェースを露出する。各アジャスタ・インタフェースは、さらに、具体的なクラス又はオブジェクトのユニークな識別子を露出するので、アジャスタは、実際に以前に実行されるものが何か、又は後に何が実行されるかを決定することができる。
【００５１】
図１１のフローチャートに示すように、オンザフライ方式のタイミング設定サブシステム１５０と、パッケージ化アルゴリズム・ブシステム内のアジャスタ・コード１７５との間には、制御が組み上げられる。アジャスタ・インタフェースの調節方法は、パイプライン・ストレージ・エレメントへの非定常的参照を受信し、これに結果を書き込む。オンザフライ方式のタイミング設定サブシステムに制御が戻るときには、サブシステムは、任意の時点で、以前のアジャスタからの結果を調節するか又は置き換えてもよい。イベントに対するパイプライン・セグメントの最後において、タイミング設定サブシステムは、そのイベントの時刻を最終的に調節された時刻に置き換える。
【００５２】
原理的には、これらの露出は、詳細は抽象に依存すべきであると述べた、オブジェクト指向プログラミングの依存逆転原則を侵している。しかしながら、パッケージ化アルゴリズムの調節フェーズは、形式的制御よりもむしろ実用的に制御された、依存性のネットワークであると考えることが最良である。パイプラインを介した当初の制御経路は、通常の実行形態を構成するが、パッケージ化アルゴリズムを高度にカスタマイズして混合すると、カスタム・コード及び予期しない依存性を要求する場合がある。この場合には、単独のプログラマ又は組織が、全てのパッケージ化アルゴリズムを生成又は組み合わせてもよく、そのような制作者であれば全てのパッケージ化アルゴリズムのステートメントの依存性を理解している。上級者ユーザは、対照的に、いずれのパッケージ化アルゴリズムが、具体的な挙動に対してパイプライン中において特定の順序で動作するかを明確にできるが、もしも一つのパッケージ化アルゴリズムが別の内部的な詳細に依存していると、それらの結果は予想通りではなくなってくる。最終的には、音声処理アルゴリズムが特定のデータにおいて偽の結果を提供することが分かっていると、後続のパッケージ化アルゴリズムは、その特定のパッケージ化アルゴリズムからの特定のデータに対して試験し、以前のステージの結果を無視することが可能である。一つのアルゴリズムを別のものと入れ替えることは、単一のパッケージ化アルゴリズムのインタフェース参照を入れ替え、次いで最適な時刻の送信のためにフレームワーク全体に強調を設定することと同様に、単純である。
【００５３】
人間の相互作用は、このフレームワークにおいて重要な役割を演ずるが、さらなる実施形態においては、代替の動作モードが存在する。このフレームワークは、予め記録されたユーザ・データの供給によるか又は別の処理からのデータ生成によるリアルタイムの再生なしに、動作してもよい。時間が厳密に増加するという明確な必要性はなく、例えば、制御システム１００は時間を逆に生成してもよい。フィルタ及びプレゼンタ・インタフェースは、ＶＭＲＡＰ９（１２５）及びフィルタ・グラフ・モジュールに対して供給される必要はないので、プロセッサ・サイクルを節約する。
【００５４】
さらに、ユーザは、人間のオペレータである必要は全くない。代わりに、ユーザは、信号として、又はパッケージ化アルゴリズム及びオンザフライ方式のタイミング設定サブシステムによって処理される直接の時間として、時間を送信する任意のプロセスであってもよい。このようなプロセスは、ビデオ及び音声ストリームの形態で（パッケージ化アルゴリズムのプレゼンタ・インタフェースからの関連オーバーレイを用いて）同時平行して提示されるデータを受け取り、評価してもよく、そのようなデータを無視してもよい。
【００５５】
それにもかかわらず、システム１００の実施形態は、この問題領域の前述した制約を考慮し、これらの代替を実装しない。第一に、インタフェース分離原則に関わらず、パッケージ化アルゴリズムは、パッケージ化アルゴリズムの挙動を他のインタフェース、すなわちアジャスタ・インタフェースに影響させるために、プレゼンタ又はフィルタの挙動を用いることができる。例えば、因果的音声（ｃａｕｓａｌ  ａｕｄｉｏ）のパッケージ化アルゴリズムは、フィルタ・インタフェースにおける音声処理及び特徴分析を実装してもよく、一方でビデオのパッケージ化アルゴリズムは、表示面からビットを読み取り、通過した将来の時間の調節に影響を与えてもよい。例えば、ユーザは、表示面におけるマウスクリック及びドラッグの形態で空間的なデータを提示し、開始及び終了時刻が変化することをジェスチャで示してもよい。以下に説明するように、差分データ時間長の（ｓｕｂ  ｄｕｒ）パッケージ化アルゴリズムは、最新の字幕の期間について視覚的な概算を提示するが、これがわずかにユーザの反応に影響する場合があるプレゼンタ及びフィルタ・インタフェースは、ユーザを取り込み、ユーザに情報を与え、刺激する、大きなフィードバック・ループの一部として見られるべきである。
【００５６】
第二に、パッケージ化アルゴリズムは、他のインタフェースへのデータ収集又は処理に影響するアジャスタ・インタフェースからのユーザのフィードバックに依存することにより、計算時間を節約することができる別の実施形態における標識移動検出は、例えば、ある場面において広範囲の計算（又は、低優先度のスレッドにおけるバッチ処理）を実行するが、標識が現在注視されていることをユーザが示している当該場面においてのみである。さらなる実装においては、パッケージ化アルゴリズムは、時間収集フェーズ中にイベントそれ自体への書き込みアクセスを有するか、又はパッケージ化アルゴリズムの調節フェーズにおける操作のために他の変化をイベントに記録した、パイプライン・ストレージ・エレメントを与えられる場合がある。
【００５７】
第三に、多くのアプリケーションにおいて、ユーザが字幕に対してリアルタイムに反応し、コンピュータ計算が限られた範囲において網羅的な検索を実施することは、コンピュータ計算がより多くの拡大範囲を検索し、ユーザに多くの次善の結果から選択を求めるよりも、高速である。上に提案した操作を逆転する実施形態において、タイミング設定サブシステムは、小さい、等間隔のインターバル内に信号を生成し、状態をもたないパッケージ化アルゴリズムによって、入力された時刻が調節後にどこに集まっているかを見る。しかしながら、コンピュータは広範囲のデータからの選択が得意ではない場合があり、人間は正確な閾値を素早く識別することが得意ではない場合がある。ユーザがマクロな識別に注意を払う場合には、システム１００はその残りに注意すべきである。
【００５８】
しかしながら、ある配列操作に対しては、この逆転した実施形態はより成功を収めることが分かる。例えば、ユーザは、自己が以前に見たことのない音声画像シーケンスにおいて、単一で既知の、不規則な字幕イベント（テキストを伴う）が発話される時刻を見つけたいと思う場合がある。この逆転した実施形態を用いれば、ユーザがそのときに調べることが可能な具体的な時刻が得られ、ユーザがシーケンス全体を見るよりも高速であるはずである。適切な時刻を選択すると直ちに、ユーザは、適切な開始及び終了時刻を用いて、字幕を配列するために、その場で微調整する（又は、前述の実施形態を用いて、さらなる操作を実施する）ことになる。
【００５９】
システム１００の一実施形態においては、以下のパッケージ化アルゴリズムを用いた。このリストは、パッケージ化アルゴリズムが露出したインタフェースを、括弧で示す。以下提示した列挙の順序は、本実施形態のパッケージ化アルゴリズムのパイプラインにおける、これらのパッケージ化アルゴリズムの順序に対応する。
【００６０】
（１）サブキューのパッケージ化アルゴリズム（プレゼンタ、アジャスタ）：アクティブなイベント、及びアクティブなイベントの前（以前のイベント）及び後（次のイベント）の任意の数のイベントを表示する。システム１００の実施形態において、このパッケージ化アルゴリズムは、Ｄｉｒｅｃｔ３Ｄ（登録商標）を用いてビデオ上にテキストを提示する。従って、これは極めて高速である。このパッケージ化アルゴリズムは、パイプラインにおいては調節を実施しない。従って、上述のように、これが依存するのは信号タイミング通知（ｎｏｔｉｆｙｓｉｇｎａｌｔｉｍｉｎｇ）機能であり、調節機能ではない。
【００６１】
（２）音声のパッケージ化アルゴリズム（プリプロセッサ、プレゼンタ、アジャスタ）：ビデオ・ビュー１１２に基づくプライベート・フィルタ・グラフを構築すること、及び大規模なサーキュラー・バッファにデータを送る受信装置（特別なレンダラ）を通じて、このグラフからデータを連続して読み取ることにより、音声波形を前処理する。パッケージ化アルゴリズムは、ピークをより容易に見るための垂直拡大ズームにより、ビデオ・ビューの表示領域に、３次元オブジェクトとして波形をレンダリングして提示する。パッケージ化アルゴリズムは、パーセバルの関係及び窓関数を用いて、組み合わされたチャネル信号の、時系列エネルギーを算出する。パッケージ化アルゴリズムは、パイプライン・ストレージ・エレメントによって特定される関心ウィンドウ内の、高エネルギー方向（入力）、高エネルギー後の低エネルギー方向（隣接）、又は低エネルギー方向（終了）の、最も急激な遷移を拾い出すことにより、イベント時刻を調節する。
【００６２】
（３）最適な差分データ時間長のパッケージ化アルゴリズム（プレゼンタ、アジャスタ）：新規なイベントがアクティブとなり、字幕の文字列の長さに基づいて、最適時刻及び最後の最適時刻を示すパッケージ化アルゴリズムにおける水平の傾斜ハイライトをレンダリングするときに、通知を受信する。システム１００の実施形態において、このパッケージ化アルゴリズムは、
０．２秒＋０．０６秒×字幕イベント文字数、
という式を用いて、最適な表示時間を決定する。調節においては、このパッケージ化アルゴリズムは、最適時刻から標準偏差（文字数の関数）の２倍よりも現在時刻が離れている場合に、その時刻を調節するのみである。この場合には、パッケージ化アルゴリズムはパイプライン値の継承を放棄し、短くとも最短（０．２秒）又は長くとも予め算出された標準偏差内の最長時間に、パイプライン内の時間を設定する。代替実施形態は、時間を調節するために、代替の画像又は聴覚的な通知、代替の形式、及び代替の閾値を指示する。
【００６３】
（４）ビデオ・キー・フレームのパッケージ化アルゴリズム（プリプロセッサ、プレゼンタ、アジャスタ）：キー・フレームをスキャンすることにより、ロードしたビデオを前処理する。キー・フレームは、マップ・データ構造（典型的には、ソートされた連想コンテナの仕様を有し、二分木として実装される）に格納され、時間によってソートされ、パッケージ化アルゴリズムの提示領域に黄色の線でレンダリングされる。調節においては、提案された時刻がキー・フレームのユーザにより指定される閾値距離以内であれば、その時刻はそのキー・フレームのいずれかの側にスナップする。
【００６４】
さらなる実施形態は、隣接スプリッタ（Ａｄｊａｃｅｎｔ  Ｓｐｌｉｔｔｅｒ）のパッケージ化アルゴリズムを含む。当該パッケージ化アルゴリズムは、前の終了と次の開始時刻とを分割し、画像の不鮮明化を防ぐための最小分離を形成し、直接的な転送を行う。最小分離及び分割方向は、ユーザ又は外部プロセスにより、静的又は時間依存するプレファレンスとして供給することができる。このような妥当な値の一つは、ビデオの２フレームであり、この時刻の値はビデオのフレーム・レートに依存する。このさらなる実施形態において、隣接スプリッタのパッケージ化アルゴリズムは、パイプラインの最後に表れることが可能である（４．１）。
【００６５】
さらなる実施形態は、反応補正（Ｒｅａｃｔｉｏｎ  Ｃｏｍｐｅｎｓａｔｉｏｎ）のパッケージ化アルゴリズムを含む。当該パッケージ化アルゴリズムは、ユーザの反応時間に対する補正を行う。通常の訓練されていない人間のユーザは、音声画像の境界に対して、表示及び聴取の約０．１秒後に反応する。この場合に対して、このパッケージ化アルゴリズムは、全ての提案された入力時刻から０．１秒を減算することになる。しかしながら、訓練により、ユーザが常に完全に時間通りである場合があり、開始及び終了に対して、隣接ではなく、ずれた値のみを入力する場合があり、あるいは早すぎる時間を入力する場合がある。このパッケージ化アルゴリズムは、全てのこうした種類のエラーに対する補正を行う。このさらなる実施形態において、反応補正のパッケージ化アルゴリズムは、パイプラインの開始に表れることができる（０．１）。この位置決めに対する一つの根拠は、後続のパッケージ化アルゴリズムが、ユーザの関心に最もよく対応する一時的領域を通じて検索を行うことである。
【００６６】
開発者が異なるアルゴリズムの実装を所望する場合には、開発者は、前述のインタフェースをサポートする別のパッケージ化アルゴリズムを生成し、そのパッケージ化アルゴリズムをパイプラインの最適な位置に差し込むことになる。
【００６７】
本開示のシステム１００の実施形態は、適宜、任意のプラットフォーム上で動作する。しかしながら、このような実施形態は、プラットフォーム間の容易な移植に伝統的に抵抗してきた、様々な異なる音声画像技術を用いる傾向がある。通常の人間のユーザ・インタフェースは、動的な字幕のオーバーレイを有する、音声波形ビュー及び実況のビデオ・プレビューを含む。システム１００の実施形態には、一つのビデオ・ビュー１１２及びスクリプト・ビュー１１０のみが表示されるが、代替実施形態は、複数フレームの並び、複数ビデオ・ループの並び、ズーム、パン、カラー操作、又は特定ピクセル上でのマウスクリックに対する、追加のビデオ・ビューを許容する。図１２に明らかであるように、スプリッタ・ウィンドウを介し、フレーム内には、複数のスクリプト・ビューがサポートされる。代替実施形態は、それらのビューを別個のスクリプト・フレーム内に表示してもよい。
【００６８】
既存の字幕作成ソフトウェアがウィンドウズ（登録商標）系であること、ウィンドウズ（登録商標）にはＤｉｒｅｃｔＳｈｏｗ（登録商標）を通じた相互のマルチメディアＡＰＩがあることから、ウィンドウズ（登録商標）機を用いる字幕作成ソフトは数多い。このため、システム１００の実施形態は、Ｍｉｃｒｏｓｏｆｔ  Ｆｏｕｎｄａｔｉｏｎ  Ｃｌａｓｓ（登録商標）、Ｄｉｒｅｃｔ３Ｄ（登録商標）、ＤｉｒｅｃｔＳｈｏｗ（登録商標）、及び国別言語サポートの列挙等の国際化（ｉｌ８ｎ）を意識したＡＰＩを用いて、マイクロソフト・ウィンドウズ（登録商標）に実装される。システム１００の設計の実施形態への参照は、時折、ウィンドウズ（登録商標）を中心とする用語を用いる場合がある一方で、当業者であれば、代替実施形態がウィンドウズ（登録商標）に見られる技術には限定されないことを理解する。
【００６９】
システム１００及び本願明細書に記載の方法の実施形態が、任意のプラットフォームに適用可能である一方で、実施形態ごとに具体的なプラットフォームを目標とすることには、個別の利点がある。それぞれのプラットフォーム及び抽象層は、個別のオブジェクト・メタファを維持するが、マルチ・プラットフォームの最上位の抽象層には、こうしたオブジェクトの最小公分母（ｌｏｗｅｓｔ  ｃｏｍｍｏｎ  ｄｅｎｏｍｉｎａｔｏｒ）を実装してもよい。システム１００の実施形態は、例えば、別のプラットフォームには正確に一致するものがない場合に対して、いくつかのウィンドウズ（登録商標）・ユーザ・インタフェース制御を利用する。あるいは、いくつかのユーザ・インタフェース制御は、外見及びユーザの機能性において同一であるが、等価であるが同一ではないファンクション・コールを要求する場合がある。
【００７０】
システム１００の実施形態において、性能及び正確さにも特別な価値があるため、一つのプラットフォームに対するコーディングは、当該プラットフォームにおいて、最高の正確さに最小の負荷を伴わせることを可能とする。例えば、システム１００の実施形態における時間計測のための基本単位は、マイクロソフト社ＤｉｒｅｃｔＳｈｏｗ（登録商標）ではＲＥＦＥＲＥＮＣＥ＿ＴＩＭＥ（ＴＩＭＥ＿ＦＯＲＭＡＴ＿ＭＥＤＩＡ＿ＴＩＭＥ）であり、これは１００ナノ秒を単位とする６４ビット整数として時間を計測する。この時間は、ＤｉｒｅｃｔＳｈｏｗ（登録商標）の全てのオブジェクト及びコールに対して一貫しているので、媒体時間の取得、設定又は計算に際して、正確さが失われることはない。ＳＭＰＴＥドロップ・フレーム・タイムコードや４４．１ｋＨｚ音声サンプリング等の、他の単位間の変換には、一貫性のある中間手段としてのＲＥＦＥＲＥＮＣＥ＿ＴＩＭＥを用いることができる。さらに、システム１００の実施形態は、ウィンドウズ（登録商標）用に設計された他のアプリケーションとして、一貫したユーザの経験を提示することを試み、これにより、当該プラットフォームのユーザに対する学習曲線の傾斜はより緩やかであり、インタフェース抽象化における内部的な信頼性をより高くすることになる。
【００７１】
図６に示すように、システム１００の実施形態におけるスクリプト・オブジェクトは、多くの他の構成要素間において中心にあり、構成要素の多くはマルチスレッド化されるか又は他のやり方で頻繁に状態を変更する。
【００７２】
上述のイベント・オブジェクトは、アレイよりもむしろＣ＋＋標準テンプレート・ライブラリ・リスト、又は特別なデータ構造に記憶される。この記憶は、未消去のリスト・メンバに対するイテレータ（すなわち、カプセル化したポインタ）の有効性を持続しながら、一定時間内において、ある動作の実施を許容する、様々な最適化及び利便性に通じる。システム１００の実施形態において、イベント・オブジェクトを要求するオブジェクト及びルーチンのほとんどは、他のイベント・オブジェクトの発見がリニアな時間よりもずっと少なく発生するように、リストにおける所望のオブジェクトに十分に近いイベント・オブジェクト・イテレータにもアクセスする。
【００７３】
動作のためにウィンドウを必要とするＭｉｃｒｏｓｏｆｔ  Ｆｏｕｎｄａｔｉｏｎ  Ｃｌａｓｓ（登録商標）のＣＶｉｅｗ抽象化に依存するよりも、システム１００の実施形態は、システム１００の制御及びユーザ・インタフェース・エレメントの全ての実施形態を通じてデータの一貫性を確実にするために、これ自体のオブザーバ・デザインを実装する。このオブザーバは、いくつかの隠された状態を有する抽象クラスであり、宣言されたクラス内部が観測される。イベント・オブジェクトに対する変化の観測を望むオブジェクトは、例えば、Ｅｖｅｎｔ：：Ｏｂｓｅｒｖｅｒから継承する。オブザーバ又はサブジェクトのいずれかが削除されると、オブザーバと観測されるものとのリンクの、証明、破壊、安全な消去が、特別なデストラクタにより確認される。
【００７４】
職業翻訳者及び字幕作成者は、自己が見たいと思う仕様の、かなり広範囲に及ぶリストを維持しているが、彼らが最も頻繁に要求する仕様は、２９．９７Ｈｚで動作するビデオに対する時間表示のための、ｈｈ：ｍｍ：ｓｓというＳＭＰＴＥドロップ・フレーム・タイムコードに対するサポートであった。システム１００の実施形態は、時間フォーマットを具体的に取り扱うために、様々なシリアライゼーション及びデシリアライゼーション・クラスを用い、ＲＥＦＥＲＥＮＣＥ＿ＴＩＭＥユニット、別々の数字のフィールドにそれぞれのデータを格納するＳＭＰＴＥオブジェクト、フレーム・カウント及びフレーム・レート用の一覧にデータを格納するＴｉｍｅＣｏｄｅオブジェクト、及び文字列の間の変換を行う。
【００７５】
システム１００の実施形態は、概要を前述して図５及び図６に示す、イベント変換、イベント・フィルタ、及びイベント変換フィルタをサポートする。フィルタは関数オブジェクト、又はいくつかの状態に初期化される、シミュレートされたクロージャである。フィルタは、イベント・オブジェクトのサブセットの選択に用いられ、イベント変換は、ユーザからの要求に応答して、イベント・オブジェクトを操作し、変調し（ｒａｍｐ）、又は他のやり方で変更する。例えば、時間オフセット及び変調は、イベント変換内にカプセル化することができるので、システム１００の実施形態は、この変換をイベントのサブセット、又はスクリプト・オブジェクト内のイベント・リスト全体に適用することになる。上述のフィルタ及び変換オブジェクト及び機能性は、コンピュータ科学の文献には存在してきたが、フィルタリングを取り入れている、概説した字幕作成ソフトウェアの実装には登場していなかった。さらに、これらの概説した実装は、字幕作成の全体にわたって再利用可能なオブジェクトとしては、変換及びフィルタを実装してはいないと考えられる。
【００７６】
システム１００の実施形態における、これらの変換フィルタの追加応用のいくつかについて、次項に言及する。
【００７７】
図１２において、システム１００のスクリプトの実施形態は、サブクラス・ウィンドウの共通制御、及びカスタム・デザインによる制御の、高度にカスタマイズした行を用いる。デフォルトでは、各行の高さはテキストの３行である。本願の実施形態において、制御の背後にあるコード自体は、ほとんどの機能性を扱うが、全てというわけではない。カスタム化したペイント及びクリップ・ルーチンにより、不要な画面の更新や背景の消去が防がれる。スクリプト・ビュー１１０のコードは、スクロール目的のための高さ全体の計算を管理しなければならないが、この構成の一つの波及効果は、このビューが、スクリプト内のイベント数において、リニアな時間よりもむしろ、ならし定数時間（ａｍｏｒｔｉｚｅｄ  ｃｏｎｓｔａｎｔ  ｔｉｍｅ）におけるイベント・オブジェクトに対する変化を処理できることである。
【００７８】
スクリプト・ビュー１１０は、同様にリスト内の行の記録を維持する。リスト内の各行は、モニタされるイベントに対するイテレータを格納する。このイテレータは、参照によりイベントにアクセスできることに加えて、スクリプト・オブジェクトのイベント・リストにおけるイベントの位置を格納する。ユーザがビューに対して異なるフィルタを選択する場合には、システム１００の実施形態は、次にマッチするイベントに対して次の適切なイテレータが見出されるまで、前方及び後方に反復するときに、フィルタを適用する。
【００７９】
図１３に示すように、ビデオ・ビュー１１２は、ツールバー２００、シークバー２０５、ビデオ・ディスプレイ２１０、パッケージ化アルゴリズムのディスプレイ２１５、波形バー２２０及びステータス・バー２２５という、いくつかの領域に分割される。ＶＭＲＡＰ９（１２５）は内部ビューを管理する（前述した通り）ため、パッケージ化アルゴリズム及びビデオ描画は同じルーチンに該当する。サブキューのパッケージ化アルゴリズムは、例えば、表示時刻における画面上のアクティブなキュー・アイテムを描画することにより、この特徴を利用する。図１３は、全てのパッケージ化アルゴリズムがアクティブであるビデオ・ビュー１１２を示し、オンザフライ方式のタイミング設定サブシステムのパッケージ化アルゴリズム調節フェーズに至る大きなフィードバック・ループに、ユーザを直結している。
【００８０】
システム１００の実施形態は、アプリケーションが世界中のコンピュータ上で動作し、他の世界中のコンピュータに由来するデータを処理するという国際化と、ユーザ・インタフェース及びそれが表すデータ・フォーマットは現地の言語及び文化に一致するという局在化との、両者を備える。
【００８１】
ウィンドウズ（登録商標）２０００／ＸＰ／Ｖｉｓｔａ（登録商標）で動作するウィンドウズ（登録商標）・アプリケーションは、テキスト文字列を格納するためにユニコード（登録商標）を用いることができる。ユニコード標準は、世界における可能なキャラクタの全てにユニークな値を割り当て、符号化及び様々なユニコード文字の表記の間で変換を行うための変換フォーマットも提供している。基本多言語面における文字は、０ｘ００００から０ｘＦＦＦＦまでの１６ビットのコード番号値を有し、単独の符号なし短精度整数型として格納することができる。しかしながら、０ｘ１０ＦＦＦＦまでの、より上位の面のコード番号値には、代用対を使用する必要がある。必要であれば、システム１００の実施形態は、これらの代用対コード番号及びユニコードを単独の３２ビット整数として格納するＵＴＦ−３２フォーマットもサポートする。国際化仕様は、例えば、スクリプト・ビュー１１０（図１０）及びビデオ・ビュー１１２（図１３）の混在テキストに明らかである。
【００８２】
いくつかのスクリプトはバイナリ形式で格納されるが（本願明細書に記載のシステム１００の実施形態は、もしもエクセル（登録商標）がインストールされていれば、マイクロソフト・エクセルのファイルの読み込みを限定的にサポートしている）、ほとんどのスクリプトは空間的な制御コードを伴うテキストとして格納される。結果として、テキスト・ファイルのエンコードは、生成元のコンピュータ及び国によって大きく変化する場合がある。システム１００の実施形態は、ユニコードと他のエンコードとの間で変換するための、ＭｕｌｔｉＢｙｔｅＴｏＷｉｄｅＣｈａｒ及びＷｉｄｅＣｈａｒＴｏＭｕｌｔｉＢｙｔｅのＷｉｎ３２ＡＰＩコールに依存する。システム１００の実施形態は、サポートされている文字エンコードを全て列挙することを問い合わせ、スクリプト・ファイルのためにカスタマイズされたＯｐｅｎ及びＳａｖｅＡｓダイアログ内に提示する。これらの機能はオペレーティング・システムのサポートに依存するので、複雑なライブラリ・ファイルのバンドルなしに、システム１００に対して多くの機能性を追加する。
【００８３】
ウィンドウズ（登録商標）の実行ファイルは、．ｅｘｅファイルにコンパイル及びリンクされる多くの非実行型データを、リソース内に格納する。リソースは、そのデータが対応する言語及び文化を識別するロケールＩＤを用いて、同様にタグ付けされ、同一のリソースＩＤを有する複数リソースは、そのロケールＩＤが異なるならば、同一の実行ファイル内に存在してもよい。ロケールを意識しないリソース機能へのコールは、コールするスレッドのロケールＩＤを用いることにより、リソースを選択する。システム１００の実施形態は、アプリケーション初期化時にスレッドのロケールＩＤを設定し、スレッドのロケールＩＤはユーザが特定した値に設定される。このアプローチを用いても、リソースは、まだ、直接的に実行ファイルにコンパイルしなければならない。ユーザは、例えばテキスト・ファイル内に、直接的にはカスタム文字列を設けることはできない。他方では、ソースコードへのアクセスを伴う進歩的な実装によれば、所望のようにローカライズしたリソースをコンパイルすることができる。代替実施形態は、一以上の別個のリソース・ファイル内のテキスト文字列及び画像等のリソースを提供し、ユーザは、ユーザ・インタフェースの言語又は表記を変更するためにこれを選択することができる。
【００８４】
上記の記載は例示を意図しており、限定ではないことを理解されたい。上記の記載を概観すれば、当業者にとっては多くの他の実施形態が明らかである。従って、本発明の範囲は、添付の特許請求の範囲を、当該特許請求の範囲が権利化する等価物の全ての範囲と共に参照することにより、決定すべきである。システム１００の実施形態の前述した記載は多くの具体性を含む一方で、これらの仕様は上記に示したシステム１００の範囲における限定としてではなく、むしろその様々な実施形態の例示として解釈すべきである。多くの他の変形が可能である。例えば、パッケージ化アルゴリズム・サブシステム及びオンザフライ方式のタイミング設定サブシステムは、結合し、様々なステージで異なるサブシステムに分離し、異なる時点で動作することが可能であり、ユーザは対話を行う人間のユーザである必要はなく、音声の断片、画像又は注釈等の字幕以外のデータでイベントを作ることも可能である。
【図１】
2010509859.tif 000003
【図２】
2010509859.tif 000004
【図３】
2010509859.tif 000005
【図４】
2010509859.tif 000006
【図５】
2010509859.tif 000007
【図６】
2010509859.tif 000008
【図７】
2010509859.tif 000009
【図８】
2010509859.tif 000010
【図９Ａ】
2010509859.tif 000011
【図９Ｂ】
2010509859.tif 000012
【図１０】
2010509859.tif 000013
【図１１】
2010509859.tif 000014
【図１２】
2010509859.tif 000015
【図１３】
2010509859.tif 000016
【国際調査報告】
2010509859.tif 000017