(57)【特許請求の範囲】
【請求項１】
１つのグループを形成するデータが繰り返し記録された領域を有する記録媒体から、少なくとも前記グループを形成するデータを読み出すことができる読出手段と、
前記読出手段によって読み出されたデータをバファリングする格納手段と、
前記格納手段に１つのグループを形成する全データが適正にバファリングされることに応じて、当該グループとなるデータの出力処理を行う出力手段と、
前記格納手段に１つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データがバファリングされている場合は前記読出手段における読出位置のアクセスを伴わない第１のリトライ動作を実行させ、一方、そのグループの先頭データがバファリングされていない場合は前記読出手段における読出位置のアクセスを伴なう第２のリトライ動作を実行させるようにするリトライ制御手段と、
を備えたことを特徴とする再生装置。
【請求項２】
前記リトライ制御手段は、前記格納手段へバッファリングされたデータについてエラーが検出された場合に、１つのグループを形成する全データが適正にバファリングできなかったとして、前記第１のリトライ動作もしくは前記第２のリトライ動作の実行制御を行うことを特徴とする請求項１に記載の再生装置。
【請求項３】
前記第２のリトライ動作において、前記読出手段の読出位置のアクセスは、そのアクセス目的位置が所定範囲内でランダムに選択されることを特徴とする請求項１に記載の再生装置。
【請求項４】
前記リトライ制御手段は、前記格納手段へバッファリングされたデータについて所定数以上のエラーが検出された場合に、リトライ動作を実行させずに動作を終了させることを特徴とする請求項１に記載の再生装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばＣＤ−ＴＥＸＴなど、記録媒体上に１つのグループを形成するデータが繰り返し記録されている領域を有する記録媒体から、少なくともそのグループデータを再生することのできる再生装置に関するものである。
【０００２】
【従来の技術】
いわゆる一般のオーディオ用のＣＤ（COMPACT DISC）のフォーマットに準拠したうえで、そのサブコードデータとして所要の文字情報を記録したＣＤ−ＴＥＸＴが知られている。記録される文字情報としては、例えばディスクのタイトルやアーティスト名、楽曲名などの情報とされ、これらの情報を読み出して表示することによって、ユーザーはそのオーディオＣＤに収録されてる情報の内容などを文字で確認することが可能である。
なお、このＣＤ−ＴＥＸＴにおける文字情報は、例えばディスクのＴＯＣ領域（リードイン領域）などにおけるサブコードとして、内容的に１つのグループを形成するデータ（文字情報）が繰り返し記録されているものである。
【０００３】
【発明が解決しようとする課題】
ところで、例えばＣＤ−ＴＥＸＴの場合は、文字情報についてはエラー訂正手段が付与されていない。このため文字情報の抽出はディスクのリーダビリティに大きく依存することになる。換言すれば、読出を行う領域に汚れや傷などがある場合は、文字情報を適正に抽出することが困難であった。
文字情報が適正に得られない場合は、ある程度の回数は読出のリトライを行うことになるのだが、リトライを何回か実行しても文字情報がうまく読み込めない場合もある。
また、リトライによって文字情報の読込に成功したとしても、その読込成功までに比較的長い時間がかかってしまうという場合もある。
【０００４】
【課題を解決するための手段】
本発明はこのような問題点に鑑みて、１つのグループを形成するデータが繰り返し記録された領域を有する記録媒体から、少なくともそのグループを形成するデータ（例えばＣＤ−ＴＥＸＴにおける文字情報グループ）を読み出す動作に関して、リトライ動作を工夫することで、読込の成功率を大きく向上させること、及びリトライ動作を効率化させることを目的とする。
【０００５】
このために再生装置として、記録媒体からグループを形成するデータを読み出すことができる読出手段と、読出手段によって読み出されたデータをバファリングする格納手段と、格納手段に１つのグループを形成する全データが適正にバファリングされることに応じて、当該グループとなるデータの出力処理を行う出力手段と、格納手段に１つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データがバファリングされている場合は読出手段における読出位置のアクセスを伴わない第１のリトライ動作を実行させ、一方、そのグループの先頭データがバファリングされていない場合は読出手段における読出位置のアクセスを伴なう第２のリトライ動作を実行させるリトライ制御手段とを備えるようにする。
つまり読み出すべきデータが繰り返し記録されたグループデータであることにより、リトライ動作としてアクセスが不要と判断した場合はそのまま読出を続行させてバッファリングのリトライ（第１のリトライ動作）を行い、一方、アクセスが必要と判断された場合、例えばディスク上の傷や汚れなどに起因する読込エラーの可能性がある場合などは、読出位置のアクセスを伴ったリトライ（第２のリトライ動作）を行なうというように、状況に応じてリトライ動作を切り換えることで、読込の成功率を向上させるとともに、リトライ動作の効率化を実現する。
【０００６】
【発明の実施の形態】
以下、本発明の実施の形態として、ＣＤ−ＴＥＸＴとしてのディスクに対応してデータ（オーディオデータ及びサブコードとしての文字情報）を再生できる再生装置を例にあげる。なお、サブコードとして記録される文字情報を「テキストデータ」ともいうこととする。
また説明上、本発明でいうアクセスを伴わない第１のリトライ動作を「バファリングリトライ」、アクセスを伴なう第２のリトライ動作を「アクセスリトライ」ということとする。
説明は次の順に行う。
１．再生装置の構成
２．ＴＯＣ及びサブコード
３．テキストデータ
４．テキストデータの読出処理
【０００７】
１．再生装置の構成
【０００８】
図１は本例の再生装置７０の要部のブロック図である。
ＣＤ方式のディスク９０（例えばＣＤ−ＴＥＸＴ）は、ターンテーブル７に積載され、再生動作時においてスピンドルモータ６によって一定線速度（ＣＬＶ）もしくは一定角速度（ＣＡＶ）で回転駆動される。そしてピックアップ１によってディスク９０にエンボスピット形態で記録されているデータの読み出しが行なわれることになる。本例ではＣＬＶ方式として説明を続ける。
なおこの再生装置７０はＤＶＤ（DIGITAL VERSATILE DISC）も再生可能であり、この場合相変化ピット形態で記録されているデータの読み出しが行なわれることになる。
【０００９】
ピックアップ１内には、レーザ光源となるレーザダイオード４や、反射光を検出するためのフォトディテクタ５、レーザ光の出力端となる対物レンズ２、レーザ光を対物レンズ２を介してディスク記録面に照射し、またその反射光をフォトディテクタ５に導く光学系が形成される。
対物レンズ２は二軸機構３によってトラッキング方向及びフォーカス方向に移動可能に保持されている。
またピックアップ１全体はスレッド機構８によりディスク半径方向に移動可能とされている。
【００１０】
ディスク９０からの反射光情報はフォトディテクタ５によって検出され、受光光量に応じた電気信号とされてＲＦアンプ９に供給される。
ＲＦアンプ９には、フォトディテクタ５としての複数の受光素子からの出力電流に対応して電流電圧変換回路、マトリクス演算／増幅回路等を備え、マトリクス演算処理により必要な信号を生成する。例えば再生データであるＲＦ信号、サーボ制御のためのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥなどを生成する。
ＲＦアンプ９から出力される再生ＲＦ信号は２値化回路１１へ、フォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥはサーボプロセッサ１４へ供給される。
【００１１】
ＲＦアンプ９で得られた再生ＲＦ信号は２値化回路１１で２値化されることでいわゆるＥＦＭ信号（８−１４変調信号；ＣＤの場合）もしくはＥＦＭ＋信号（８−１６変調信号；ＤＶＤの場合）とされ、デコーダ１２に供給される。
デコーダ１２ではＥＦＭ復調、デインターリーブ、エラー訂正処理等を行ない、また必要に応じてＣＤ−ＴＥＸＴとしてのディスクにサブコードとして記録されているテキストデータのデコード、ＣＤ−ＲＯＭデコード、またはＭＰＥＧデコードなどを行なってディスク９０から読み取られた情報の再生を行なう。
【００１２】
なおデコーダ１２は、ＥＦＭ復調したオーディオデータをデータバッファとしてのキャッシュメモリ２０に蓄積していき、このキャッシュメモリ２０上でエラー訂正処理等を行う。そしてエラー訂正され適正な再生データとされた状態で、キャッシュメモリ２０へのバファリングが完了される。
また、ＣＤ−ＴＥＸＴとしてのディスク９０に記録されるテキストデータは、同じく記録されているオーディオデータとは異なってインターリーブ処理は施されておらず、またエラー訂正コードは付加されていないため、テキストデータのデコード時には、デインターリーブを行わないで、サブコードをデコードしたデータをそのままキャッシュメモリ２０にバファリングすることになる。そしてキャッシュメモリ２０上でＣＲＣチェックによるエラー検出を行うことになる。
なお後述するが、テキストデータはサブコードＰ〜Ｗのうち、Ｒ〜Ｗのデータとして記録されている。これに対してバファリング時にはＰ、Ｑも含めてキャッシュメモリ２０に取り込んでいくことになり、その後キャッシュメモリ２０に取り込まれたサブコードに対してエラー検出やテキストデータの抽出を行うものである。Ｐ、Ｑを含めてバファリングされるサブコードデータをロウデータ（ＲＡＷ＿ＤＡＴＡ・・・ディスク９０から読み出されインターリーブされていないデータ）と呼ぶこととする。
【００１３】
再生装置７０からの再生出力としては、キャッシュメモリ２０にバファリングされているデータが読み出されてインターフェース部１３から転送出力されることになる。
インターフェース部１３は、外部のホストコンピュータ８０と接続され、ホストコンピュータ８０との間で再生データやリードコマンド等の通信を行う。
即ちキャッシュメモリ２０に格納された再生データは、インターフェース部１３を介してホストコンピュータ８０に転送出力される。
またホストコンピュータ８０からのリードコマンドその他の信号はインターフェース部１３を介してシステムコントローラ１０に供給される。
【００１４】
サーボプロセッサ１４は、ＲＦアンプ９からのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥや、デコーダ１２もしくはシステムコントローラ１０からのスピンドルエラー信号ＳＰＥ等から、フォーカス、トラッキング、スレッド、スピンドルの各種サーボドライブ信号を生成しサーボ動作を実行させる。
即ちフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥに応じてフォーカスドライブ信号、トラッキングドライブ信号を生成し、二軸ドライバ１６に供給する。二軸ドライバ１６はピックアップ１における二軸機構３のフォーカスコイル、トラッキングコイルを駆動することになる。これによってピックアップ１、ＲＦアンプ９、サーボプロセッサ１４、二軸ドライバ１６、二軸機構３によるトラッキングサーボループ及びフォーカスサーボループが形成される。
【００１５】
またサーボプロセッサ１４はスピンドルモータドライバ１７に対して、スピンドルエラー信号ＳＰＥに応じて生成したスピンドルドライブ信号を供給する。スピンドルモータドライバ１７はスピンドルドライブ信号に応じて例えば３相駆動信号をスピンドルモータ６に印加し、スピンドルモータ６のＣＬＶ回転を実行させる。またサーボプロセッサ１４はシステムコントローラ１０からのスピンドルキック／ブレーキ制御信号に応じてスピンドルドライブ信号を発生させ、スピンドルモータドライバ１７によるスピンドルモータ６の起動、停止、加速、減速などの動作も実行させる。
【００１６】
なお、スピンドルモータ６のＣＬＶ回転としての線速度については、システムコントローラ１０が各種速度に設定できる。
例えばデコーダ１２は、デコード処理に用いるためにＥＦＭ信号に同期した再生クロックを生成するが、この再生クロックから現在の回転速度情報を得ることができる。システムコントローラ１０もしくはデコーダ１２は、このような現在の回転速度情報と、基準速度情報を比較することで、ＣＬＶサーボのためのスピンドルエラー信号ＳＰＥを生成する。従って、システムコントローラ１１は、基準速度情報としての値を切り換えれば、ＣＬＶ回転としての線速度を変化させることができる。例えばある通常の線速度を基準として４倍速、８倍速などの線速度を実現できる。
これによりデータ転送レートの高速化が可能となる。
なお、もちろんＣＡＶ方式であっても回転速度の切換は可能である。
【００１７】
サーボプロセッサ１４は、例えばトラッキングエラー信号ＴＥの低域成分として得られるスレッドエラー信号や、システムコントローラ１０からのアクセス実行制御などに基づいてスレッドドライブ信号を生成し、スレッドドライバ１５に供給する。スレッドドライバ１５はスレッドドライブ信号に応じてスレッド機構８を駆動する。スレッド機構８には図示しないが、ピックアップ１を保持するメインシャフト、スレッドモータ、伝達ギア等による機構を有し、スレッドドライバ１５がスレッドドライブ信号に応じてスレッドモータ８を駆動することで、ピックアップ１の所要のスライド移動が行なわれる。
【００１８】
ピックアップ１におけるレーザダイオード４はレーザドライバ１８によってレーザ発光駆動される。
システムコントローラ１０はディスク９０に対する再生動作を実行させる際に、レーザパワーの制御値をオートパワーコントロール回路１９にセットし、オートパワーコントロール回路１９はセットされたレーザパワーの値に応じてレーザ出力が行われるようにレーザドライバ１８を制御する。
【００１９】
以上のようなサーボ及びデコード、エンコードなどの各種動作はマイクロコンピュータによって形成されたシステムコントローラ１０により制御される。
そしてシステムコントローラ１０は、ホストコンピュータ８０からのコマンドに応じて各種処理を実行する。
例えばホストコンピュータ８０から、ディスク９０に記録されている或るデータの転送を求めるリードコマンドが供給された場合は、まず指示されたアドレスを目的としてシーク動作制御を行う。即ちサーボプロセッサ１４に指令を出し、シークコマンドにより指定されたアドレスをターゲットとするピックアップ１のアクセス動作を実行させる。
その後、その指示されたデータ区間のデータをホストコンピュータ８０に転送するために必要な動作制御を行う。即ちディスク９０からのデータ読出／デコード／バファリング等を行って、要求されたデータを転送する。
【００２０】
ホストコンピュータ８０からのリードコマンド、即ち転送要求としては、要求するデータ区間の最初のアドレスとなる要求スタートアドレスと、その最初のアドレスからの区間長として要求データ長（データレングス）となる。
例えば要求スタートアドレス＝Ｎ、要求データ長＝３という転送要求は、ＬＢＡ「Ｎ」〜ＬＢＡ「Ｎ＋２」の３セクターのデータ転送要求を意味する。ＬＢＡとは論理ブロックアドレス（LOGICAL BLOCK ADDRESS ）であり、ディスク９０のデータセクターに対して与えられているアドレスである。
【００２１】
２．ＴＯＣ及びサブコード
次に、ディスク９０（ＣＤ方式のディスク）においてリードインエリアに記録されるＴＯＣ、及びサブコードについて説明する。
ディスク９０において記録されるデータの最小単位は１フレームとなる。９８フレームでサブコードデータとしての１ブロック（１サブコードフレーム）が構成される。
【００２２】
１フレームの構造は図２のようになる。
１フレームは５８８ビットで構成され、先頭２４ビットが同期データと、これに続く３ビットによるマージンビットが設定され、続いて１４ビットがサブコードデータエリアとされる。そして、その後に１２シンボルのメインデータ及び４シンボルのパリティデータが配される。
【００２３】
この構成のフレームが９８フレームで１ブロックが構成され、９８個のフレームから取り出されたサブコードデータが集められて図３（ａ）のような１ブロックのサブコードデータが形成される。
９８フレームの先頭の第１、第２のフレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）からのサブコードデータは同期パターンとされている。そして、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）までで、各９６ビットのチャンネルデータ、即ちＰ，Ｑ，Ｒ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのサブコードデータが形成される。
【００２４】
このうち、アクセス等、再生に関わる各種制御には再生管理情報とされるＰチャンネルとＱチャンネルが用いられる。ただし、Ｐチャンネルはトラックとトラックの間のポーズ部分を示しているのみで、より細かい制御はＱチャンネル（Ｑ1 〜Ｑ96）によって行なわれる。９６ビットのＱチャンネルデータは図３（ｂ）のように構成される。
Ｒチャンネル〜Ｗチャンネルのデータは、テキストデータ群を形成するために設けられるが、これについては後述する。
【００２５】
まずＱ1 〜Ｑ4 の４ビットはコントロールデータとされ、オーディオのチャンネル数、エンファシス、ＣＤ−ＲＯＭの識別などに用いられる。
即ち、４ビットのコントロールデータは次のように定義される。
『０＊＊＊』・・・・２チャンネルオーディオ
『１＊＊＊』・・・・４チャンネルオーディオ
『＊０＊＊』・・・・ＣＤ−ＤＡ（ＣＤデジタルオーディオ；CD-TEXTを含む）
『＊１＊＊』・・・・ＣＤ−ＲＯＭ
『＊＊０＊』・・・・デジタルコピー不可
『＊＊１＊』・・・・デジタルコピー可
『＊＊＊０』・・・・プリエンファシスなし
『＊＊＊１』・・・・プリエンファシスあり
【００２６】
次にＱ5 〜Ｑ8 の４ビットはアドレスとされ、これはサブＱデータのコントロールビットとされている。
このアドレス４ビットが『０００１』である場合は、続くＱ9 〜Ｑ80のサブＱデータはオーディオＱデータであることを示し、また『０１００』である場合は、続くＱ9 〜Ｑ80のサブＱデータがビデオＱデータであることを示している。
そしてＱ9 〜Ｑ80で７２ビットのサブＱデータとされ、残りのＱ81〜Ｑ96はＣＲＣとされる。
【００２７】
リードインエリアにおいては、そこに記録されているサブＱデータが即ちＴＯＣ情報となる。
つまりリードインエリアから読み込まれたＱチャンネルデータにおけるＱ9 〜Ｑ80の７２ビットのサブＱデータは、図４（ａ）のような情報を有するものである。サブＱデータは各８ビットのデータを有している。
【００２８】
まずトラックナンバが記録される。リードインエリアではトラックナンバは『００』に固定される。
続いてＰＯＩＮＴ（ポイント）が記され、さらにトラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥが記録されるが、このＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥは、ＰＯＩＮＴの値によって、次に述べるように意味が決定されている。
【００２９】
ＰＯＩＮＴの値が『０１ｈ』〜『９９ｈ』（ｈは１６進表現であることを示す）のときは、その値はトラックナンバを意味し、この場合ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにおいては、そのトラックナンバのトラックのスタートポイント（絶対時間アドレス）が分（ＰＭＩＮ），秒（ＰＳＥＣ），フレーム番号（ＰＦＲＡＭＥ）として記録されている。
【００３０】
ＰＯＩＮＴの値が『Ａ０ｈ』のときは、ＰＭＩＮに最初のトラックのトラックナンバが記録される。また、ＰＳＥＣの値によってＣＤ−ＤＡ，ＣＤ−Ｉ，ＣＤ−ＲＯＭ（ＸＡ仕様）が区別される。
ＰＯＩＮＴの値が『Ａ１ｈ』のときは、ＰＭＩＮに最後のトラックのトラックナンバが記録される。
ＰＯＩＮＴの値が『Ａ２ｈ』のときは、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにリードアウトエリアのスタートポイントが絶対時間アドレスとして示される。
【００３１】
例えば６トラックが記録されたディスクの場合、このようなサブＱデータによるＴＯＣとしては図５のようにデータが記録されていることになる。
図５に示すようにトラックナンバＴＮＯは全て『００ｈ』である。
ブロックＮＯ．とは上記のように９８フレームによるブロックデータとして読み込まれた１単位のサブＱデータのナンバを示している。
各ＴＯＣデータはそれぞれ３ブロックにわたって同一内容が書かれている。
図示するようにＰＯＩＮＴが『０１ｈ』〜『０６ｈ』の場合、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥとしてトラック＃１〜トラック＃６のスタートポイントが示されている。
【００３２】
そしてＰＯＩＮＴが『Ａ０ｈ』の場合、ＰＭＩＮに最初のトラックナンバとして『０１』が示される。またＰＳＥＣの値によってディスクが識別され、このディスクがＣＤ−ＤＡ（ＣＤ−ＴＥＸＴを含む）の場合は、図示するようにＰＳＥＣ＝『００ｈ』とされる。なお、ＣＤ−ＲＯＭ（ＸＡ仕様）の場合は、ＰＳＥＣ＝『２０ｈ』、ＣＤ−Ｉ（ＣＤインタラクティブ）の場合は『１０ｈ』となる。
【００３３】
そしてＰＯＩＮＴの値として『Ａ１ｈ』の位置にＰＭＩＮに最後のトラックのトラックナンバが記録され、さらにＰＯＩＮＴの値として『Ａ２ｈ』の位置には、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにそれぞれリードアウトエリアのスタートポイントが示される。
ブロックｎ＋２７以降は、ブロックｎ〜ｎ＋２６の内容が再び繰り返して記録されている。
【００３４】
ディスク９０上で実際に音楽等のデータが記録されるトラック＃１〜＃ｎ、及びリードアウトエリアにおいては、そこに記録されているサブＱデータは図４（ｂ）に示されている情報を有する。
まずトラックナンバが記録される。即ち各トラック＃１〜＃ｎでは『０１ｈ』〜『９９ｈ』のいづれかの値となる。またリードアウトエリアではトラックナンバは『ＡＡｈ』とされる。
続いてインデックスとして各トラックをさらに細分化することができる情報が記録される。
【００３５】
そして、トラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥとして、絶対時間アドレスが分（ＡＭＩＮ），秒（ＡＳＥＣ），フレーム番号（ＡＦＲＡＭＥ）として記録されている。
【００３６】
このようにＴＯＣ及びサブコードが形成されているわけであるが、ディスク上のアドレス、即ちＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥは、９８フレーム単位で記録されることが理解される。
この９８フレーム（１ブロック）は１サブコードフレームと呼ばれ、音声データとしての１秒間には７５サブコードフレームが含まれることになる。つまり、アドレスとしての『ＡＦＲＡＭＥ』がとりうる値は『０』〜『７４』となる。なお、後述するフレームチェック処理でデータの連続性がチェックされるのは、このサブコードフレーム単位となる。
【００３７】
３．テキストデータ
以降、図２及び図３に示す構造のサブコードに含まれるテキストデータについて説明を行うこととし、先ず、図６によりテキストデータの包括的な構造について説明する。
サブコード内に含まれるテキストデータのみを抽出して構造的に見た場合、テキストデータは図６に示すようなものとなる。テキストデータとしての最も大きなデータ単位は、図６（ａ）に示す『テキストグループ』とされる。図６（ａ）においては複数のテキストグループが示されているが、各テキストグループのデータは同一内容とされており、従って、サブコード内においては、同一データ内容の所定数の複数のテキストグループが繰り返し記録されていることになる。
【００３８】
１つのテキストグループは、例えば最大２０４８パック（パックの定義については後述する）により形成するものとされるが、１テキストグループあたりのデータ読出に要する時間等を考慮して、１テキストグループを５１２パック以内により形成することが推奨されている。この際、１テキストグループあたりのデータ総量としては６５００文字程度となる。
また１つのテキストグループは、図６（ｂ）に示すようにブロック＃０〜ブロック＃ｎにより形成され、例えば最大８ブロック（０≦ｎ≦７となる）であると規定されている。各ブロックは、同一の内容の情報をそれぞれ異なる言語により表記するためのテキストデータが格納されているものとされる。例えば、ブロック＃０には、当該ディスクに対応する各種情報を英語により表記するためのテキストデータが格納されており、ブロック＃１には、ブロック＃０と内容的には同一の情報を日本語により表記するためのテキストデータが格納されているものとされる。
【００３９】
この場合、１テキストグループは最大８ブロックにより形成可能であることから、テキストデータのフォーマットとしては最大８言語に対応することが可能とされる。
１つのブロックは、図６（ｃ）に示すようにパック＃０〜パック＃ｎのデータ単位により形成される。ここでは、１ブロックは最大２５６パックで形成され情報量としては例えば３６．８６４ＫＢｙｔｅとされている。なお、パック内のデータ構造等については、次の図７、図８及び図９により説明する。
【００４０】
図７（ａ）は、図３に示した１サブコードフレームをデータ領域別に示すものであり、前述のように１サブコードフレームは９８フレームにより形成される。９８フレームの先頭の第１、第２フレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）は、図３で説明したように同期パターンＳ０，Ｓ１の領域とされる。また、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）におけるＰチャンネルはサブコードＰのデータ領域とされ、ＱチャンネルはサブコードＱのデータ領域とされて、前述したようにアクセス等の管理のためのデータが格納される。
【００４１】
そして、第３フレームから第９８フレームにおけるＲチャンネル〜Ｗチャンネルの領域は図のようにパック０〜パック４とされる。各パックのデータサイズは固定長とされて、図７（ｂ）に示すようにシンボル０〜２３の２４シンボルにより形成される。１シンボルは図７（ｃ）に示すように、１フレームにおけるＲ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのチャンネルデータよりなる６ビットのデータ単位であり、この場合にはＲチャンネルデータがＭＳＢ、ＷチャンネルがＬＳＢとして定義される。
【００４２】
図８は、上記図７（ａ）に示す構造の１サブコードフレームから、４つのパック（パック０〜パック４）によるデータ構造を抜き出して示している。
１パックは、図７で説明したように、２４のシンボル（６ビット）により形成されることから、
６ビット×２４／８＝１８バイト
で示されるように１８バイトのデータサイズを有する。そして、図のように１パックは、先頭のＩＤ領域と続くテキストデータ領域により１６バイトを占有し、残りの２バイトはＣＲＣ領域となる。
また、前述のように１サブコードフレームにおいては４つの連続したパックが設けられるが、これら４つのパックの集合により形成されるデータ単位はパケットとして定義されている。１パックは２４シンボルにより形成されることから、１パケットは、
２４（シンボル）×４（パック）＝９６（シンボル）
で示されるように９６のシンボルにより形成されるものとみることができる。
【００４３】
図９及び図１０は、図８で示した１パック分のデータをシリアルに表現したものである。
図９（ａ）から分かるように、テキストデータのフォーマットにおいては、６ビットよりなるシンボルをシリアルに配列させたうえで、このデータ列を８ビット（１バイト）ごとに区切るようにしてデータを扱うように規定されている。
【００４４】
そして図９（ｂ）及び図１０に示すように、パックの先頭からはヘッダ領域としてＩＤ１、ＩＤ２、ＩＤ３、ＩＤ４の４つのＩＤデータが設けられる。なお、ＩＤ１はＰａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ２はＴｒａｃｋ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ３はＳｅｑｕｅｎｃｅ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ４はＢｌｏｃｋ＿Ｎｕｍｂｅｒ＿ａｎｄ＿Ｃｈａｒａｃｔｅｒ＿Ｐｏｓｉｔｉｏｎ＿Ｉｎｄｉｃａｔｏｒとされる。
【００４５】
そして図９（ａ）のようにシリアルに配列されるデータを８ビット（１バイト）ごとに区切って扱うことにより、これら各ＩＤはそれぞれ８ビット（１バイト）のデータ単位とされることになる。このため、図９（ｂ）に示すように、ヘッダ領域（ＩＤ１〜ＩＤ４）以降の残りの１２バイトがテキストデータ領域として確保され、残りの２バイトがＣＲＣ領域となる。
そして、上記１２バイトのテキストデータ領域も、図１０に示すパックの構造図に示すように、８ビットごとのｔｅｘｔ１〜ｔｅｘｔ１２のデータ単位により扱われるものとされる。
【００４６】
なお以上のように各パックの先頭はヘッダ領域（ＩＤ１〜ＩＤ４）とされるが、多数のパックにより構成されるテキストグループ（図６参照）における先頭のパックのヘッダは『スタートヘッダ』と位置づけられ、テキストグループとしての先頭であることを示す特定のパターンを有するものとなる。
そして、ＴＯＣ領域（ディスクのリードイン領域）でのサブコードデータとしてテキストグループは連続して繰り返し記録されているものであるが、スタートヘッダから次のスタートヘッダの直前までのデータが、１つのテキストグループのデータ群であると識別できるようにされている。
【００４７】
ところでＣＤ方式のディスクとして、テキストデータがリードインエリアのサブコードとして記録されている方式がモード４、プログラムエリア（オーディオデータが格納されているエリア）のサブコードにテキストデータが記録されている方式がモード２とされている。
本例ではモード４を例に挙げて説明するが、本発明はモード２を適用している場合にも対応することが可能とされる。
なお参考までに、モード１はＣＤ−Ｇ（グラフィック）、モード３はＣＤ−ＭＩＤＩとされる。
【００４８】
以上のようにＣＤ−ＴＥＸＴでは、サブコードを利用してディスクのタイトル、曲名、アーティスト等の付加情報を記録するものである。
そして上記のようにこれらテキストデータはテキストグループと呼ばれる単位で繰り返し記録され、テキストグループは最大８つのブロック（最大８ヶ国語）、ブロックは最大２５６パックで構成されるので、許容される最大情報量は、３６８６４バイトとなる。
１パック（２４シンボル）×６（Ｒ〜Ｗ）×２５６（パック）×８（ブロック）＝２９４９１２ｂｉｔｓ＝３６８６４Ｂｙｔｅｓ
【００４９】
また１サブコードフレームは９８バイトから成り、同期パターンＳ０，Ｓ１を除いて９６バイトのＰ〜Ｗのデータがある。従って、最大テキストデータ量は、サブコードＰ，Ｑを考慮して、
｛３６８６４×（８／６）｝／９６＝５１２サブコードフレーム
つまり、１つのテキストグループは最大で５１２サブコードフレーム内にあることになる。
ディスク内周（リードイン領域）では、約９サブコードフレーム／トラックだとすると、およそ５７トラックに渡って１つのテキストグループが記録されている事になる。
ＣＤでは、リードイン領域がディスクの半径２３ｍｍから２５ｍｍの間に規定されていて、トラックピッチが１．６μｍであることを考慮すると、（２５００−２３００）／１．６＝１２５０トラックとなり、最大テキストデータがおよそ２２回、リードイン領域に繰り返し記録されている。
【００５０】
４．再生処理
以下、本例の再生装置におけるテキストデータの再生時の処理を説明していく。
上記したように、モード４においてはテキストデータはディスク９０のリードイン領域のサブコードデータの一部に記録されている。したがって、テキストデータを扱う場合は、まずサブコードデータ（Ｐ〜Ｗ）から不要なデータ（Ｐ、Ｑ）を排除してテキストデータ（Ｒ〜Ｗ）の抽出を行なうことになる。
この場合サブコードデータはデインターリーブ及びエラー訂正を行なわないロウデータとしてキャッシュメモリ２０に順次格納（バファリング）していく。ロウデータとしては９６バイト（９６ｂｉｔ×８（Ｐ〜Ｗ））、すなわち１フレームに相当するデータ量が１回のバファリング単位とされる。そして、キャッシュメモリ２０に格納されたサブコードデータの中から、所望するテキストデータの位置を識別する検出処理を行なう。この検出処理としてはテキストグループのスタートヘッダを検出するための処理とされる。
【００５１】
バッファリング処理としては、サブコードデータにおいて図６（ａ）に示したテキストグループの先頭とされる位置（先頭パックのヘッダに相当する）を起点とし読み出しを行なうこと望ましいが、実際にはこれは困難な処理とされる。これはＣＤのリードイン領域にはアドレスが存在しないためである。
そこで、１回の読み込みではバファリング処理を行なうに際して必要なデータが得られない場合を想定して、キャッシュメモリ２０には少なくとも２テキストグループ分のデータ量に相当するサブコードデータを格納するようにし、格納された２フレーム分のデータの中からスタートヘッダを検出するようにしている。
【００５２】
なおバファリングが開始されてから１０２４サブコードフレーム分（２５６パック×８ブロック／４（１サブコードフレームに４バック））貯えられるまでバファリングを続ける仕様も考えられるが、常にこのようにバファリングすることは、もしテキストデータが長くなかった場合には無駄なバファリングが行われることになり、時間的にもロスとなる。そこで、バファリングしながら、不要なサブコードＰ，Ｑも含んだテキストグループの先頭を示すデータパターン（スタートヘッダー）の存在を監視していくこととしている。
２つ以上のスタートヘッダーが見つかれば、最初のスタートヘッダーから次のスタートヘッダーの直前までのサブコードデータの中に、所望するテキスト情報が存在するはずである。
【００５３】
本例では、説明の都合上、サブコードのバファリングの最中に、スタートヘッダーを２つ見つけたらバファリングを止めて、テキスト情報の抜き出し及び、検証を行うものとする。
ただし、本例における最も大きな特徴は、適切なバファリングができなかった際のリトライ処理にあるので、バファリングの方法は以下説明する例に限定されず、どのようなバファリング方式でも適応できる。
【００５４】
また本例の特徴であるリトライ動作としては、ピックアップ１のアクセスを伴うアクセスリトライと、ピックアップ１のアクセスは実行しないバファリングリトライがある。
アクセスリトライは、読出リトライ時に、ディスク盤面上のアクセス位置（目的位置）を故意に変えてからテキスト情報を読み出す動作となる。一方、バファリングリトライは、ピックアップ１による読出を継続させながら、バファリングをやり直すものである。
【００５５】
上述したようにテキストグループは繰り返し記録されているため、あるテキストグループで読出が不調となっても、リトライ時にはピックアップ１の読出動作をそのまま継続させても、次のテキストグループの読出が適正に実行できる可能性がある。その様な場合はバファリングリトライが好適である。
【００５６】
一方、ディスクの読み取り面に、傷や汚れが付着している場合や、記録層の物理的状態のむらや形成ばらつき、ディスクの歪み等の原因で、情報単位が繰り返し記録されている領域内で場所により、読み出す信号品質に差異があるときはアクセスリトライが好適である。つまり信号品質が悪化する領域での情報（テキストグループ）の読み出しを避けて、信号品質が良好な領域での情報（テキストグループ）の読み出しを行う方が、得られる情報の信頼性を考慮すると得策である事は自明である。これは、ＣＤ−ＴＥＸＴのテキストデータのようにエラー訂正手段を持たず、信号品質（エラーレート）に強く依存する情報の再生に於いて有効となる。
【００５７】
以下、図１１〜図１５によりテキストデータの読出処理を具体的に説明していく。
図１１〜図１４はは、システムコントローラ１０によるテキストデータの読出処理を示すフローチャートである。
【００５８】
テキストデータの読出（即ちテキストデータのバファリング処理の開始）を指示するコマンドはホストコンピュータ８０から供給される。ここで、再生装置７０が受信するコマンドとしては、例えば「Ａ０コマンド」、「Ｐａｃｋｅｔコマンド」などのリードＴＯＣコマンドを拡張してＣＤ−ＴＥＸＴデータを読み込む処理を開始するためのコマンドとされる。
このようなコマンドを受信すると、システムコントローラ１０の処理は図１１のステップＦ１０１からＦ１０２に進み、「ＯＰコードチェック」、「ＣＤＢチェック」、「メディアチェック」などの各種チェック処理を行なう。
【００５９】
「ＯＰコードチェック」によって、受信したコマンドのＯＰコードが当該装置に対応しているものかの可否判別が行なわれ、「ＣＤＢチェック」によって、コマンド（１２バイト）の内容が規格に準拠しているかの可否判別が行なわれる。これらの判別結果が「可」とされた場合、「メディアチェック」によって、再生装置７０に装填されているディスク９０が、例えばオーディオＣＤであるか否か（つまりＣＤ−ＲＯＭ等ではなく、ＣＤ−ＴＥＸＴとしてテキストデータを有する可能性のあるディスクであるか否か）の判別が行なわれる。なお、ＣＤ−ＴＥＸＴとは種別的にはオーディオＣＤ（ＣＤ−ＤＡ）に含まれるものである。
ディスク９０がオーディオＣＤ（オーディオトラックが存在する）か否かは、上述したＴＯＣデータにより判別できる。そして通常、ＴＯＣデータはディスク装填時に読み込んでいるため、即座に判別可能である。
【００６０】
ここで、ディスク９０がオーディオＣＤでないと判別された場合は、ステップＦ１０３からＦ１０４に進み、そのとき装填されているディスク９０はテキストデータが存在しないディスクであるとしてコマンドに応じたテキスト読みだし処理を終了させる。例えばホストコンピュータ８０にエラーを返すなどの処理を行ってコマンド実行を終了する。
【００６１】
一方、オーディオＣＤであってテキストデータの存在の可能性がある場合は、ステップＦ１０５に進み、テキストデータのバファリングの準備を行う。
まずオーディオ再生モードを強制終了させる。
テキストデータの読出時には、デインターリーブやエラー訂正を行わないことで、オーディオトラックの再生時とは処理が異なることになるため、もしテキスト読出コマンドが供給された時点で、オーディオデータの再生を行っていたような場合は、その動作を強制終了させデインターリーブやエラー訂正処理をオフとすることが必要になる。またもちろん、オーディオデータはディスク９０のプログラムエリアに記録されているが、テキストデータ（モード４の場合）はリードインエリアに移行して読出を行わなければならないことからも、オーディオ再生モードを終了させる必要が生じる。
なお、モード２の場合はテキストデータはオーディオトラックのサブコードとして記録されているが、インターリーブやエラー訂正のオフの必要から、オーディオ再生モードを終了させる必要があることは同様となる。
【００６２】
続いてステップＦ１０６で、制御パラメータの初期化及びキャッシュメモリ２０のデータの破棄を行う。
キャッシュデータの破棄は、この後テキストデータのバファリングを行うために当然必要になる処理である。
また制御パラメータとしては、変数Ｍ、変数ＣＲＣＮＧのリセットを行う。変数Ｍはスタートヘッダ検出回数を示す変数、変数ＣＲＣＮＧはＣＲＣチェックでエラーとなった回数を示す変数である。
【００６３】
次にステップＦ１０７でリードイン領域へのピックアップ１のアクセスを実行させる。
このステップＦ１０７でのアクセス処理は図１２に詳しく示しているが、まずステップＦ１５１に示すように、ピックアップをプログラムエリアの先頭にアクセスさせる。
図１５にディスク９０を半径方向にみた場合のエリア構成を示しているが、ディスク９０の最内周側はリードインエリア、最外周側はリードアウトエリアとされ、その間がプログラムエリアとされてオーディオトラックが記録されている。このプログラムエリアはＣＤフォーマットの絶対時間アドレス（分／秒／フレーム）として「００：０２：００」の位置であるが、ステップＦ１５１ではまずこの位置にピックアップ１をアクセスさせる処理となる。
続いてステップＦ１５２で時変乱数αを発生させる。例えばαは０≦α≦６３の範囲でのランダムな数とする。
【００６４】
そしてステップＦ１５３で、ジャンプすべきトラック数を（２４０＋α）トラックとし、内周側へトラックジャンプを実行させる。
つまり本例ではアドレス「００：０２：００」のトラックから（２４０＋α）トラック数減算したトラックを目的としてアクセスを実行させる。この場合、フォーカスサーボはオンのまま、トラッキングサーボをオフしてピックアップを目的のトラックに向けて移動させる。そしてトラックを横切った数をカウントしていき、これをジャンプすべきトラック数と逐次比較して、その値に到達したときにステップＦ１５４からＦ１５５に進み、アクセス終了、即ち各サーボをオンにして、ピックアップの移動にブレーキをかけて静定させる。
【００６５】
ＣＤのリードインエリアでは盤面上に物理アドレスが無いため、物理アドレスを頼って目的の場所にアクセスする事ができない。そこで上記のように一度アドレスの或る領域（プログラムエリアの先頭）にアクセスを行い、そこからディスクの内周に向かってトラックを横切る本数を監視しながらジャンプして、ピックアップをリードインエリアへと移動させる。この時、ジャンプする本数を時変乱数を利用して生成すれば、アクセスするディスク盤面上の位置が毎回異なる様になる。
このようにアクセス目的がランダムに設定されることは、後述するアクセスリトライを効果的に実行するためであり、その点については後述する。
【００６６】
なお、ここで挙げたトラック数「２４０」や「α」のとりうる範囲は一例に過ぎず、再生装置の都合により決められる。
重要なのは時変乱数αを使って、アクセス先を毎回異なる様にした点である。つまり本例では図１５に目的範囲ＡＰとして示したような範囲内で、ランダムな位置にアクセスが行われることになる。
ところで、ジャンプするトラック本数のカウントは必ずしも正確ではないので、乱数を用いなくとも、２もしくはそれ以上の種類のトラックジャンプ数を設定して交互に利用するような処理方式でもよい。
【００６７】
図１２に示したアクセス処理が終了すると、システムコントローラ１０の処理は図１１のステップＦ１０８に進み、データバファリングモードを設定する。ここでは、インターリーブされておらず、またエラー訂正コードを持たないテキストデータに対応させるため、デコーダ１２等においてデインターリーブやエラー訂正処理をオフとする処理を行う。
【００６８】
以上の処理を終えたら、図１３のステップＦ１０９に進んで、サブコードデータのバファリングを開始する。
本例では、１つのサブコードフレーム単位でバファリングを行っていく。そして１つのサブコードフレーム分のデータがバファリングされる毎に、ステップＦ１１０からＦ１１１に進み、ＣＲＣチェックを行う。
上述したように１つのサブコードフレームには４つのパックが含まれるが、各パックについてのＣＲＣチェックを行い、全てのパックのＣＲＣチェックがＯＫであれば、バファリングしたロウデータ（サブコードデータ）の信頼性が確保されたとする。つまりＣＲＣチェックＯＫとしてステップＦ１１２に進む。
一方、１つでもＣＲＣエラーとなったパックが存在した場合は、バファリングしたサブコードの信頼性が確保できないとして、ステップＦ１１８に進んでリトライ判別処理を行い、必要なリトライ動作を実行することになる。
【００６９】
４つのパックのＣＲＣチェックがＯＫでステップＦ１１２に進んだ場合は、スタートヘッダの有無のチェックを行う。
即ちバファリングされた４つのパックの各ヘッダにおいて、テキストグループの先頭であることを示す特定のパターンであるスタートヘッダとされているものが存在するか否かを確認する。
４つのパックのうちにスタートヘッダが存在しない場合は、そのままステップＦ１１７に進んで、バファリング処理を継続し、同様の処理を繰り返す。
【００７０】
４つのパックのうちにスタートヘッダが存在した場合、つまり４つのパックのうちのいずれかがテキストグループの先頭のパックであった場合は、ステップＦ１１３に進んでスタートヘッダ検出回数を示す変数Ｍをインクリメントし、ステップＦ１１４で変数Ｍ＝２であるか否かを判別する。
変数Ｍ＝２でなければステップＦ１１７に進んで、バファリング処理を継続する。
【００７１】
もしバファリングの過程でＣＲＣエラーとなることがないままスタートヘッダが２回確認された場合や、もしくはＣＲＣエラーとなっても後述するリトライ処理を行うことで、データの信頼性が確保された状態でのバファリングデータの中でスタートヘッダが２回確認された場合は、ステップＦ１１４からＦ１１５に進み、サブコードのバファリングを終了する。
つまり、スタートヘッダが２回検出できたということは、バファリングされたデータとして最初のスタートヘッダから次のスタートヘッダまでの直前のデータとして、１つのテキストグループが確保されていることになるため、バファリング完了と判断するものである。
そしてステップＦ１１６で、バファリングされたローパスフィルタデータとしてのサブコードからＰ、Ｑデータの除去や必要なデコード処理などを行って、テキストグループを構成するテキストデータを抽出し、ホストコンピュータ８０に転送する処理を行うことになる。そして転送処理を終えることで、コマンドに応じたテキスト再生動作を終了させる。
【００７２】
ところで上記のようにステップＦ１１１でＣＲＣエラーとなった場合は、ステップＦ１１８のリトライ判別処理に移ることになる。
このリトライ判別処理は図１４に詳しく示される。
【００７３】
まずステップＦ１７１で、ＣＲＣエラーとなったことに応じてＣＲＣエラー回数を示す変数ＣＲＣＮＧをインクリメントする。
次にステップＦ１７２で、ＣＲＣエラーとる直前までにキャッシュメモリ２０に確保されているロウデータ（サブコードデータ）の有効性を判断し、有効なロウデータとしてサブコードフレームが１０２４フレーム以上確保されているか否かを確認する。
テキストグループの最大長は、２５６パック×８ブロック＝２０４８パックであり、１サブコードフレームに４パック存在するため、テキストグループの最大長＝５１２サブコードフレームとなる。従って１０２４サブコードフレームとは、最大長のテキストグループの２つ分のデータ量に相当する。
この１０２４この有効なサブコードフレームが既に確保されている場合とは、そのバファリングデータ中には１つのテキストグループが確保されている場合であることを意味する。従って、その場合はステップＦ１７２から図１３のステップＦ１１５に進み、バファリングを終了し、テキストデータの抽出／転送処理に移行してよい。
【００７４】
また、有効なサブコードフレームが１０２４個未満であった場合でも、ステップＦ１７３でＭ＝２、つまりスタートヘッダが２回確認されていることが検出できれば、その場合も、１つのテキストグループ分のデータが確保されていることになるため、図１３のステップＦ１１５に進み、バファリングを終了し、テキストデータの抽出／転送処理に移行してよい。
【００７５】
このステップＦ１７２、Ｆ１７３の処理は例えば何らかの事情で図１３のステップＦ１１２でのスタートヘッダ検出が良好にできなかった場合などにおいてステップＦ１１８のリトライ判別処理に進んだ場合などに、実際は不要となるリトライ処理が実行されてしまうことを防止するためのものとなる。
【００７６】
１つのテキストグループがキャッシュメモリ２０内に確保できておらず、実際にリトライ処理が必要になった場合は、まずステップＦ１７４で変数Ｍ＝１であるか否かを判断する。
変数＝１であって、すでに１回スタートヘッダが検出されている場合は、ステップＦ１７８に進んで、制御パラメータの初期化、つまり、変数Ｍ、変数ＣＲＣＮＧのリセットを行うとともに、キャッシュメモリ２０のデータの破棄を行う。そしてステップＦ１７９でバファリングリトライ開始として図１１のステップＦ１０８に進み、上述してきたバファリング動作を行う。
【００７７】
このバファリングリトライとは、単にキャッシュメモリ２０内のデータを破棄し、一方ピックアップ１の位置はそのままで、バファリングのリトライを行うものである。
【００７８】
ピックアップ１のアクセスを伴わないでリトライを行う理由は次の通りである。
まず、既にスタートヘッダが１回検出されていることから、現在トレースしているピックアップ位置でのテキストデータ再生に関するディスク９０のリーダビリティはさほど悪くないと判断でき、従って、ピックアップ１はそのまま現状の位置からトレースを行っていれば、テキストグループの抽出（２つのスタートヘッダ検出）が完了する可能性が高いためである。
また、このようにアクセスを行わないでもリトライを成功に導く可能性が高い場合には、アクセスを実行することで無駄な時間を浪費することや、場合によってはリーダビリティの良くない場所にアクセスしてしまい、再びＣＲＣエラーを招く可能性が生じることを避けるという意味もある。
【００７９】
一方、ステップＦ１７４でＭ＝１ではないと判断された場合は、ステップＦ１７５に進んで、バファリングされている有効なサブコードフレームが、ある設定値Ｎ（Ｎ≧１）以上であるか否かを判別する。
設定値Ｎとは、再生装置７０の都合で決められるパラメータであり、これはディスク９０がテキストデータを記録したディスクであるか否かを判別するためのしきい値となる。
【００８０】
有効なサブコードフレーム数が設定値Ｎを越えていなかった場合は、ステップＦ１７６で、変数ＣＲＣＮＧが６４を越えているか否かを判断する。
そして変数ＣＲＣＮＧが６４を越えていなければ、図１３のステップＦ１１７に戻って、その時点ではリトライは行わずにバファリング処理を継続する。
【００８１】
もし、ある時点でステップＦ１７５で有効なサブコードフレーム数が設定値Ｎを越えておらず、しかも、ステップＦ１７６で、変数ＣＲＣＮＧが６４を越えていると判断された場合は、ステップＦ１８１で、現在のディスク９０にはテキストデータは存在しないと判断し、図１１のステップＦ１０４に進んで、ホストコンピュータ８０にエラー（テキスト無し）を返して処理を終了する。
【００８２】
これはディスク９０がテキストデータの記録されていないオーディオＣＤであった場合の処理となる。
そしてテキスト再生時には上記のようにデインターリーブがオフとされていることから、ディスク９０としてテキストデータのないオーディオＣＤが装填されていた場合は、全てのサブコードフレームのバファリング時にＣＲＣエラーとなる。従ってステップＦ１７６から図１３のＦ１１７に戻ってサブコードフレーム単位でバファリングが行われていくと、６４個目のサブコードフレームのバファリングにおいてステップＦ１７６で変数ＣＲＣＮＧが６４となる。
つまりバファリングを開始してからわずか６４サブコードフレームのバファリングを行った時点で、そのディスク９０にはテキストデータが存在しないことを確認でき、換言すれば、ディスク９０にテキストデータが存在しない場合には、バファリング開始後、非常に迅速にテキストデータが存在しないとして処理を終了させることができる。従って無駄な動作がいつまでも行われることはない。
【００８３】
なお、ＣＲＣＮＧが「６４」以上となったことでテキストデータ無しと判断するのは、テキストグループを構成する１つのブロックが最大２５６パックからなることによる（２５６パック＝６４サブコードフレーム）。
【００８４】
ディスク９０がテキストデータが含まれるＣＤ−ＴＥＸＴであった場合には、有効サブコードフレーム数がＮ未満のまま変数ＣＲＣＮＧが６４に達することはまずない。
これも換言すれば、ＣＤ−ＴＥＸＴの場合は、変数ＣＲＣＮＧが６４に達するよりも早く、ステップＦ１７５で有効サブコードフレーム数がＮ以上となることを意味する。
【００８５】
この場合は、ステップＦ１７７で変数ＣＲＣＮＧがある許容数未満であれば、リトライ動作に移行しないまま、図１３のＦ１１７に戻ってサブコードフレーム単位でバファリングを継続する。
ある時点で、ステップＦ１７７で変数ＣＲＣＮＧがある許容数以上となったことが検出された場合は、ステップＦ１８０に進んでアクセスリトライを行うことになる。
【００８６】
即ち図１１のステップＦ１０６に進んで、制御パラメータの初期化、つまり、変数Ｍ、変数ＣＲＣＮＧのリセットを行うとともに、キャッシュメモリ２０のデータの破棄を行う。そしてステップＦ１０７で、上記図１２の処理としてのアクセスを実行する。つまり上述した時変乱数を利用することで、最初にアクセスした場所と異なる場所にアクセスする。そしてステップＦ１０８以降、バファリングを再開する。
【００８７】
このアクセスリトライとは、キャッシュメモリ２０内のデータを破棄するとともに、ピックアップ１の位置も変更させるものである。
このアクセスリトライを行う理由は次のようになる。
変数ＣＲＣＮＧの数が許容値を超えるということは、少なくとも現在ピックアップ１でトレースしている位置は、テキストデータ再生におけるリーダビリティが悪いと判断できるものである。この場合、そのままの位置でピックアップ１によるトレースを続行しても、適正なバファリングができる確率が低い。場合によってはいつまでたっても有効なサブコードデータが確保できない可能性もある。そこでその様な場合は、アクセスリトライによりピックアップ１のトレース位置を変更させて、リトライを行うことが好適となる。
例えばリトライ前のトレース位置が、傷や汚れの影響でリーダビリティが悪化していたような場合は、トレース位置を変更させることで、適正な読出が可能となる確率が大幅に向上する。
【００８８】
以上のように本例では、ＣＲＣエラーの場合に、状況に応じてバファリングリトライとアクセスリトライを使い分けるようにしており、これによってＣＲＣエラーとなった原因等に応じて最も適切なリトライが可能となる。
即ちリトライ動作としてアクセスが不要と判断できる場合、つまりリーダビリティがさほど悪くなく、そのまま読出を続行させることが有利であると判断された場合はバファリングリトライを行うようにし、一方、読出位置（トレース位置）を変えた方が良いと判断される場合はアクセスリトライを行なうようにしているため、状況に応じて最も適切なリトライ動作が実行されることになり、データ読込の成功率を格段に向上させることができるとともに、リトライ動作が効率化され、短時間で読み込み成功に導くことができるという効果がある。
【００８９】
ところで本出願人は、以上のような本例の処理の効果を確認する実験を行った。
まず市販されているＣＤ−ＴＥＸＴ（テキストデータ量１６６０バイト）を、ＣＤ−Ｒにコピーし、かつそれをリーダビリティの悪いディスクとして作成した。Ｃ１エラーレートは最大５０／ｓｅｃとなるディスクであった。そしてそのディスクを用いて、ファームウエアＡ、Ｂ、Ｃの各場合でテキストデータ読出の実験を行った。
【００９０】
ファームウエアＡは、変数ＣＲＣＮＧ数が許容値を越えた場合に従来方式のリトライを行うものである。つまりリトライ時にはピックアップアクセスを伴うが、本例のようにアクセス位置をランダムに変更することは行わないもの（つまり図１２のステップＦ１５２の処理がなく、ステップＦ１５３でα＝０となる処理）である。
ファームウエアＢは、本例でいうアクセスリトライを行うのみで、バファリングリトライは実行しないものである。
ファームウエアＣは本例の処理を行うものである。
この実験の結果は図１６のようになり、つまり本例（ファームウエアＣ）による処理では、リーダビリティの悪いディスクであっても安定にデータ読出ができることが確認された。
【００９１】
なお、本発明は、テキストデータがディスク９０のプログラムエリアに記録されている「モード２」に対しても適用することができる。
またテキストデータがプログラムエリアに記録されるモード２の場合は、アドレスにたよってアクセスを行うことができるため、アクセスリトライの際に、毎回異なる目標アドレスを設定してアクセスを行うことが可能となる。
【００９２】
また本発明はＣＤ−ＴＥＸＴ以外のＣＤ方式のディスクや、ＤＶＤなど、他の種のディスクであっても、同じ内容が繰り返し記録されているデータの読出処理に広く適用できるものである。
繰り返し記録されるデータの例としては、具体的には、ＣＤのＴＯＣデータ、ＤＶＤのリードインデータ、書換可能なＤＶＤのディフェクト管理情報などがある。
もちろん繰り返しデータの記録エリアとしてのアドレスの有無に限らず適用できる。
【００９３】
【発明の効果】
以上、説明したように本発明では、ＣＤ−ＴＥＸＴにおけるテキストデータなどの、１つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データ（例えば上述したスタートヘッダ）がバファリングされている場合は、読出位置のアクセスを伴わない第１のリトライ動作（バファリングリトライ）を実行させ、一方、そのグループの先頭データがバファリングされていない場合は読出位置のアクセスを伴なう第２のリトライ動作（アクセスリトライ）を実行させるようにしている。
即ちリトライ動作としてアクセスが不要と判断できる場合、つまりデータが繰り返し記録されているためそのまま読出を続行させることが有利であると判断された場合は第１のリトライ動作を行うようにし、一方、読出位置を変えた方が良いと判断される場合は第２のリトライ動作を行なうようにしているため、状況に応じて最も適切なリトライ動作が実行されることになり、データ読込の成功率を格段に向上させることができるとともに、リトライ動作が効率化され、短時間で読み込み成功に導くことができるという効果がある。
【００９４】
またリトライの実行判断は、格納手段へバッファリングされたデータについてエラーが検出されたか否かにより行うことで、適切にリトライ動作に移行できるという効果がある。
また、第２のリトライ動作が実行される場合に、読出位置のアクセスは、そのアクセス目的位置が所定範囲内でランダムに選択されることで、第２のリトライ動作のたびに、読出位置が変わることになる。これは例えば記録媒体上の傷や汚れなどにより読み込みエラーとなったような場合に、その部位を避けることができることになり、従ってリトライ時の読込成功率を大きく向上させる一因となる。なお、読出位置が変わっても、グループデータは繰り返し記録されているものであるため、必要なデータの読出には支障はない。
【００９５】
また、バッファリングされたデータについて所定数以上のエラーが検出された場合には、読み出すべきグループデータが存在しないとしてリトライ動作を実行させずに動作を終了させることで、そもそも読出が不可能な場合にリトライ動作を繰り返してしまうというような無駄な動作を避けることができるという効果がある。
【図面の簡単な説明】
【図１】本発明の実施の形態の再生装置のブロック図である。
【図２】ディスク（ＣＤ）のフレーム構造の説明図である。
【図３】ディスク（ＣＤ）のサブコーディングの説明図である。
【図４】ディスク（ＣＤ）のサブＱデータの説明図である。
【図５】ディスク（ＣＤ）のＴＯＣデータの説明図である。
【図６】テキストデータの構造を包括的に示す説明図である。
【図７】サブコードフレームとテキストデータとの構造的な関係を示す説明図である。
【図８】テキストデータとしてパケットの構造を示す説明図である。
【図９】テキストデータの構造として、シンボル単位のデータからパックを形成する過程を説明するための説明図である。
【図１０】パックの構造を示す説明図である。
【図１１】実施の形態のテキストデータ読出時の処理のフローチャートである。
【図１２】実施の形態のテキストデータ読出時におけるアクセス処理のフローチャートである。
【図１３】実施の形態のテキストデータ読出時の処理のフローチャートである。
【図１４】実施の形態のテキストデータ読出時におけるリトライ判別処理のフローチャートである。
【図１５】実施の形態のアクセス動作の説明図である。
【図１６】実施の形態の効果を確認する実験結果の説明図である。
【符号の説明】
１  ピックアップ、９  ＲＦアンプ、１０  システムコントローラ、１２  デコーダ、１３  インターフェース部、１４  サーボプロセッサ、２０  キャッシュメモリ、７０  再生装置、８０  ホストコンピュータ、９０  ディスク
【図１】
0003921858.tif 000002
【図２】
0003921858.tif 000003
【図３】
0003921858.tif 000004
【図４】
0003921858.tif 000005
【図５】
0003921858.tif 000006
【図６】
0003921858.tif 000007
【図７】
0003921858.tif 000008
【図８】
0003921858.tif 000009
【図９】
0003921858.tif 000010
【図１０】
0003921858.tif 000011
【図１１】
0003921858.tif 000012
【図１２】
0003921858.tif 000013
【図１３】
0003921858.tif 000014
【図１４】
0003921858.tif 000015
【図１５】
0003921858.tif 000016
【図１６】
0003921858.tif 000017