JP4092804B2 - 再生装置 - Google Patents
再生装置 Download PDFInfo
- Publication number
- JP4092804B2 JP4092804B2 JP00794699A JP794699A JP4092804B2 JP 4092804 B2 JP4092804 B2 JP 4092804B2 JP 00794699 A JP00794699 A JP 00794699A JP 794699 A JP794699 A JP 794699A JP 4092804 B2 JP4092804 B2 JP 4092804B2
- Authority
- JP
- Japan
- Prior art keywords
- management information
- information
- data
- header
- character
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ＣＤ−ＴＥＸＴに記憶されている文字情報を再生することができる再生装置に関するものである。
【０００２】
【従来の技術】
例えばオーディオ用のＣＤ（COMPACT DISC）のフォーマットに準拠した上で、そのサブコードデータとして所要の文字情報を記憶したＣＤ−ＴＥＸＴが知られている。記憶される文字情報としては、例えばディスクのタイトルやアーティスト名、楽曲名などの情報とされ、これらの情報を読み出して表示することによって、そのオーディオＣＤに収録されてる情報の内容などを文字で得ることが可能である。
【０００３】
【発明が解決しようとする課題】
しかし、ＣＤ−ＴＥＸＴは、ＥＣＣなどのエラー訂正手段を有していないことが例えばＣＤ−ＲＯＭなどと異なっている。したがって、再生状況によっては、正規のデータが検出されず、これにより文字情報の始まりと終わりが正しく検出することができないという不具合が生じることがあった。
また、文字情報が前記リードイン領域に記憶されている場合は、ディスクのアドレスに基づいたリトライ処理を有効に行なうことができない。
即ち、従来では読み出されたデータにおける文字情報が確かなものか否かを判断することができなかった。
【０００４】
【課題を解決するための手段】
本発明はこのような問題点を解決するために、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された、前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される第一のヘッダ情報を起点とした順方向における所定の位置のデータ内容を検証する第一の検証手段と、前記第一のヘッダ情報に続いて検出される第二のヘッダ情報を起点とした逆方向における所定の位置のデータ内容を検証する第二の検証手段と、前記第一、第二の検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であるか否かを判断することができる判断手段を備えて再生装置を構成する。
【０００５】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される第一のヘッダ情報と、該第一のヘッダ情報に続いて検出される第二のヘッダ情報の間の所定の位置にあるデータ内容が、前記文字情報において規定されている所定のデータ内容に一致しているか否かを検証する検証手段と、前記検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であると判断することができる判断手段を備えて再生装置を構成する。
【０００６】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、ヘッダ情報検出手段によって検出される前記ヘッダ情報の間にあるデータを一つの単位として複数単位のデータの内容を比較を行ない、比較したデータの内容が同等であった場合に、当該データが前記文字情報として有効であると判断することができる判断手段を備えて再生装置を構成する。
【０００７】
さらに、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される所要のヘッダ情報に基づいて文字情報の検証処理を行なう検証手段を備え、前記ヘッダ情報検出手段によって所要のヘッダ情報が２回検出された場合、前記再生手段による前記管理情報の読み出しを終了するとともに、前記管理情報検出手段による前記管理情報の検出を終了したうえで、前記検証手段は前記ヘッダ情報に基づいた前記文字情報の検証処理を行なうように再生装置を構成する。
【０００８】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を所定の単位毎に順次格納することができるようにされている管理情報記憶手段と、前記文字情報に対する誤り検出符号に基づいて、前記管理情報記憶手段に格納される前記管理情報に含まれる前記文字情報の誤り検出を行う誤り検出手段と、前記管理情報記憶手段に前記所定の単位とされる前記管理情報が格納された場合に、格納された前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記誤り検出手段によって前記管理情報記憶手段に格納されている前記文字情報に誤りが検出された場合に、前記ヘッダ情報検出手段によって前記ヘッダ情報が検出されないまま、それまでに前記誤り検出手段によって検出された前記文字情報の誤り回数が前記管理情報の所定の単位数以上となったら、前記記録媒体に前記文字情報が記憶されていないと判別するようにした文字情報有無識別手段を備えて再生装置を構成する。
【０００９】
本発明によれば、記録媒体から読み込んだ管理情報から、この管理情報に含まれる文字情報を示すヘッダ情報に対応した各種データ内容を検証し、所定のデータ内容が検出され場合に、当該ヘッダ情報に対応した文字情報の有効性を確認することができるようにしている。
これにより、文字情報の誤検出を抑制し検出能力を向上させることができ、より正確な文字情報を得ることができるようになる。
【００１０】
また、所定数のヘッダ情報が２回検出された時点で、管理情報の検出を終了したうえで文字情報の検証処理を行なうようにすることにより、それ以降行なう検証処理の処理負担を軽減することができるようになる。
【００１１】
さらに、前記文字情報に対する誤り検出符号に基づいて、当該文字情報に誤りが検出されたときに、ヘッダ情報が検出されないまま、それまでに前記文字情報の誤りが所定回数以上検出されていた場合には、記録媒体に文字情報が記録されていないと判断するようにしているので、必要以上の再生動作を抑制したうえで、記録媒体の種別を識別することができるようになる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態として、ＣＤ−ＴＥＸＴとしてのディスクに対応して、オーディオデータ及びサブコードとしての文字情報を再生することができる再生装置を例に挙げて次に示す順序で説明する。なお、サブコードとして記録される文字情報を「テキストデータ」ともいうこととする。
＜１．再生装置の構成＞
＜２．ＴＯＣ及びサブコード＞
＜３．テキストデータ＞
＜４．再生処理＞
＜５．バファリング処理＞
＜６．８ビット／６ビット変換＞
＜７．テキストデータ有効性検証処理＞
＜８．データ例＞
＜９．変形例＞
【００１３】
１．再生装置の構成
本実施の形態の再生装置に装填される光ディスクは、例えばＣＤ−ＴＥＸＴなどのＣＤ方式のディスクや、ＤＶＤなどが考えられる。もちろん他の種類の光ディスクに対応する再生装置でも本発明は適用できるものである。
【００１４】
図１は本例の再生装置７０の要部のブロック図である。
ディスク９０は、ターンテーブル７に積載され、再生動作時においてスピンドルモータ６によって一定線速度（ＣＬＶ）もしくは一定角速度（ＣＡＶ）で回転駆動される。そしてピックアップ１によってディスク９０にエンボスピット形態や相変化ピット形態などで記録されているデータの読み出しが行なわれることになる。なお本例ではＣＬＶ方式として説明を続ける。
【００１５】
ピックアップ１内には、レーザ光源となるレーザダイオード４や、反射光を検出するためのフォトディテクタ５、レーザ光の出力端となる対物レンズ２、レーザ光を対物レンズ２を介してディスク記録面に照射し、またその反射光をフォトディテクタ５に導く光学系が形成される。
対物レンズ２は二軸機構３によってトラッキング方向及びフォーカス方向に移動可能に保持されている。
またピックアップ１全体はスレッド機構８によりディスク半径方向に移動可能とされている。
【００１６】
ディスク９０からの反射光情報はフォトディテクタ５によって検出され、受光光量に応じた電気信号とされてＲＦアンプ９に供給される。
ＲＦアンプ９には、フォトディテクタ５としての複数の受光素子からの出力電流に対応して電流電圧変換回路、マトリクス演算／増幅回路等を備え、マトリクス演算処理により必要な信号を生成する。例えば再生データであるＲＦ信号、サーボ制御のためのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥなどを生成する。
ＲＦアンプ９から出力される再生ＲＦ信号は２値化回路１１へ、フォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥはサーボプロセッサ１４へ供給される。
【００１７】
ＲＦアンプ９で得られた再生ＲＦ信号は２値化回路１１で２値化されることでいわゆるＥＦＭ信号（８−１４変調信号；ＣＤの場合）もしくはＥＦＭ＋信号（８−１６変調信号；ＤＶＤの場合）とされ、デコーダ１２に供給される。デコーダ１２ではＥＦＭ復調，エラー訂正処理等を行ない、また必要に応じてＣＤ−ＴＥＸＴデコード、ＣＤ−ＲＯＭデコード、またはＭＰＥＧデコードなどを行なってディスク９０から読み取られた情報の再生を行なう。
【００１８】
なおデコーダ１２は、ＥＦＭ復調したデータをデータバッファとしてのキャッシュメモリ２０に蓄積していき、このキャッシュメモリ２０上でエラー訂正処理等を行う。そしてエラー訂正され適正な再生データとされた状態で、キャッシュメモリ２０へのバファリングが完了される。また、本例ではＣＤ−ＴＥＸＴデータを検証する際のローデータ（ＲＡＷ＿ＤＡＴＡ・・・ディスク９０から読み出されインターリーブされていないデータ）のバッファリングエリアとしても用いられる。なお、ローデータのバッファリング処理については後述する。
再生装置７０からの再生出力としては、キャッシュメモリ２０でバファリングされているデータが読み出されて転送出力されることになる。
【００１９】
インターフェース部１３は、外部のホストコンピュータ８０と接続され、ホストコンピュータ８０との間で再生データやリードコマンド等の通信を行う。
即ちキャッシュメモリ２０に格納された再生データは、インターフェース部１３を介してホストコンピュータ８０に転送出力される。
またホストコンピュータ８０からのリードコマンドその他の信号はインターフェース部１３を介してシステムコントローラ１０に供給される。
【００２０】
サーボプロセッサ１４は、ＲＦアンプ９からのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥや、デコーダ１２もしくはシステムコントローラ１０からのスピンドルエラー信号ＳＰＥ等から、フォーカス、トラッキング、スレッド、スピンドルの各種サーボドライブ信号を生成しサーボ動作を実行させる。
即ちフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥに応じてフォーカスドライブ信号、トラッキングドライブ信号を生成し、二軸ドライバ１６に供給する。二軸ドライバ１６はピックアップ１における二軸機構３のフォーカスコイル、トラッキングコイルを駆動することになる。これによってピックアップ１、ＲＦアンプ９、サーボプロセッサ１４、二軸ドライバ１６、二軸機構３によるトラッキングサーボループ及びフォーカスサーボループが形成される。
【００２１】
またサーボプロセッサ１４はスピンドルモータドライバ１７に対して、スピンドルエラー信号ＳＰＥに応じて生成したスピンドルドライブ信号を供給する。スピンドルモータドライバ１７はスピンドルドライブ信号に応じて例えば３相駆動信号をスピンドルモータ６に印加し、スピンドルモータ６のＣＬＶ回転を実行させる。またサーボプロセッサ１４はシステムコントローラ１０からのスピンドルキック／ブレーキ制御信号に応じてスピンドルドライブ信号を発生させ、スピンドルモータドライバ１７によるスピンドルモータ６の起動、停止、加速、減速などの動作も実行させる。
【００２２】
なお、スピンドルモータ６のＣＬＶ回転としての線速度については、システムコントローラ１０が各種速度に設定できる。
例えばデコーダ１２は、デコード処理に用いるためにＥＦＭ信号に同期した再生クロックを生成するが、この再生クロックから現在の回転速度情報を得ることができる。システムコントローラ１０もしくはデコーダ１２は、このような現在の回転速度情報と、基準速度情報を比較することで、ＣＬＶサーボのためのスピンドルエラー信号ＳＰＥを生成する。従って、システムコントローラ１１は、基準速度情報としての値を切り換えれば、ＣＬＶ回転としての線速度を変化させることができる。例えばある通常の線速度を基準として４倍速、８倍速などの線速度を実現できる。
これによりデータ転送レートの高速化が可能となる。
なお、もちろんＣＡＶ方式であっても回転速度の切換は可能である。
【００２３】
サーボプロセッサ１４は、例えばトラッキングエラー信号ＴＥの低域成分として得られるスレッドエラー信号や、システムコントローラ１０からのアクセス実行制御などに基づいてスレッドドライブ信号を生成し、スレッドドライバ１５に供給する。スレッドドライバ１５はスレッドドライブ信号に応じてスレッド機構８を駆動する。スレッド機構８には図示しないが、ピックアップ１を保持するメインシャフト、スレッドモータ、伝達ギア等による機構を有し、スレッドドライバ１５がスレッドドライブ信号に応じてスレッドモータ８を駆動することで、ピックアップ１の所要のスライド移動が行なわれる。
【００２４】
ピックアップ１におけるレーザダイオード４はレーザドライバ１８によってレーザ発光駆動される。
システムコントローラ１０はディスク９０に対する再生動作を実行させる際に、レーザパワーの制御値をオートパワーコントロール回路１９にセットし、オートパワーコントロール回路１９はセットされたレーザパワーの値に応じてレーザ出力が行われるようにレーザドライバ１８を制御する。
【００２５】
以上のようなサーボ及びデコード、エンコードなどの各種動作はマイクロコンピュータによって形成されたシステムコントローラ１０により制御される。
そしてシステムコントローラ１０は、ホストコンピュータ８０からのコマンドに応じて各種処理を実行する。
例えばホストコンピュータ８０から、ディスク９０に記録されている或るデータの転送を求めるリードコマンドが供給された場合は、まず指示されたアドレスを目的としてシーク動作制御を行う。即ちサーボプロセッサ１４に指令を出し、シークコマンドにより指定されたアドレスをターゲットとするピックアップ１のアクセス動作を実行させる。
その後、その指示されたデータ区間のデータをホストコンピュータ８０に転送するために必要な動作制御を行う。即ちディスク９０からのデータ読出／デコード／バファリング等を行って、要求されたデータを転送する。
【００２６】
ホストコンピュータ８０からのリードコマンド、即ち転送要求としては、要求するデータ区間の最初のアドレスとなる要求スタートアドレスと、その最初のアドレスからの区間長として要求データ長（データレングス）となる。
例えば要求スタートアドレス＝Ｎ、要求データ長＝３という転送要求は、ＬＢＡ「Ｎ」〜ＬＢＡ「Ｎ＋２」の３セクターのデータ転送要求を意味する。ＬＢＡとは論理ブロックアドレス（LOGICAL BLOCK ADDRESS ）であり、ディスク９０のデータセクターに対して与えられているアドレスである。
【００２７】
２．ＴＯＣ及びサブコード
次に、ディスク９０においてリードインエリアに記録されるＴＯＣ、及びサブコードについて説明する。
ディスク９０において記録されるデータの最小単位は１フレームとなる。９８フレームで１ブロック（１サブコーディングフレーム）が構成される。
【００２８】
１フレームの構造は図２のようになる。
１フレームは５８８ビットで構成され、先頭２４ビットが同期データと、これに続く３ビットによるマージンビットが設定され、続いて１４ビットがサブコードデータエリアとされる。そして、その後に１２シンボルのメインデータ及び４シンボルのパリティデータが配される。
【００２９】
この構成のフレームが９８フレームで１ブロックが構成され、９８個のフレームから取り出されたサブコードデータが集められて図３（ａ）のような１ブロックのサブコードデータが形成される。
９８フレームの先頭の第１、第２のフレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）からのサブコードデータは同期パターンとされている。そして、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）までで、各９６ビットのチャンネルデータ、即ちＰ，Ｑ，Ｒ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのサブコードデータが形成される。
【００３０】
このうち、アクセス等、再生に関わる各種制御には再生管理情報とされるＰチャンネルとＱチャンネルが用いられる。但し、Ｐチャンネルはトラックとトラックの間のポーズ部分を示しているのみで、より細かい制御はＱチャンネル（Ｑ1 〜Ｑ96）によって行なわれる。９６ビットのＱチャンネルデータは図３（ｂ）のように構成される。
Ｒチャンネル〜Ｗチャンネルのデータは、テキストデータ群を形成するために設けられるが、これについては後述する。
【００３１】
まずＱ1 〜Ｑ4 の４ビットはコントロールデータとされ、オーディオのチャンネル数、エンファシス、ＣＤ−ＲＯＭの識別などに用いられる。
即ち、４ビットのコントロールデータは次のように定義される。
『０＊＊＊』・・・・２チャンネルオーディオ
『１＊＊＊』・・・・４チャンネルオーディオ
『＊０＊＊』・・・・ＣＤ−ＤＡ（ＣＤデジタルオーディオ；CD-TEXTを含む）
『＊１＊＊』・・・・ＣＤ−ＲＯＭ
『＊＊０＊』・・・・デジタルコピー不可
『＊＊１＊』・・・・デジタルコピー可
『＊＊＊０』・・・・プリエンファシスなし
『＊＊＊１』・・・・プリエンファシスあり
【００３２】
次にＱ5 〜Ｑ8 の４ビットはアドレスとされ、これはサブＱデータのコントロールビットとされている。
このアドレス４ビットが『０００１』である場合は、続くＱ9 〜Ｑ80のサブＱデータはオーディオＱデータであることを示し、また『０１００』である場合は、続くＱ9 〜Ｑ80のサブＱデータがビデオＱデータであることを示している。
そしてＱ9 〜Ｑ80で７２ビットのサブＱデータとされ、残りのＱ81〜Ｑ96はＣＲＣとされる。
【００３３】
リードインエリアにおいては、そこに記録されているサブＱデータが即ちＴＯＣ情報となる。
つまりリードインエリアから読み込まれたＱチャンネルデータにおけるＱ9 〜Ｑ80の７２ビットのサブＱデータは、図４（ａ）のような情報を有するものである。サブＱデータは各８ビットのデータを有している。
【００３４】
まずトラックナンバが記録される。リードインエリアではトラックナンバは『００』に固定される。
続いてＰＯＩＮＴ（ポイント）が記され、さらにトラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥが記録されるが、このＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥは、ＰＯＩＮＴの値によって、次に述べるように意味が決定されている。
【００３５】
ＰＯＩＮＴの値が『０１ｈ』〜『９９ｈ』（ｈは１６進表現であることを示す）のときは、その値はトラックナンバを意味し、この場合ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにおいては、そのトラックナンバのトラックのスタートポイント（絶対時間アドレス）が分（ＰＭＩＮ），秒（ＰＳＥＣ），フレーム番号（ＰＦＲＡＭＥ）として記録されている。
【００３６】
ＰＯＩＮＴの値が『Ａ０ｈ』のときは、ＰＭＩＮに最初のトラックのトラックナンバが記録される。また、ＰＳＥＣの値によってＣＤ−ＤＡ，ＣＤ−Ｉ，ＣＤ−ＲＯＭ（ＸＡ仕様）が区別される。
ＰＯＩＮＴの値が『Ａ１ｈ』のときは、ＰＭＩＮに最後のトラックのトラックナンバが記録される。
ＰＯＩＮＴの値が『Ａ２ｈ』のときは、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにリードアウトエリアのスタートポイントが絶対時間アドレスとして示される。
【００３７】
例えば６トラックが記録されたディスクの場合、このようなサブＱデータによるＴＯＣとしては図５のようにデータが記録されていることになる。
図５に示すようにトラックナンバＴＮＯは全て『００ｈ』である。
ブロックＮＯ．とは上記のように９８フレームによるブロックデータとして読み込まれた１単位のサブＱデータのナンバを示している。
各ＴＯＣデータはそれぞれ３ブロックにわたって同一内容が書かれている。
図示するようにＰＯＩＮＴが『０１ｈ』〜『０６ｈ』の場合、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥとしてトラック＃１〜トラック＃６のスタートポイントが示されている。
【００３８】
そしてＰＯＩＮＴが『Ａ０ｈ』の場合、ＰＭＩＮに最初のトラックナンバとして『０１』が示される。またＰＳＥＣの値によってディスクが識別され、このディスクがＣＤ−ＤＡの場合は、図示するようにＰＳＥＣ＝『００ｈ』とされる。なお、ＣＤ−ＲＯＭ（ＸＡ仕様）の場合は、ＰＳＥＣ＝『２０ｈ』、ＣＤ−Ｉの場合は『１０ｈ』となる。
【００３９】
そしてＰＯＩＮＴの値として『Ａ１ｈ』の位置にＰＭＩＮに最後のトラックのトラックナンバが記録され、さらにＰＯＩＮＴの値として『Ａ２ｈ』の位置には、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにそれぞれリードアウトエリアのスタートポイントが示される。
ブロックｎ＋２７以降は、ブロックｎ〜ｎ＋２６の内容が再び繰り返して記録されている。
【００４０】
ディスク９０上で実際に音楽等のデータが記録されるトラック＃１〜＃ｎ、及びリードアウトエリアにおいては、そこに記録されているサブＱデータは図４（ｂ）に示されている情報を有する。
まずトラックナンバが記録される。即ち各トラック＃１〜＃ｎでは『０１ｈ』〜『９９ｈ』のいづれかの値となる。またリードアウトエリアではトラックナンバは『ＡＡｈ』とされる。
続いてインデックスとして各トラックをさらに細分化することができる情報が記録される。
【００４１】
そして、トラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥとして、絶対時間アドレスが分（ＡＭＩＮ），秒（ＡＳＥＣ），フレーム番号（ＡＦＲＡＭＥ）として記録されている。
【００４２】
このようにＴＯＣ及びサブコードが形成されているわけであるが、ディスク上のアドレス、即ちＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥは、９８フレーム単位で記録されることが理解される。
この９８フレーム（１ブロック）は１サブコーディングフレームと呼ばれ、音声データとしての１秒間には７５サブコーディングフレームが含まれることになる。つまり、アドレスとしての『ＡＦＲＡＭＥ』がとりうる値は『０』〜『７４』となる。なお、後述するフレームチェック処理でデータの連続性がチェックされるのは、このサブコーディングフレーム単位となる。
【００４３】
３．テキストデータ
以降、図２及び図３に示す構造のサブコードに含まれるテキストデータについて説明を行うこととし、まず、図６によりテキストデータの包括的な構造について説明する。
サブコード内に含まれるテキストデータのみを抽出して構造的に見た場合、テキストデータは図６に示すようなものとなる。テキストデータとしての最も大きなデータ単位は、図６（ａ）に示す『テキストグループ』とされる。図６（ａ）においては複数のテキストグループが示されているが、各テキストグループのデータは同一内容とされており、従って、サブコード内においては、同一データ内容の所定数の複数のテキストグループが繰り返し記録されていることになる。
【００４４】
１つのテキストグループは、例えば最大２０４８パック（パックの定義については後述する）により形成するものとされるが、１テキストグループあたりのデータ読出しに要する時間等を考慮して、１テキストグループを５１２パック以内により形成することが推奨されている。この際、１テキストグループあたりのデータ総量としては６５００文字程度となる。
また１つのテキストグループは、図６（ｂ）に示すようにブロック＃０〜ブロック＃ｎにより形成され、例えば最大８ブロック（０≦ｎ≦７となる）であると規定されている。各ブロックは、同一の内容の情報をそれぞれ異なる言語により表記するためのテキストデータが格納されているものとされる。例えば、ブロック＃０には、当該ディスクに対応する各種情報を英語により表記するためのテキストデータが格納されており、ブロック＃１には、ブロック＃０と内容的には同一の情報を日本語により表記するためのテキストデータが格納されているものとされる。
【００４５】
この場合、１テキストグループは最大８ブロックにより形成可能であることから、テキストデータのフォーマットとしては最大８言語に対応することが可能とされる。
１つのブロックは、図６（ｃ）に示すようにパック＃０〜パック＃ｎのデータ単位により形成される。ここでは、１ブロックは最大２５６パックで形成され情報量としては例えば３６．８６４ＫＢｙｔｅとされている。なお、パック内のデータ構造等については、次の図７、図８及び図９により説明する。
【００４６】
図７（ａ）は、図３に示した１サブコーディングフレームをデータ領域別に示すものであり、前述のように１サブコーディングフレームは９８フレームにより形成される。
９８フレームの先頭の第１、第２フレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）は、図３で説明したように同期パターンＳ０，Ｓ１の領域とされる。また、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）におけるＰチャンネルはサブコードＰのデータ領域とされ、ＱチャンネルはサブコードＱのデータ領域とされて、前述したようにアクセス等の管理のためのデータが格納される。
【００４７】
そして、第３フレームから第９８フレームにおけるＲチャンネル〜Ｗチャンネルの領域は図のようにパック０〜パック４とされる。各パックのデータサイズは固定長とされて、図７（ｂ）に示すようにシンボル０〜２３の２４シンボルにより形成される。１シンボルは図７（ｃ）に示すように、１フレームにおけるＲ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのチャンネルデータよりなる６ビットのデータ単位であり、この場合にはＲチャンネルデータがＭＳＢ、ＷチャンネルがＬＳＢとして定義される。
【００４８】
図８は、上記図７（ａ）に示す構造の１サブコーディングフレームから、４つのパック（パック０〜パック４）によるデータ構造を抜き出して示している。
１パックは、図７で説明したように、２４のシンボル（６ビット）により形成されることから、
６ビット×２４／８＝１８バイト
で示されるように１８バイトのデータサイズを有する。そして、図のように１パックは、先頭のＩＤ領域と続くテキストデータ領域により１６バイトを占有し、残りの２バイトはＣＲＣ領域となる。
また、前述のように１サブコーディングフレームにおいては４つのパックが設けられるが、これら４つのパックの集合により形成されるデータ単位はパケットとして定義されている。１パックは２４シンボルにより形成されることから、１パケットは、
２４（シンボル）×４（パック）＝９６（シンボル）
で示されるように９６のシンボルにより形成されるものとみることができる。
【００４９】
図９及び図１０は、図８で示した１パック分のデータをシリアルに表現したものである。
図９（ａ）から分かるように、本実施の形態におけるテキストデータのフォーマットにおいては、６ビットよりなるシンボルをシリアルに配列させたうえで、このデータ列を８ビット（１バイト）ごとに区切るようにしてデータを扱うように規定されている。
【００５０】
本実施の形態のテキストデータのフォーマットでは、図９（ｂ）及び図１０に示すように、パックの先頭からはヘッダ領域としてＩＤ１、ＩＤ２、ＩＤ３、ＩＤ４の４つのＩＤデータが設けられる。なお、ＩＤ１はＰａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ２はＴｒａｃｋ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ３はＳｅｑｕｅｎｃｅ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ４はＢｌｏｃｋ＿Ｎｕｍｂｅｒ＿ａｎｄ＿Ｃｈａｒａｃｔｅｒ＿Ｐｏｓｉｔｉｏｎ＿Ｉｎｄｉｃａｔｏｒとされているが、これらの内容については後述する。
【００５１】
本実施の形態のフォーマットとして８ビット（１バイト）ごとに区切ってデータを扱うことにより、これら各ＩＤはそれぞれ８ビット（１バイト）のデータ単位とされることになる。このため、図９（ｂ）に示すように、ヘッダ領域（ＩＤ１〜ＩＤ４）以降の残りの１２バイトがテキストデータ領域として確保され、残りの２バイトがＣＲＣ領域となる。
そして、上記１２バイトのテキストデータ領域も、図１０に示すパックの構造図に示すように、８ビットごとのｔｅｘｔ１〜ｔｅｘｔ１２のデータ単位により扱われるものとされる。
なお、以降の説明では、単に『ヘッダ』という場合はパックの先頭にあるヘッダ領域（ＩＤ１〜ＩＤ４）を示し、テキストグループ内における先頭のパックのヘッダについては『スタートヘッダ』ということとする。
【００５２】
ここで、本実施の形態のテキストデータのフォーマットにおいては、図１１に示すようにテキストデータ対応以外のＣＤのフォーマットに準じて、パックの先頭のＩＤ１の上位３ビットをモード（ＭＯＤＥ）として扱い、続く３ビットをアイテム（ＩＴＥＭ）として扱うことができるようにしている。
そして、上位３ビットのモードとしては、モード４を設定してこの３ビットに対して値『１００』を設定するようにしている。このモード４はＣＤ−ＴＥＸＴフォーマットが提案される前は未定義とされている。こうすることで、例えばテキストデータに対応していない再生装置等にテキストデータが格納されたＣＤを装填しても、モードとして認識不可能とされることでその動作を停止するだけであって、誤動作することはないようにされる。また、モード４としてはテキストデータがリードインエリアに記憶されているモードであるが、この他にも、プログラムエリア（主データが格納されているエリア）に対してテキストデータが記憶されているモード２が知られている。本例ではモード４を例に挙げて説明するが、本発明はモード２を適用している場合にも対応することが可能とされる。
【００５３】
なお、未定義のモードとしてはモード５及びモード６が存在するので、モード４の代わりにこれらのモードに対応する値を設定することも可能である。また、参考までに、使用済みのモードとしては、ＣＤ−Ｇに対応するモード１、ＣＤ−ＭＩＤＩに対応するモード３等が存在する。
なお、ここではアイテム（ＩＴＥＭ）としての値は特に設定されず、後述するように、ＩＤ１により定義する識別内容に応じて下位３ビット以降の値は適宜異なる（実際には下位４ビットのみが変更される）ものとなる。
【００５４】
次に、図１２及び図１３を参照して、本実施の形態が対応するテキストデータフォーマットにおけるヘッダ領域（ＩＤ１、ＩＤ２、ＩＤ３、及びＩＤ４）の各定義内容について説明する。図１２（ａ）〜（ｄ）はそれぞれＩＤ１〜ＩＤ４を示し、図１３はＩＤ１の定義内容を示している。
図１２（ａ）に示すＩＤ１（８ビット）は、当該パックのテキストデータ領域におけるｔｅｘｔ１以降に格納される文字列の内容の種類を識別するためのデータが設定されるものであり、『８０ｈ』〜『８Ｆｈ』の値をとるものとされる。ここで、ＩＤ１について設定される値として上位４ビットが１６進法によりすべて『８』が設定されているのは、図１１で説明したように、ＩＤ１の上位３ビットをモード（ＭＯＤＥ）として扱った場合に『１００』の値が得られるようにして、モード４として識別できるようにするためである。
【００５５】
ＩＤ１に設定される値『８０ｈ』〜『８Ｆｈ』に対応する定義内容は、図１３に示すように規定されている。この図によると、ＩＤ１が『８０ｈ』の場合には、ｔｅｘｔ１以降に格納される文字列の内容が、アルバムタイトル（ＴｉｔｌｅＯｆ Ａｌｂｕｍ Ｎａｍｅ・・・ＩＤ２が『００ｈ』の場合）又はトラックに記録された楽曲等の曲名（Ｔｒａｃｋ Ｔｉｔｌｅ・・・ＩＤ２が『０１ｈ〜６３ｈ』の場合）であることを示すことになる。
また、ＩＤ１が『８１ｈ』の場合には演奏者、指揮者、又はオーケストラ名であることを示し、『８２ｈ』の場合には作詞者名、『８３ｈ』の場合には作曲者名、『８４ｈ』の場合には編曲者名であることを示す。ＩＤ１が『８５ｈ』の場合には、当該ＣＤを供給する者（例えばレコード会社等）や演奏者などからのメッセージであることが示される。
【００５６】
また、ＩＤ１が『８６ｈ』の場合には、例えばカタログナンバやレコード会社の名前等により決められるディスクＩＤであることが示され、『８７ｈ』の場合にはジャンルを示すテキストデータであることが示され、『８８ｈ』の場合にはＴＯＣデータであることが示される。このＴＯＣデータは、例えばＱチャンネルのサブコードデータに準ずる内容を示すものとなる。また、『８９ｈ』の場合には、２ｎｄＴＯＣであることが示される。
ＩＤ１として『８Ａｈ』『８Ｂｈ』『８Ｃｈ』は予約（ＲＥＳＥＲＶＥＤ）とされている。
【００５７】
『８Ｄｈ』は、当該ＣＤの製造管理に関する情報や当該パック内に記録されている内容に関するコメント等であることが示され、『８Ｅｈ』はアルバムのＵＰＣ／ＥＡＮコードやトラックのＩＳＲＣコードであることが示される。
『８Ｆｈ』は、ブロック内のサイズインフォメーション（Ｓｉｚｅ Ｉｎｆｏｒｍａｔｉｏｎ）が示されている。
【００５８】
図１２（ｂ）に示すＩＤ２は、当該パックのテキストデータ領域におけるｔｅｘｔ１以降に格納される文字列がどのトラックに対応するのかをトラックナンバにより示すものとされ、ＩＤ２を形成する８ビットにより、『００ｈ』〜『６３ｈ』（１０進法では０〜９９）の値をとるものとされる。但し、トラックナンバは「１」からインクリメントされるようにして付されていくものであるため、トラックナンバとしては『０１ｈ』〜『６３ｈ』（１０進法では１〜９９）の値をとることになる。値『００ｈ』は、ディスク全体を代表することを意味するものとされる。
ＩＤ２のＭＳＢは、拡張用フラグとされているがここでは常に『０』を設定するものとされ、『１』が設定されると拡張用のフラグが立てられたことになる。
【００５９】
図１２（ｃ）に示すＩＤ３は、当該パックが属するブロック内において、当該パックが何番目のパックであるのかを示すパックのブロック内連番を示すものとされ、ＩＤ３を形成する８ビットにより、『００ｈ』〜『ＦＦｈ』（１０進法では０〜２５５）の値をとるものとされる。
【００６０】
図１２（ｄ）に示すＩＤ４は、現パックのブロック番号（文字コードの識別情報を含む）と、１まとまりの文字列の文字位置を示すものとされる。
ＭＳＢは当該パックにおけるテキストデータが１バイトコードか２バイトコードであるかを示す２バイトコードフラグの領域とされ、値として「１」の場合には２バイトコードであることが示され、「０」の場合には１バイトコードであることが示される。
ＭＳＢに続く上位第２ビットから第４ビットまでの３ビットは、当該パックを含むブロック（図６（ｂ）参照）のブロック番号が示され、２進法で『０００』〜『１１１』（１０進法では０〜７）の値を取るものとされる。図６により説明したようにブロックは最大８つ設けられて、ブロックナンバとしてはブロックナンバ０〜７の値を取り得ることになるが、上記３ビットにより取り得る値はこれに対応したものとなる。
【００６１】
ところで、現状として、少なくともブロック＃０においては、テキストデータとしてＡＳＣＩＩコードを含む８８５９−１コードのみを使用することが規定されている。つまり、ブロック＃０においては、一般的には言語として英語による表記を行うためのテキストデータが格納されることになる。なお、以降の説明においては、便宜上、ブロック０は言語として英語に対応し、文字コードとしてはＡＳＣＩＩコードを用いるものする。ＡＳＣＩＩコード（及び８８５９−１コード）は１バイトコードであることから、ブロック＃０に含まれる全パック内のＩＤ４においては、上位４ビットは『００００』となる。
【００６２】
ＩＤ４の下位４ビットは、現パックにおける文字位置の情報が格納される。つまり、現パックのテキストデータ領域における最初のｔｅｘｔ１に格納されている文字データが、１まとまりの文字列における何番目の文字であるのかを示すものとされ、図１３（ｄ）に示すように、２進法で『００００』〜『１１１１』の値をとる。なお、１６番目以上の文字である場合にはすべて『１１１１』となる。
また、ここでいう「１まとまりの文字列」とは、例えば、トラックの曲名データであれば、この１トラック分の曲名を形成する一連の文字列を意味するものである。
【００６３】
図１４には、トラックごとの曲名を示すテキストデータをテキストデータ領域に格納する場合の１パックの構造例が示されている。この場合、図１２（ａ）及び図１３により説明したように、ＩＤ１は『８０ｈ』とされ、ＩＤ２には、当該パックのテキストデータにより表記するタイトルのトラックに対応するトラックナンバが『０１ｈ』〜『６３ｈ』（トラック１〜９９）により適宜示される。ＩＤ３には、ブロック内における当該パックのブロック内連番が『００ｈ』〜『ＦＦｈ』により示される。ＩＤ４は当該パックを含む現ブロックのブロック番号（図６（ｂ）参照）が第２ビット〜第４ビットの３ビットにより示され、現ブロックが対応する文字コードが２バイトコードか１バイトコードであるかがＭＳＢにより示される。例えば、現パックのテキストデータがＡＳＣＩＩコードに対応するものであれば、前述のようにＩＤ４の上位４ビットは『００００』となる。
【００６４】
また、ＩＤ４の下位４ビットは、ｔｅｘｔ１に格納されている文字データが、１まとまりの文字列における何番目の文字であるのかを示す値が適宜示されることになる。トラックごとの曲名を示すテキストデータの場合、上記「１まとまりの文字列」とは、トラックごとの曲名に対応する文字列がこれに相当するものとされ、例えば、あるトラックの曲名が『ＴＨＩＳ ＩＳ Ａ ＰＥＮ』であるとして、このＴＨＩＳ＿ＩＳ＿Ａ＿ＰＥＮの文字列のうち、２番目の『Ｈ』の文字データが当該パックのｔｅｘｔ１に格納されているとすれば、当該パックのＩＤ４における下位４ビットは『０００１（１ｈ）』とされることになる。
【００６５】
この場合、『ＴＨＩＳ ＩＳ Ａ ＰＥＮ』のうち最初の文字データ『Ｔ』は、当該パックの直前のパックのテキストデータ領域に格納されていることになる。つまりテキストデータは、１まとまりの文字列データが連続するパックをまたがるようにしてテキストデータ領域に格納することが可能とされるフォーマットとされている。
そして、テキストデータ領域である各８ビットのｔｅｘｔ１〜ｔｅｘｔ１２には、本実施の形態のテキストデータフォーマットに則った規則に従って、各トラックの曲名を示す文字コードのデータが格納されることになる。
【００６６】
４．再生処理
本実施の形態におけるテキストデータの再生処理の概要を説明する。まず、ここでは全体の流れを説明し、詳細な説明については順次行なっていくこととする。
【００６７】
上記したように、「モード４］においてはテキストデータはディスク９０のサブコードデータの一部に記録されている。したがって、テキストデータを扱う場合は、まずサブコードデータ（Ｐ〜Ｗ）から不要なデータ（Ｐ、Ｑ）を排除してテキストデータ（Ｒ〜Ｗ）の抽出を行なうことになる。
この場合サブコードデータはデインターリーブを行なわないローデータとしてキャッシュメモリ２０に順次格納していく。ローデータとしては９６バイト（９６ｂｉｔ×８（Ｐ〜Ｗ））、即ち１サブコードフレームに相当するデータ量が１回のバファリング単位とされる。そして、キャッシュメモリ２０に格納されたサブコードデータの中から、所望するテキストデータの位置を識別する検出処理を行なう。この検出処理としてはテキストグループのスタートヘッダを検出するための処理とされる。以降、この処理をバファリング処理という。
【００６８】
バッファリング処理としては、サブコードデータにおいて図６（ａ）に示したテキストグループの先頭とされる位置（先頭パックのヘッダに相当する）を起点とし読み出しを行なうこと望ましいが、実際にはこれは困難な処理とされる。そこで、１回の読み込みではバファリング処理を行なうに際して必要なデータが得られない場合を想定して、キャッシュメモリ２０には少なくとも２テキストグループ分のデータ量に相当するサブコードデータを格納することができるようにして、この格納された２テキストグループ分のサブコードデータの中からスタートヘッダを検出するようにしている。
【００６９】
バッファリング処理を行なう場合、キャッシュメモリ２０は例えば図１５に示されている形態でマッピングされた状態で使用する。ローサブコードエリア（ＲＡＷ＿ＳＵＢ＿ＣＯＤＥ＿ＡＲＥＡ）は、例えば２テキストグループ分のデータ量に相当するのローサブコードデータ（ＲＡＷ＿ＳＵＢ＿ＣＯＤＥ＿ＤＡＴＡ（Ｐ〜Ｗ））を格納することができる領域とされる。
そして、後述するようにローサブコードエリアに格納されたサブコードデータに対してバッファリング処理を行ない、このバファリング処理によって検出された、スタートヘッダに基づいてローテキストデータ（ＲＡＷ＿ＴＥＸＴ＿ＤＡＴＡ（Ｒ〜Ｗ））の抽出（８ビット（Ｐ〜Ｗ）から６ビット（Ｒ〜Ｗ）への変換処理・・・以下、８ビット／６ビット変換処理という）を行なう。ここで、抽出されたローテキストデータは、図１５に示すローテキストエリア（ＲＡＷ＿ＴＥＸＴ＿ＡＲＥＡ）に格納される段階で、データ内容の有効性が検証される。
有効性が確認されたローテキストデータは、ローテキストエリアから読み出されてホストコンピュータ８０に対して転送されるようにされる。即ち、ホストコンピュータ８０に対しては、有効性が確認されたローテキストデータのみを転送することができるようになる。
【００７０】
ところで、図示している各エリアの容量を示す数値は一例である。
前記したように、テキストグループの１ブロックの情報量は上述したように例えば３６．８６４Ｋバイトとされる。したがって、ローテキストエリアに必要な容量としては少なくとも、３６．８６４×２＝７３．７２８Ｋバイト以上であれば良い。
また、ローサブコードエリアは、３６．８６４×８／６＝４９．１５２Ｋバイトが１フレーム分のデータ量に相当するので、２フレームに相当する容量としては４９．１５２×２＝９８．３０４Ｋｂｙｔｅとなる。したがって、ローサブコードエリアに必要な容量は、少なくとも９８．３０４Ｋｂｙｔｅ以上であれば良い。
【００７１】
５．バファリング処理
図１６、図１７は、バッファリング処理の流れを摸式的に説明するフローチャートを示す図である。なお、図１６に示されているフローチャートの結合子（１）は、図１７に示されているフローチャートの結合子（１）に対応したものである。即ち、バファリング処理としては図１６乃至図１７に示されている一連の処理行程によって実現される処理とされる。したがって、各図には連続したステップ番号を付している。
【００７２】
バッファリング処理の開始を指示するコマンドはホストコンピュータ８０から供給される（S001）。ここで、再生装置が受信するコマンドとしては、例えば「Ａ０コマンド」、「Ｐａｃｋｅｔコマンド」などのリードＴＯＣコマンドを拡張してＣＤ−ＴＥＸＴに格納されたテキストデータを読み込む処理を開始するためのコマンドとされる。
このようなコマンドを受信すると、「ＯＰコードチェック」、「ＣＤＢチェック」、「メディアチェック」などの各種チェック処理が行なわれる（S002）。
【００７３】
「ＯＰコードチェック」によって、受信したコマンドのＯＰコードが当該装置に対応しているものかの可否判別が行なわれ、「ＣＤＢチェック」によって、コマンド（１２バイト）の内容が規格に準拠しているかの可否判別が行なわれる。これらの判別結果が「可」とされた場合、「メディアチェック」によって、再生装置７０に装填されているディスク９０が、例えばオーディオＣＤであるか否か（つまり、ＣＤ−ＲＯＭなどではなくＣＤ−ＴＥＸＴとしてテキストデータを有する可能性のあるディスクであるか否か）の判別が行なわれる。なお、ＣＤ−ＴＥＸＴとは種別的にはオーディオＣＤ（ＣＤ−ＤＡ）に含まれるものである。
ディスク９０がオーディオＣＤ（オーディオトラックが存在する）か否かは、上述したＴＯＣにより判別できる。そして通常、ＴＯＣデータはディスク装填時に読み込んでいるため、即座に判別可能である。
【００７４】
ここで、ディスク９０がオーディオＣＤであると判別された場合は、「Ａｌｌｏｃａｔｉｏｎ ｌｅｎｇｔｈ＝０」か否か、即ち、要求するデータ長の確認を行ない（S003）、要求するデータがある場合（「０」でない場合）ステップS004に進む。
なお、各種チェック処理（S002）における判定が「否」であった場合は、その時点で所要のエラー処理が行なわれ、バファリング処理は行なわれないことになる。
【００７５】
要求するデータ長の確認（S003）が終了すると、ファームウエア内の状況の初期化を行なう（S004）。そして、例えば現在当該再生装置７０によってオーディオ再生が行なわれている場合は、その再生処理を強制的に終了する（S005）。但し、現在オーディオ再生処理を行なっていない場合は、この処理行程は省略される。 ステップS005を経ると、さらにキャッシュパラメータの初期化を行なう（S006）。これは、キャッシュメモリ２０の使用形態が、通常の状態から図１５に示した状態（ローサブコードエリアとローテキストエリアがマッピングされる状態）に移行するため、現在まで格納されているデータが不要となるので、これらのデータを無効にするための処理とされる。
そして、本実施の形態のバファリング処理を行なうために実行すべき割り込み処理の切替えを行なう（S007）。これは、例えばデインターリーブをオフにするなど、バファリング処理を行なうための所要の割り込み処理を実行させるためとされる。
【００７６】
図１６のフローチャートにおいて割り込み処理の切替え処理（S007）を経ると、図１７のフローチャートに示されていうように、ディスク９０のリードインエリアのＴＯＣに対するアクセス要求を行なう（S008）。これによりピックアップ１はディスク９０の内周側に記憶されているＴＯＣに対してアクセスを開始する。
さらに、ローサブコードデータが９６バイト分バファリングされた時点で「１」づつインクリメントされるパラメータとして設定される『Ｎ』、テキストグループの先頭を示すヘッダ情報とされるスタートヘッダが検出された回数を示すパラメータとして設定される『Ｍ』、及びＣＲＣのＮＧ回数を示すパラメータとして設定される『ＮＧ数』を初期値化「０」する（S009）。
アクセス開始後は、アクセス完了に対して待機状態となり（S010）、アクセスが完了した時点で、ローサブコードデータのバッファリングを開始する（S011）。即ち、デインターリーブをオフにするとともに、図１５に示したローサブコードエリアに対してローサブコードの格納を開始させる。
【００７７】
そして、ローサブコードエリアに対して所定量のローサブコードデータ（例えば１サブコードに相当するデータ量）が格納されるのを待つことになる（S012）。ここで、所定量のローサブコードデータが格納されると、その時点で割り込み処理として所要の通知処理が行なわれ、システムコントローラ１０ではローサブコードエリアに対してローサブコードデータが格納されたことを認識することができる。なお、この図に示すフローチャートとしてはステップS012の判別処理を便宜上一連の処理行程の一部として示しているが、実際には、この判別処理は随時行なわれているものとされる。つまり、ローサブコードエリアに対するローサブコードデータの読み込みも、随時行なわれている。したがって、以降説明する処理行程は、ローサブコードエリアに所定量のローサブコードデータが格納される度に、随時割り込み処理として行なわれるようにされる。
【００７８】
ローサブコードエリアに所定量のローサブコードデータが蓄えられると、これをカウントするパラメータ『Ｎ』をインクリメント（Ｎ＝Ｎ＋１）する処理を行なう（S013）。そして、蓄えられたローサブコードデータに対してＣＲＣのチェックを行なう（S014）。このＣＲＣチェックは、図８に示した４個のＣＲＣ領域に或る誤り検出符号に対して行われ、チェックによる判定結果としては、４個のＣＲＣ領域全てが「ＯＫ」とされた場合に「ＯＫ」とされ、一つでも「ＮＧ」があった場合には「ＮＧ」とされる。
ステップS014で、ＣＲＣが「ＯＫ」となった場合、即ちローサブコードエリアに蓄えられたローサブコードデータが有効であるとされた場合は、テキストグループの先頭を示すスタートヘッダのパターン（Ｓｔａｒｔ＿Ｈｅａｄｅｒ＿Ｐａｔｔｅｒｎ）のチェックを行なう（S016）。
【００７９】
そして、スタートヘッダの検出の有無の判別を行ない（S017）、スタートヘッダが検出されない場合は、ステップS012に戻る。
また、スタートヘッダが検出された場合は、検出されたスタートヘッダの数をカウントするパラメータ『Ｍ』をインクリメント（Ｍ＝Ｍ＋１）する処理を行ない（S018）、続いて、パラメータ『Ｍ』の値の判別を行なう（S019）。ここで、パラメータ『Ｍ』が「１」以下であると判別した場合は、『Ｃｏｕｎｔ１』にパラメータ『Ｎ』の値を設定して（S020）、ステップS012に戻る。なお、『Ｃｏｕｎｔ１』は、何回目のローサブコードデータの読み込みにおいて第一のスタートヘッダが検出されたかを示すパラメータとされる。
【００８０】
一方、ステップS019においてパラメータ『Ｍ』が「２」または「２」以上であると判別した場合は、『Ｃｏｕｎｔ２』にパラメータ『Ｎ』の値を設定する（S021）。この『Ｃｏｕｎｔ２』は、何回目のローサブコードデータの読み込みにおいて第二のスタートヘッダが検出されたかを示すパラメータとされる。
即ち、パラメータ『Ｍ』が「２」または「２」以上となった時点で、第一のスタートヘッダ及び、第二のスタートヘッダが検出されたことになる。つまり、第一、第二のスタートヘッダ間に１個のテキストグループがバファリングされたとみなすことができる。
【００８１】
以降、このようにして検出された第一、第二のスタートヘッダ間におけるテキストデータの有効性を検証する処理（２）に移行するが、これについては後で図２１にしたがい詳しく説明する。また、ステップS021を経て処理（２）に移行した場合でも、図１７に示したバファリング処理は継続して行なうようにしている。
これにより、後述する処理（２）においてテキストデータの有効性が確認されなかった場合でも、その時点で引き続きキャッシュメモリ２０のローサブコードエリアに格納されているローサブコードデータの検証を行なえば良い。したがって、改めてＴＯＣに対するアクセス処理などを行なう必要がないので、処理効率が向上する。
【００８２】
また、例えば２個のスタートヘッダが検出された時点でローサブコードデータのバッファリングを終了させたうえで、テキストデータの有効性の検証処理に移行するようにしても良い。これは、２個のスタートヘッダが検出されたことによって、その時点で期待されるテキストデータが得られたと見なすようにする処理とされる。これにより、２個のタートヘッダが検出された後は、システムコントローラ１０は前記検証処理のみを実行させれば良いので、処理負担を軽減することが可能である。
【００８３】
ところで、ステップS014においてＣＲＣが「ＮＧ」となった場合は、ＣＲＣのＮＧ回数を示すパラメータとして設定される『ＮＧ数』のインクリメント（ＮＧ数＝ＮＧ数＋１）を行ない（S022）、さらに、『ＮＧ数』が当該再生装置７０に設定されている『ＮＧ許容数』（例えば「４」回）以下であるか否かの判別を行なう（S023）。ここで、『ＮＧ数』が『ＮＧ許容数』以下であった場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
また、『ＮＧ数』が『ＮＧ許容数』以上であった場合は、リトライ処理としてステップS008に戻りＴＯＣに対するアクセス要求を行ない、さらに上述したステップS009からの処理を実行していくようにする。
【００８４】
なお、本例では『ＮＧ許容数』は例えば「４」として、『ＮＧ数』がこれを超えた場合に再びＴＯＣに対するアクセス要求を行なうようにしている。しかし、『ＮＧ数』が例えば２５６（全てのパックについて「ＮＧ」の判定）を超えるような場合、テキストデータを読むことができる見込みがないものと見なして、図１６、図１７に示すフローチャートの処理自体を終了させるようにしても良い。
【００８５】
この場合の処理行程としては、ステップS014、S022を経た後、例えば図１８に示されているようになる。この図１８において、図１７と同一の符号を付した処理ステップについては同じ処理行程を示している。
図示されているように、ステップS022において『ＮＧ数』のインクリメント処理を経ると、パラメータ『Ｍ』、即ち、テキストグループの先頭を示すヘッダ情報とされるスタートヘッダが検出された回数が「０」であるか否かの判別を行う（S701）。そして判別結果が「０」とされスタートヘッダが検出されないと判別した場合は、ローサブコードデータが例えば９６バイトを単位として何回バッファリングされたかを示すパラメータ『Ｎ』が所定値以上であるか否かの判別を行う（S702）。なお、ステップS702における所定値とは、ディスク９０にテキストデータが記憶されているか否かを判別するための閾値として設定される。即ち、ステップS014においてＣＲＣが「ＮＧ」になった時点で、ローサブコードデータが何回バッファリングされたかに基づいて、以降の処理が行われる。
【００８６】
例えば、パラメータ『Ｎ』が所定値以下であったと判別した場合は、さらに、『ＮＧ数』が例えば「６４」を超えたか否かの判別を行う（S703）。このステップS703における閾値とされる「６４」は、先述したようにテキストグループを形成する１ブロックが２５６パック（２５６パック＝６４サブコードフレーム）によって形成されていることに基づいている。
したがってステップS703において「ＮＧ数」が例えば「６４」を超えていたと判別した場合は、再生装置７０に装填されたディスク９０にはテキストデータが格納されていないと判断する（S704）。これにより、テキストデータの読み込むことができる見込みがないものと見なして、バッファリング処理を終了させる（S705）。
また、「ＮＧ数」が例えば「６４」を超えていないと判別した場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
【００８７】
また、ステップS702においてパラメータ「Ｎ」が所定値を超えていなかった場合には、『ＮＧ数』が当該再生装置７０に設定されている『ＮＧ許容数』（例えば「４」回）以下であるか否かの判別を行なう（S023）。ここで、『ＮＧ数』が『ＮＧ許容数』以下であった場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
また、『ＮＧ数』が『ＮＧ許容数』以上であった場合は、リトライ処理としてステップS008に戻りＴＯＣに対するアクセス要求を行ない、図１７で説明した場合と同様にステップS009からの処理を実行していくようにする。
【００８８】
このように、ステップS701、S702、S703を経ることによって、スタートヘッダが検出されず、サブコードデータのバッファリング回数が所定値以下であり、かつＣＲＣの「ＮＧ数」が例えば「６４」以上であった時点で、ディスク９０にテキストデータが格納されていないことを判別することができるようになる。したがって、ディスク９０がオーディオＣＤとしてテキストデータを有していないと判別した時点で、図１６、図１７に示したバッファリング処理を終了させることができる。
つまり、再生装置７０にテキストデータが記憶されていないオーディオＣＤが装填されている場合は、バッファリング処理が開始されると、連続してＣＲＣがＮＧとされる処理ステップを進むことになる。この場合、スタートヘッダは検出されないので、バファリングの回数（S702）及び「ＮＧ数」（S703）に基づいて、当該ディスク９０にテキストデータが記録されているか否かを判別することができるようになる。これにより、バッファリング処理が開始されてから、必要最小限のサブコードデータのバッファリングを行うことで、テキストデータの有無を判別することが可能になる。
【００８９】
ところで、ステップS014においてＣＲＣが「ＮＧ」とされた場合は、図１７において例えば破線で示されている結合子（３）に対応した、図１９に示されているフローチャートの処理を行なうことも考えられる。
この図に示されているフローチャートの処理行程としては、ステップS201に示されてるようにパラメータ『Ｍ』が「０」であるか否かの判別を行ない、ここでパラメータ『Ｍ』が「０」であると判別した場合には、図１７に示したステップS023に進み『ＮＧ数』の判定を行なうようにする。つまり、ステップS201でパラメータ『Ｍ』が「０」であった場合、まだスタートヘッダが検出されていない状態を示しており、したがって、再度スタートヘッダを検出する処理を行なうようにするため、ステップS023におけるＮＧ判定処理を経ることになる。
【００９０】
また、パラメータ『Ｍ』が「０」ではないと判別した場合は、ステップS202に進みパラメータ『Ｍ』が「２」であるか否かの判別を行なう。ここで、パラメータ『Ｍ』が「２」ではないと判別した場合は、図１７に示したステップS008に進みＴＯＣエリアに対するアクセス要求を行なう。一方、パラメータ『Ｍ』が「２」であると判別した場合は、サブコードデータのバッファリング処理を終了して（S203）テキストデータの有効性を検証する処理（２）に進む。
【００９１】
ステップ201及びステップS202の行程により、検出されているスタートヘッダの連続性が検出されるようになる。但し、図１７に示したフローチャートのステップS019において、パラメータ『Ｍ』が例えば「２」または「２」以上とされた場合は、ステップS012を経てテキストデータの有効性を検証する処理（２）に進む行程を説明している。したがって、パラメータ『Ｍ』が「２」または「２」以上とされている場合、スタートヘッダの検出に伴って実行される処理行程として、図１７のステップS019、S021を経て処理（２）に進むことになる。
【００９２】
しかしながら、前述したようにステップS012以降の処理行程は随時行なわれており、現在実行している各判別処理などに対して並行した読み込み処理が行なわれているものとされる。これは、処理中のデータに対して予め次のデータの読み込みを行なう先読み処理に相当する。したがって、ステップS014においてＣＲＣの判定結果が「ＮＧ」とされた場合でも、ステップ201及びステップS202の処理行程において先読みによって連続したスタートヘッダが検出された状態では、当該スタートヘッダに対応したテキストデータに対して有効性の検証を行なうことが可能とされるようにしている。
なお、図１９のフローチャートにおいて、テキストデータの有効性の検証を行なうまえにステップS203においてローサブコードデータのバッファリングを終了しているのは、ＣＲＣ判定が「ＮＧ］とされていることに加え、先読みによって得られたテキストデータを利用すれば良いということから、これ以上バファリング処理を継続しなくても良いという判断を下すことが可能とされるためである。
【００９３】
図２０はバファリング処理によるキャッシュメモリの内容を説明する図であり、図２０（ａ）は、図１７のフローチャートで説明した各パラメータの数値例、図２０（ｂ）は、キャッシュメモリ２０のアドレスに準じたデータ内容を摸式的に示す図である。
【００９４】
パラメータ『Ｎ』は、１フレーム分のサブコードデータがキャッシュメモリ２０のサブコードエリア格納された場合にインクリメントされ、この図に示す例では初期値とされる「０」から「５１７」までの数値が示されている。即ち、図１７におけるステップS012以降の処理が５１７回行なわれたことを示している。これに対応して、図２０（ｂ）に示すキャッシュメモリ２０では、Ｃａｓｈｅ＃１〜Ｃａｓｈｅ＃５１７が示されているが、パラメータ『Ｎ』に対応したエリアにはバッファリングされた１フレーム分のサブコードデータが格納されている。
【００９５】
パラメータ『Ｍ』は、スタートヘッダが検出された時点でインクリメントされ、この図に示す例では『Ｎ』＝「７」、及び『Ｎ』＝「５１６」となった場合に、インクリメントされている。したがって、『Ｎ』＝「７」の時点で第一のスタートヘッダが、また『Ｎ』＝「５１６」の時点で第二のスタートヘッダが検出されたことを示している。
『ＮＧ数』は『Ｎ』＝「１」の時点からインクリメントされ、『Ｎ』＝「４」以降は『ＮＧ数』＝「４」がホールドされている。即ち、『Ｎ』＝「５」以降はＣＲＣ判定が「ＯＫ」とされていることを示している。
【００９６】
『Ｃｏｕｎｔ１』はパラメータ『Ｍ』が１回目にインクリメンとされた時点でのパラメータ『Ｎ』の値が設定され、本例では「７」が設定されている。同様に『Ｃｏｕｎｔ２』はパラメータ『Ｍ』が２回目にインクリメントされた時点で、パラメータ『Ｎ』の値が設定され「５１６」が設定されている。
【００９７】
このようなことから、図２０（ｂ）に示されているように、キャッシュメモリ２０のローサブコードエリアでは、Ｃａｓｈｅ＃１〜Ｃａｓｈｅ＃４がＣＲＣ判定により「ＮＧ」とされたデータとされ、『Ｃｏｕｎｔ１』＝「７」〜『Ｃｏｕｎｔ２』＝「５１６」に相当する、Ｃａｓｈｅ＃７〜Ｃａｓｈｅ＃５１６までの間にテキストグループが存在すると判別することができる。
即ち、これまでの処理が、図１６乃至図１９で示したフローチャートの処理行程によって行なわれる。
なお、Ｃａｓｈｅ＃７〜Ｃａｓｈｅ＃５１６については、後に８ビット／６ビット変換されキャッシュメモリ２０におけるローテキストエリア内に移されることになるが、この処理については後述で詳しく説明することにする。
【００９８】
図１７のフローチャートのステップS016乃至ステップS017においてスタートヘッダを検出する行程を説明したが、ここではその概要を説明する。
例えば１０２４フレーム分のローサブコードデータをバッファリングすることによって、その中からスタートヘッダを検出することも考えられるが、ＣＤ−ＴＥＸＴとして記憶されているデータ容量が比較的小さい場合などは、処理効率が良いものではない。そこで、本例では、ローサブコードデータをローサブコードエリアに格納しつつ、並行して格納されているスタートヘッダの監視を行い、検出されたスタートヘッダの数が２以上である場合、その間に１個のテキストグループがあるという判断を下している。
【００９９】
スタートヘッダのパターンとしては「８０ｈ，００ｈ，００ｈ，Ｘ０ｈ」とされる４バイトのデータとされる。このデータ配列をビットで示すと
「８０ｈ」 ・・・ １０００００００ｂ
「００ｈ」 ・・・ ００００００００ｂ
となる。なお４バイト目の「Ｘ０ｈ」については、「００ｈ」または「８０ｈ」のいずれかであることを示している。つまり、このヘッダパターンは「８０ｈ，００ｈ」から、図１３で説明したようにアルバムタイトルヘッダであることがわかる。
【０１００】
ローサブコードデータがローサブコードエリアに格納された状態では図２１に示されているようになる。この図には、スタートヘッダを含んだＰ〜Ｗに至る８ビットのデータを示している。このデータにおいて、図７（ａ）で説明したパックの先頭（ヘッダ領域）をチェックし、これらのパターンが２回以上検出された場合に、１個のテキストグループが検出されたとすることができる。
【０１０１】
６．８ビット／６ビット変換
ローサブコードエリアに格納されたローサブコードは図２１に示したように８ビット（Ｐ〜Ｗ）とされているが、テキストデータは６ビット（Ｒ〜Ｗ）のデータとされる。したがって、効率の良い処理を行なうためには、８ビットのデータ（Ｐ〜Ｗ）のうちＰ、Ｑデータの２バイトを除去することが必要になる。そこで、後で図２３で説明するフローチャートの処理行程とされる８ビット／６ビット変換処理を行なうようにしている。
【０１０２】
図２２（ａ）は、図２１に示したＲ〜Ｗのデータ配列を、アルファベット（ａ〜ｘ）に対応させて示している。この状態ではＲ〜Ｗのデータは６ビット単位とされる。このように配列されている８ビットのデータからＰ、Ｑデータ（Ｘ印）を除去して再び８ビットに配列し直すと、図２２（ｂ）に示されているようになる。つまり、キャッシュメモリ２０のローテキストエリアには、バイト単位で扱うことができるテキストデータが格納される。
【０１０３】
この処理について、図２０を参照して説明する。
図２０（ｂ）に示されている『Ｃｏｕｎｔ１』〜『Ｃｏｕｎｔ２』とされるテキストグループを含んだデータは、図２２（ａ）に対応した８ビット（Ｐ〜Ｗ）のデータとされる。つまり、ローサブコードエリアには、不要なＰ、Ｑデータも格納されている。そこで、８ビット／６ビット変換を行なうことによって、『Ｃｏｕｎｔ１』〜『Ｃｏｕｎｔ２』におけるテキストグループのみをローテキストエリアに移して、該ローテキストエリアにおいて、後述する例えばトラックタイトルヘッダやサイズインフォメーションヘッダの検証処理を行なうようにしている。
【０１０４】
ローサブコードエリアの他にローテキストエリアを設けるようにした場合、キャッシュメモリ２０内に必要な領域が増えることになる。しかし、検証処理などを行なう場合、Ｒ〜Ｗデータの６ビット毎の検証を行なうよりも、バイト単位で検証を行なう方が、システムコントローラ１０の処理も単純化することができ、さらには、ホストコンピュータ８０に対する転送処理も簡単になる。
【０１０５】
７．テキストデータ有効性検証処理
図２３、図２４は、図１６、図１７で説明したバッファリング処理に続くテキストデータ有効性検証処理の流れを説明するフローチャートを示す図である。なお、図２３に示されているフローチャートの結合子（４）及び結合子（５）は、それぞれ図２４に示されているフローチャートの結合子（４）及び結合子（５）に対応したものである。即ち、テキストデータ有効性検証処理としては図２３乃至図２４に示されている一連の処理行程によって実現される処理とされる。
【０１０６】
テキストデータ有効性検証処理としては、まず図２２で説明した８ビット／６ビット変換を行ない、テキストデータに対応した６ビット（Ｒ〜Ｗ）のデータをローテキストエリアに格納していく（S301）。そして、パックのヘッダ領域の各ＩＤ（ＩＤ１〜ＩＤ４）を示すためのパラメータ『Ｕ』に「０」を設定し、さらにパラメータ『Ｍ』に「０」を設定する行なう（S302）。
【０１０７】
ところで、ステップS301における８ビット／６ビット変換が開始されると、ローテキストデータがローテキストエリアに順次格納されていくことになるが、ここで順次格納されてくるデータに対してスタートヘッダ（先頭パックのヘッダ領域）のサーチを行なう。
スタートヘッダのパターンは、上述したように例えば「８０ｈ，００ｈ，００ｈ，Ｘ０ｈ」とされている。これらのパターンはそれぞれ、図９（ｂ）に示したヘッダ領域のＩＤ１〜ＩＤ４に相当する。したがって、格納されてくるローテキストデータにこのパターンが含まれているか否かを判別することで、スタートヘッダを認識することができる。
【０１０８】
スタートヘッダのサーチ処理としては、先頭のＵ番目のデータ（ＩＤ１に相当する）が１０００００００ｂか否か（S303）、Ｕ＋１番目（ＩＤ２に相当する）のデータが００００００００ｂか否か（S304）、Ｕ＋２番目（ＩＤ３に相当する）のデータが００００００００ｂか否か（S305）、さらにＵ＋３番目（ＩＤ４に相当する）のデータが００００００００ｂまたは１０００００００ｂか否か（S306）の判別を行なう。
【０１０９】
ここでの判定結果として、いずれか一つでも一致しない場合は、パラメータ『Ｕ』のインクリメントを行ない（S313）再びステップS303からステップS306におけるスタートヘッダサーチを行なう。このようにパラメータ『Ｕ』をインクリメントすることにより、前回１番目のデータをＩＤ１に相当するものとしていたが、今回は前回の２番目のデータ、即ち前回ＩＤ２に相当するとしていたデータを、ＩＤ１としてサーチ処理を行なう。このように、被サーチデータをシフトさせていくことで、ローサブコードデータの中から所望するスタートヘッダパターンを検出するようにしている。
【０１１０】
ステップS303からステップS306において、全てのデータのパターンがスタートヘッダパターンに一致すると、パラメータ『Ｍ』をインクリメントする（S307）。
即ちパラメータ『Ｍ』は先程と同様にスタートヘッダの検出回数を示すものとして用いられている。
最初にステップ（S307）に到達した時点では『Ｍ』＝１とされ、これは第一のスタートヘッダが検出されたことを示す。したがって、ステップS308における『Ｍ』の値の判定は「ＮＯ」とされ、スターヘッダに続く２番目のパックのヘッダパターンの検出処理に移行する（S309）。
【０１１１】
ここで、２番目のパックのヘッダパターンの検出処理について説明する。
本例では、スタートヘッダに続くヘッダのタイプとして、例えばトラックタイトルヘッダまたはアルバムタイトルヘッダの検証を行なうこととしている。
図２５はＣＤ−ＴＥＸＴフォーマットに規定されているヘッダタイプの一例を示している。即ち、図１３の一部を詳細に示した図である。
図中（ａ）に示されている部分がアルバムタイトルヘッダとされており、先頭のＩＤ１が「８０ｈ」、続くＩＤ２は「００ｈ」とされる。したがって、少なくともＩＤ１、ＩＤ２がこのようなパターンとされていた場合は、当該ヘッダはアルバムタイトルヘッダとすることができる。
【０１１２】
また、図中（ｂ）で示されている部分がトラックタイトルヘッダとされており、先頭のＩＤ１が「８０ｈ」とされ、続くＩＤ２については曲順を示す「０１ｈ」「０２ｈ」・・・「６３ｈ」とされている。即ち、少なくともＩＤ１及びＩＤ２がこれらの値とされているパターン（例えば１曲目を示す「８０ｈ，０１ｈ」など）はトラックタイトルヘッダと見なすことができる。
そして、後述するようにアルバムタイトルヘッダ、またはトラックタイトルヘッダはパラメータ『Ｍ』＝１とされたスタートヘッダが検出された次（順方向）のパックの先頭、即ち１８バイト後から始まるテキストグループ内の２番目のパックのヘッダパターンとされる。したがって、第一のスタートヘッダとされているテキストグループ内の先頭パックのヘッダ及びこれに続く２番目のパックのヘッダとされる、２個のヘッダの内容によって第一のスタートヘッダが認識されるようにしている。
【０１１３】
したがって、２番目のパックのヘッダパターンを検出する場合のフローチャートは図２６に示されているようになる。但し、この図に示すフローチャートは、図２３のステップS309の処理内容を示している。
ステップS401において、まず次のパックの先頭とされるＵ＋１８番目のデータ（ＩＤ１に相当する）と、これに続くＵ＋１９番目のデータが「８０ｈ，０１ｈ」に一致しているか否かを判別し、各データがそれぞれ「８０ｈ，０１ｈ」に一致していると判別した場合は、所要のへッダ（トラックタイトルヘッダ）が検出されたと見なす（S402）。
【０１１４】
また、各データが「８０ｈ，０１ｈ」に一致していない場合は、Ｕ＋１８番目のデータ、Ｕ＋１９番目のデータ、及びこれに続くＵ＋２０番目のデータ（ＩＤ３に相当する）が、「８０ｈ，００ｈ，０１ｈ」に一致しているか否かを判別する（S402）。ここで判別するヘッダタイプは、ＩＤ１、ＩＤ２による「８０ｈ，００ｈ」からアルバムタイトルヘッダとされる。また、ＩＤ３に示されている「０１ｈ」は上述したようにシーケンスナンバが示されている。これは後述する図２９に示されているが、先頭パックが「００ｈ」、２番目のパックが「０１ｈ」・・・というように、ブロック内における当該パックの順位を示すことができるようになっている。
【０１１５】
したがって、先頭パックのヘッダ（スタートヘッダ）としては「８０ｈ，００ｈ，００ｈ」とされる。そして、記憶されているアルバムタイトルが比較的長いものとされ、例えば先頭パックと２番目のパックにまたがって記憶されている場合は、「８０ｈ，００ｈ，０１ｈ」となる。したがって、２番目のパックの先頭はＩＤ１、ＩＤ２によるトラックタイトルヘッダ「８０ｈ，０１ｈ」、またはＩＤ１、ＩＤ２、及びＩＤ３によるアルバムタイトルヘッダ「８０ｈ，００ｈ，０１ｈ」となる。
したがって、各ヘッダがそれぞれ「８０ｈ，００ｈ，０１ｈ」に一致している判別した場合は、所要のへッダ（アルバムタイトルヘッダ）が検出されたと見なし（S403）、また、一致していないと判別した場合は所要のへッダが検出されなかったとみなす（S404）。
【０１１６】
なお、パックのヘッダ領域はＩＤ１〜１Ｄ４によって形成されるが、これら全てのデータを検出する必要はなく、説明したように少なくとも、ヘッダの判別が可能とされるＩＤの検出を行なうことができれば良い。
また、この図のフローチャートでは例えば、例えばトラックタイトルヘッダ、アルバムタイトルヘッダの検出を行なう例を挙げているが、先頭パックに続く２番目のパックのヘッダであることを検出することができれば、検出項目はいずれのものであっても良い。
【０１１７】
図２３のフローチャートに戻り説明を続ける。
ステップS309を経た後、所要のヘッダが検出されたか否かを判別する（S310）。そして、所要のヘッダが検出された場合は、システムコントローラ１０はＵ番目のデータが格納されているローテキストエリアのアドレスをスタートアドレス（Ｓｔａｒｔ＿Ａｄｒｅｓｓ）であると認識して記憶する（S311）。そして、ステップS313によってパラメータ『Ｕ』のインクリメントを行ない、再度スタートヘッダのサーチ処理を行なう。
【０１１８】
また、ステップS310で所要のヘッダが検出されなかったと判別した場合は、パラメータ『Ｍ』のデクリメントを行ない（S312）、パラメータ『Ｍ』を元の値に戻す。これは、第一のスタートへッダについて、所要のヘッダが検出されなかったという結果に基づいて、再び第一のスタートへッダのサーチを行なうためである。したがって、第一のスタートへッダに対して所要のヘッダが検出されるまで、ステップS308からステップS309に進むようにされる。そして第一のスタートへッダに対して所要のヘッダが検出され、パラメータ『Ｍ』が「２」となった時点で、結合子（４）に対応した処理に進む。
【０１１９】
パラメータ『Ｍ』が「２」となると図２４に示されているように、システムコントローラ１０はＵ番目のデータが格納されているローテキストエリアのアドレスをエンドアドレス（Ｅｎｄ＿Ａｄｒｅｓｓ）であると認識して記憶する（S314）。そして、エンドアドレスの値とスタートアドレスの値の差を求め、この差、即ち各アドレス間のデータ長と、テキストデータの最小単位として規定されているパックの長さ（Ｐａｃｋ＿Ｌｅｎｇｔｈ・・・１８バイト）と比較する（S315）。ここでアドレス間のデータ長がパックの長さよりも長いと判別した場合は、次に、前記各アドレス間のデータ長が、１ブロックが最大２５６パックで形成された場合の最大データ長（Ｍａｘ．ＴＥＸＴ＿Ｌｅｎｇｔｈ・・・３６．８６４Ｋバイト）以下であるか否かを判別する（S316）。そして、前記各アドレス間のデータ長が最大データ長以下であると判別した場合は、サイズインフォメーションヘッダのチェックを行なう（S319）。
つまり、ステップS315、S316を経ることによって第一のスタートヘッダに続く第二のスタートへッダが存在する見なすことができる。そして、さらに第二のスタートへッダの存在を確認するために、この第二のスタートへッダから所定量遡った位置に在る、サイズインフォメーションヘッダのチェック（S319）に移行する。
【０１２０】
なお、ステップS315において各アドレス間のデータ長がパックよりも短い場合や、またステップS316において各アドレス間のデータ長が前記最大データ長よりも長いと判別した場合、システムコントローラ１０はステップS317に進み、エンドアドレスをヘッダの起点であると認識して記憶し、パラメータ『Ｍ』を初期値化「０」する処理を行なう（S318）。これは、第二のスタートへッダが検出されなかったという結果に基づいて、再び第一のスタートへッダのサーチを行なうためである。したがって、パラメータ『Ｍ』を「０」にした後は、結合子（５）を介して図２３に示すステップS303に進む。
【０１２１】
この処理においては、図２５（ｃ）に示したサイズインフォメーションヘッダ＃１〜＃３の検出を行なう。
ところで、サイズインフォメーションヘッダ（＃１〜＃３）としては、図２５（ｃ）に示されているように先頭のＩＤ１が「８Ｆｈ」とされ、続くＩＤ２はそれぞれ「００ｈ」「０１ｈ」「０２ｈ」とされている。即ち、少なくともＩＤ１及びＩＤ２がこれらの値とされているパターンはサイズインフォメーションヘッダと見なすことができる。また、このサイズインフォメーションは、テキストグループの最後の３個のパックのヘッダとされているので、本例では第二のスタートヘッダから遡って検出するようにしている。
【０１２２】
したがって、サイズインフォメーションヘッダチェック（S319）の処理としては、例えば図２７のフローチャートに示されているようにされる。
まずステップS501において、最後のパックの先頭とされるＵ−１８番目のデータ（ＩＤ１に相当する）と、これに続くＵ−１７番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，０２ｈ」に一致しているか否かを判別し、各データがそれぞれ「８Ｆｈ，０２ｈ」に一致していると判別した場合はステップS502に進む。
ステップS502では、最後から２番目のパックの先頭とされるＵ−３６番目のデータ（ＩＤ１に相当する）と、これに続くＵ−３５番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，０１ｈ」に一致しているか否かを判別し、各データがそれぞれ「８Ｆｈ，０１ｈ」に一致していると判別した場合はステップS503に進む。
そして、ステップS503では、最後から３番目のパックの先頭とされるＵ−５４番目のデータ（ＩＤ１に相当する）と、これに続くＵ−５３番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，００ｈ」に一致しているか否かを判別する。
【０１２３】
ステップS501からステップS503を経ることにより、各データがそれぞれ所望するデータ内容に一致していた場合はステップS504に進み、３個のサイズインフォメーションヘッダが検出されたと見なす。
また、ステップS501からステップS503において、一つでも内容が一致しないものが在れば、不一致が検出された時点でステップS505に進みサイズインフォメーションヘッダが検出されていないと見なす。
【０１２４】
このようにして得られたサイズインフォメーションの検出結果に基づいて、図２４に示すステップS319以降の処理を行なう。ステップS319を経た後は、まずサイズインフォメーションヘッダが検出されたか否かの検出を行ない（S320）、ここで、サイズインフォメーションヘッダが検出された場合は、所望するテキストデータが得られたと見なし、図１６、図１７によって開始されているバファリング処理を終了して（S321）、ステップS311で認識したスタートアドレスとステップS314で認識したエンドアドレスの間のテキストデータをホストコンピュータ８０に転送する（S322）。
【０１２５】
再生装置７０としては、上記したような処理によりテキストデータの誤検出を低減することができるので、ホストコンピュータ８０に対しては精度の高いテキストデータを転送することができる。そして、ホストコンピュータ８０では、ディスク９０から読み出された精度の良いテキストデータを利用して所要の表示処理を行なうことができるようになる。
【０１２６】
８．データ例
図２８はバファリング処理を経て、キャッシュメモリ２０のローサブコードエリアに格納されたローサブコードデータの一例を示す図である。
この図に示すローサブコードデータは、ＣＲＣのＮＧ数が例えば９回、バファリングフレーム数（パラメータ『Ｎ』）が例えば１００回とされるデータである。したがって、バファリングされたデータの先頭から９×９６＝８６４バイトは無効とされる。即ち、アドレス０から８６３（ｄｅｃｉ）までのデータは図２０（ｂ）に示したＣＲＣ＿ＮＧ領域に相当する。したがって、９フレーム以降からＣＲＣが「ＯＫ」とされている。
また、スタートヘッダとしては８６４番目からＰ、Ｑデータを含んだ第一のスタートヘッダパターン（２０ｈ，００ｈ，００ｈ，００ｈ・・・実線で囲む）が示され、これは例えば『Ｃｏｕｎｔ１』に対応したデータとされる。そして、１９４４番目から同じくＰ、Ｑデータを含んだ第二のスタートヘッダパターン（２０ｈ，００ｈ，００ｈ，００ｈ）が示されているが、これが『Ｃｏｕｎｔ２』に対応したデータとされる。したがって、この第一、第二のスタートヘッダの間に、所望するテキストデータが存在していると見なし、テキストデータ有効性検証処理を行なう。
【０１２７】
図２９はバファリング処理、テキストデータ有効性検証処理を経て、ローテキストエリアからホストコンピュータ８０に転送されるローテキストデータの一例を示す図である。
この図のデータの先頭に実線で囲んだスタートヘッダに相当するアルバムタイトルヘッダ「８０ｈ，００ｈ，００ｈ，００ｈ」が示され、このスタートヘッダパターンの次に、下線によりアルバムタイトルヘッダ「８０ｈ，００ｈ，０１ｈ」が示されていることが解る。これは、上記したようにスタートヘッダパターンから数えて１８バイト後に位置している。したがって、実線で囲んだ先頭からのデータが第一のスタートヘッダパターンとすることができる。
【０１２８】
なお、この図に示すデータ例では、アルバムタイトルが２つのパックにまたがっているので、１曲目のトラックタイトルヘッダ「８０ｈ，０１ｈ」は３番目のパックのヘッダとされる。したがって、ＩＤ３のシーケンスナンバは「０２ｈ］とされている。つまり、当該ディスク９０のアルバムタイトルが１パックに収まる比較的短い場合は、２番目のパックが１曲目のタイトルに対応し、ＩＤ１〜ＩＤ３までの内容は、「８０ｈ，０１ｈ，０１ｈ」となる。
【０１２９】
また同じく実線で囲んだ８１１番目から実線で囲んだスタートヘッダパターンが示され、このスタートヘッダパターンを所定量遡った位置に、サイズインフォメーションヘッダパターン（「８Ｆｈ，０２ｈ」、「８Ｆｈ，０１ｈ」、「８Ｆ，００ｈ」）が示されていることが解る。したがって、８１１番目からのデータが第二のスタートヘッダパターンとすることができる。
【０１３０】
したがって、これら２個のスタートヘッダに囲まれたデータが、所望するテキストデータとされる。即ち、図２９に示す例では、各スタートヘッダ（「８０ｈ，００ｈ，００ｈ，００ｈ」）の間のデータが、ローテキストエリアからホストコンピュータ８０に転送されるようになる。
【０１３１】
９．変形例
以下、本発明の変形例を説明する。
上記実施の形態では、例えば２個の連続したスタートヘッダを検出して、各スタートヘッダの間の所定のデータ内容の検証を行なう例としたが、例えば図３０の摸式図に示されているように２個以上のスタートヘッダＨ１、Ｈ２、Ｈ３・・・を検出して、これらのスタートヘッダがＣＤ−ＴＥＸＴのフォーマットとして規定されているパターンであった場合にテキストデータの有効性を確認するようにしても良い。
また、例えば２個以上のスタートヘッダを検出した場合、スタートヘッダＨ１、Ｈ２に囲まれたデータの内容（テキストデータ（１））と、スタートヘッダＨ２、Ｈ３に囲まれたデータの内容（テキストデータ（２））を比較して、双方のデータ内容が一致していることを確認した場合には、テキストデータ（（１）及び（２））の有効性を確認するようにしても良い。
【０１３２】
また、上記実施の形態ではバファリング処理によって検出された２個のスタートヘッダの間に在る、アルバムタイトルヘッダ、トラックタイトルヘッダやサイズインフォメーションヘッダの内容が所定のものとされていれば、当該トラックタイトルヘッダやサイズインフォメーションヘッダに対応したテキストデータの有効性を確認したが、他のヘッダ内容によっても有効性の確認を行なうことができる。
【０１３３】
例えば、ヘッダ（図２９の実線で囲んだ部分に相当する）の内容チェックとして、最初の１バイト（ＩＤ１：Ｐａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ）をチェックする場合を例に挙げる。ここで、第一のスタートヘッダがＵ番目にバファリングされ、第二のスタートヘッダがＵ＋Ｎ番目に在るとする。そして、検証対象とする任意のヘッダがＵ＋Ｍ番目（但し、Ｍ＜Ｎ）とした場合、処理の流れとしては図３１のフローチャートに示されているようになる。
【０１３４】
図３１のに示されているように、まず、ＩＤ１が「８０ｈ」であるか否かを判別する（S601）。ここで、ＩＤ１が「８０ｈ」であると判別した場合は、さらにＩＤ２が「０」以上かつ「６３」以下であるか否かを判別する（S602）。そして、ＩＤ２が「０」以上かつ「６３」以下であったと判別した場合は、図１３に示したように、アルバムタイトルヘッダまたはトラックタイトルヘッダであると見なすことができ、テキストデータの有効性を確認することができる（S615）。
また、ＩＤ２が「０」以上かつ「６３」以下ではないと判別した場合、即ちＣＤ−ＴＥＸＴのフォーマットで規定されている値ではない場合には、テキストデータとしての有効性を確認しないで、無効なデータであると認識する（S616）。
【０１３５】
以降、同様にして、ステップS603からステップＳ614に至るまで、各ステップ毎にＩＤ１の内容が「８１ｈ」から「８Ｆｈ」のいずれかに一致しているか否かの判別を行なう。なお、「８１ｈ」から「８Ｆｈ」についてのデータ内容（識別内容）は、図１３に示したものとされる。
このようにしてステップS603〜ステップＳ614においての判別結果が、ＣＤ−ＴＥＸＴのフォーマットで規定されている値に一致していない場合は、ＩＤ１に対応したテキストデータは無効なデータであると認識する（S617）。一方、ステップS603〜ステップＳ614において、一つでも「８１ｈ」から「８Ｆｈ」に一致しているものがあったと判別した場合には、その時点でテキストデータの有効性を確認することができる（S615）。
なお、この図に示すフローチャートでは、一つの任意のヘッダとして例えばＩＤ１（Ｐａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ）のチェックを行なう例を挙げたが、他のヘッダ（ＩＤ２、ＩＤ３、ＩＤ４）について同様の処理を行なうようにしても良い。
【０１３６】
また、ローサブコードエリアに対してローサブコードデータをバファリングした時点で、パックの先頭のＩＤを全てスタートヘッダ（テキストグループの先頭のヘッダ）であるか否かを検出することができるハードウエアを構成するようにすることにより、システムコントローラ１０の処理負担が軽減され、バッファリングを行なうデータ量を必要最小限に低減することができる。
【０１３７】
なお、上記実施の形態は、テキストデータがディスク９０のＴＯＣ領域に記憶されている「モード４」を例に挙げて説明したが、テキストデータがプログラムエリア（主データのエリア）に記憶されている「モード２」に対しても適用することができる。
【０１３８】
【発明の効果】
以上、説明したように本発明は、例えばオーディオＣＤの一種とされるＣＤ−ＴＥＸＴに記憶されている、テキストデータ（文字情報）を構成するテキストグループの先頭にあるスタートヘッダ（先頭パックのヘッダ）を検出するようにしている。これにより、当該テキストグループの開始位置、終了位置を検出することができる。そして、前記スタートヘッダ間にある所定のデータ内容の検証や比較を行なうことにより、前記スタートヘッダの間のデータに対して、テキストデータとしての有効性を確認することができ、テキストデータの誤検出を低減することができるようになる。
【０１３９】
例えば、前記スタートヘッダが検出されるとパックが形成されていることを想定することができる。つまり、前記スタートヘッダの間に在るデータに対して、パックのヘッダに相当するデータ内容を検証し、この検証結果に基づいて前記スタートヘッダ間のデータを前記テキストデータとして認識することができるようになる。したがって、第一のスタートヘッダから順方向における所定の位置にあるパックのヘッダ（例えばアルバムタイトルヘッダ、トラックタイトルヘッダ）と、第二のスタートヘッダから逆方向における所定の位置にあるパックのヘッダ（例えばサイズインフォメーションヘッダ）のパターンを検出することにより、テキストデータの有効性を確認することができる。
つまり、前記スタートヘッダ間の所要の位置にＣＤ−ＴＥＸＴフォーマットに規定されているパックのヘッダに対応したデータパターンを検出することにより、テキストデータの有効性確認が可能となる。
【０１４０】
また、スタートヘッダ間における例えばヘッダ（ＩＤ１・・・パックインジケータ）などの所定の位置にあるデータ内容が、規定されている所定のデータ内容に一致している場合にも、テキストデータの有効性を確認することができる。つまり、読み込まれたデータと規定されているデータの内容の一致、不一致を判定することにより検証結果を得ることができるので、テキストデータの有効性確認の精度を向上することができる。
【０１４１】
また、複数の連続したスタートヘッダを検出するとともに、これらのスタートヘッダの間にある複数のテキストグループに相当するデータ内容を比較して、この比較結果が一致していた場合は、当該テキストグループに相当するテキストデータの有効性を確認することができる。つまり、テキストデータ全体を比較しているので、データの整合性に基づいた有効なテキストデータを得ることができるようになる。
【０１４２】
さらに、スタートヘッダが所定回数検出された時点で、管理情報の読み込みを終了させて、検出されているスタートヘッダに対応した文字情報の検証処理に移行することで、必要以上のデータの読み込み動作を抑制することができ、システムコントローラにかかる負担を抑制することができるようになる。
【０１４３】
また、上記したテキストデータの検証処理を行なう場合、管理情報から文字情報とされるテキストデータのみを抽出して行なうことにより、必要最小限のデータによって検証処理を行なうことができ、処理自体が簡単になるとともに、検証結果が有効であった場合についても、ホストコンピュータに対する転送処理が簡単になる。
【０１４４】
さらに、ディスクからインターリーブされた状態で読み出されたデータ形態の管理情報を、デインターリーブされる前に検出するので、デインターリーブ処理を省略することができるようになる。
【０１４５】
また、前記テキストデータに対する誤り検出符号に基づいて、当該テキストデータに誤りが検出されたときに、スタートヘッダが検出されないまま、それまでに前記テキストデータの誤りが所定回数以上検出されていた場合には、ディスクにテキストデータが記録されていないと判断するようにしている。したがって、必要以上のデータの読み込み動作を抑制したうえで、オーディオＣＤとＣＤ−ＴＥＸＴの識別を行うことができるようになる。
【０１４６】
さらに、ディスクにテキストデータが記録されていないと判断した時点で、ディスクに記録されている情報の読み出しを行うバファリング処理を終了させることで、システムコントローラにかかる負担を抑制することができるようになるという利点がある。
【図面の簡単な説明】
【図１】本発明の実施の形態の再生装置の構成を説明するブロック図である。
【図２】ディスク（ＣＤ）のフレーム構造の説明図である。
【図３】ディスク（ＣＤ）のサブコーディングの説明図である。
【図４】ディスク（ＣＤ）のサブＱデータの説明図である。
【図５】ディスク（ＣＤ）のＴＯＣデータの説明図である。
【図６】テキストデータの構造を包括的に示す説明図である。
【図７】サブコーディングフレームとテキストデータとの構造的な関係を示す説明図である。
【図８】テキストデータとしてパケットの構造を示す説明図である。
【図９】テキストデータの構造として、シンボル単位のデータからパックを形成する過程を説明するための説明図である。
【図１０】パックの構造を示す説明図である。
【図１１】ＩＤ１の構造を示す説明図である。
【図１２】ＩＤ１〜ＩＤ４の構造をそれぞれ示す説明図である。
【図１３】ＩＤ１の定義内容を示す説明図である
【図１４】テキストデータとしてトラックの曲名を格納する場合のパックの構造を示す説明図である。
【図１５】再生処理時のキャッシュメモリのマッピング例を説明する図である。
【図１６】バッファリング処理の行程を説明するフローチャートである。
【図１７】図１７に続くバッファリング処理の行程を説明するフローチャートである。
【図１８】図１７のフローチャートに対応して、ＮＧが検出されている場合にサブコードデータのバッファリングを終了させる処理に進む流れを説明するフローチャート。
【図１９】ＮＧが検出されている場合にサブコードデータのバッファリングを終了させ、有効性を検出する処理に進む流れを説明するフローチャート。
【図２０】再生処理時のキャッシュメモリのローサブコードエリアの内容を摸式的に説明する図である。
【図２１】キャッシュメモリのローサブコードエリアに格納されているローサブコードデータを説明する図である。
【図２２】８ビット／６ビット変換の概要を説明する図である。
【図２３】テキストデータ有効性検証処理の行程を説明するフローチャートである。
【図２４】図２２に続くテキストデータ有効性検証処理の行程を説明するフローチャートである。
【図２５】ヘッダタイプの一例を説明する図である。
【図２６】２番目のパックのヘッダの検証処理を説明するフローチャートである。
【図２７】サイズインフォメーションの検証処理を説明するフローチャートである。
【図２８】ローサブコードデータのデータ例を説明する図である。
【図２９】テキストデータのデータ例を説明する図である。
【図３０】本発明の変形例を説明する摸式図である。
【図３１】本発明の他の変形例を説明するフローチャートである。
【符号の説明】
１ ピックアップ、９ ＲＦアンプ、１０ システムコントローラ、１２ デコーダ、１３ インターフェース部、１４ サーボプロセッサ、２０ キャッシュメモリ、７０ 再生装置、８０ ホストコンピュータ、９０ ディスク
【発明の属する技術分野】
本発明は、ＣＤ−ＴＥＸＴに記憶されている文字情報を再生することができる再生装置に関するものである。
【０００２】
【従来の技術】
例えばオーディオ用のＣＤ（COMPACT DISC）のフォーマットに準拠した上で、そのサブコードデータとして所要の文字情報を記憶したＣＤ−ＴＥＸＴが知られている。記憶される文字情報としては、例えばディスクのタイトルやアーティスト名、楽曲名などの情報とされ、これらの情報を読み出して表示することによって、そのオーディオＣＤに収録されてる情報の内容などを文字で得ることが可能である。
【０００３】
【発明が解決しようとする課題】
しかし、ＣＤ−ＴＥＸＴは、ＥＣＣなどのエラー訂正手段を有していないことが例えばＣＤ−ＲＯＭなどと異なっている。したがって、再生状況によっては、正規のデータが検出されず、これにより文字情報の始まりと終わりが正しく検出することができないという不具合が生じることがあった。
また、文字情報が前記リードイン領域に記憶されている場合は、ディスクのアドレスに基づいたリトライ処理を有効に行なうことができない。
即ち、従来では読み出されたデータにおける文字情報が確かなものか否かを判断することができなかった。
【０００４】
【課題を解決するための手段】
本発明はこのような問題点を解決するために、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された、前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される第一のヘッダ情報を起点とした順方向における所定の位置のデータ内容を検証する第一の検証手段と、前記第一のヘッダ情報に続いて検出される第二のヘッダ情報を起点とした逆方向における所定の位置のデータ内容を検証する第二の検証手段と、前記第一、第二の検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であるか否かを判断することができる判断手段を備えて再生装置を構成する。
【０００５】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される第一のヘッダ情報と、該第一のヘッダ情報に続いて検出される第二のヘッダ情報の間の所定の位置にあるデータ内容が、前記文字情報において規定されている所定のデータ内容に一致しているか否かを検証する検証手段と、前記検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であると判断することができる判断手段を備えて再生装置を構成する。
【０００６】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、ヘッダ情報検出手段によって検出される前記ヘッダ情報の間にあるデータを一つの単位として複数単位のデータの内容を比較を行ない、比較したデータの内容が同等であった場合に、当該データが前記文字情報として有効であると判断することができる判断手段を備えて再生装置を構成する。
【０００７】
さらに、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記ヘッダ情報検出手段によって検出される所要のヘッダ情報に基づいて文字情報の検証処理を行なう検証手段を備え、前記ヘッダ情報検出手段によって所要のヘッダ情報が２回検出された場合、前記再生手段による前記管理情報の読み出しを終了するとともに、前記管理情報検出手段による前記管理情報の検出を終了したうえで、前記検証手段は前記ヘッダ情報に基づいた前記文字情報の検証処理を行なうように再生装置を構成する。
【０００８】
また、主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、前記管理情報検出手段によって検出された前記管理情報を所定の単位毎に順次格納することができるようにされている管理情報記憶手段と、前記文字情報に対する誤り検出符号に基づいて、前記管理情報記憶手段に格納される前記管理情報に含まれる前記文字情報の誤り検出を行う誤り検出手段と、前記管理情報記憶手段に前記所定の単位とされる前記管理情報が格納された場合に、格納された前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、前記誤り検出手段によって前記管理情報記憶手段に格納されている前記文字情報に誤りが検出された場合に、前記ヘッダ情報検出手段によって前記ヘッダ情報が検出されないまま、それまでに前記誤り検出手段によって検出された前記文字情報の誤り回数が前記管理情報の所定の単位数以上となったら、前記記録媒体に前記文字情報が記憶されていないと判別するようにした文字情報有無識別手段を備えて再生装置を構成する。
【０００９】
本発明によれば、記録媒体から読み込んだ管理情報から、この管理情報に含まれる文字情報を示すヘッダ情報に対応した各種データ内容を検証し、所定のデータ内容が検出され場合に、当該ヘッダ情報に対応した文字情報の有効性を確認することができるようにしている。
これにより、文字情報の誤検出を抑制し検出能力を向上させることができ、より正確な文字情報を得ることができるようになる。
【００１０】
また、所定数のヘッダ情報が２回検出された時点で、管理情報の検出を終了したうえで文字情報の検証処理を行なうようにすることにより、それ以降行なう検証処理の処理負担を軽減することができるようになる。
【００１１】
さらに、前記文字情報に対する誤り検出符号に基づいて、当該文字情報に誤りが検出されたときに、ヘッダ情報が検出されないまま、それまでに前記文字情報の誤りが所定回数以上検出されていた場合には、記録媒体に文字情報が記録されていないと判断するようにしているので、必要以上の再生動作を抑制したうえで、記録媒体の種別を識別することができるようになる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態として、ＣＤ−ＴＥＸＴとしてのディスクに対応して、オーディオデータ及びサブコードとしての文字情報を再生することができる再生装置を例に挙げて次に示す順序で説明する。なお、サブコードとして記録される文字情報を「テキストデータ」ともいうこととする。
＜１．再生装置の構成＞
＜２．ＴＯＣ及びサブコード＞
＜３．テキストデータ＞
＜４．再生処理＞
＜５．バファリング処理＞
＜６．８ビット／６ビット変換＞
＜７．テキストデータ有効性検証処理＞
＜８．データ例＞
＜９．変形例＞
【００１３】
１．再生装置の構成
本実施の形態の再生装置に装填される光ディスクは、例えばＣＤ−ＴＥＸＴなどのＣＤ方式のディスクや、ＤＶＤなどが考えられる。もちろん他の種類の光ディスクに対応する再生装置でも本発明は適用できるものである。
【００１４】
図１は本例の再生装置７０の要部のブロック図である。
ディスク９０は、ターンテーブル７に積載され、再生動作時においてスピンドルモータ６によって一定線速度（ＣＬＶ）もしくは一定角速度（ＣＡＶ）で回転駆動される。そしてピックアップ１によってディスク９０にエンボスピット形態や相変化ピット形態などで記録されているデータの読み出しが行なわれることになる。なお本例ではＣＬＶ方式として説明を続ける。
【００１５】
ピックアップ１内には、レーザ光源となるレーザダイオード４や、反射光を検出するためのフォトディテクタ５、レーザ光の出力端となる対物レンズ２、レーザ光を対物レンズ２を介してディスク記録面に照射し、またその反射光をフォトディテクタ５に導く光学系が形成される。
対物レンズ２は二軸機構３によってトラッキング方向及びフォーカス方向に移動可能に保持されている。
またピックアップ１全体はスレッド機構８によりディスク半径方向に移動可能とされている。
【００１６】
ディスク９０からの反射光情報はフォトディテクタ５によって検出され、受光光量に応じた電気信号とされてＲＦアンプ９に供給される。
ＲＦアンプ９には、フォトディテクタ５としての複数の受光素子からの出力電流に対応して電流電圧変換回路、マトリクス演算／増幅回路等を備え、マトリクス演算処理により必要な信号を生成する。例えば再生データであるＲＦ信号、サーボ制御のためのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥなどを生成する。
ＲＦアンプ９から出力される再生ＲＦ信号は２値化回路１１へ、フォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥはサーボプロセッサ１４へ供給される。
【００１７】
ＲＦアンプ９で得られた再生ＲＦ信号は２値化回路１１で２値化されることでいわゆるＥＦＭ信号（８−１４変調信号；ＣＤの場合）もしくはＥＦＭ＋信号（８−１６変調信号；ＤＶＤの場合）とされ、デコーダ１２に供給される。デコーダ１２ではＥＦＭ復調，エラー訂正処理等を行ない、また必要に応じてＣＤ−ＴＥＸＴデコード、ＣＤ−ＲＯＭデコード、またはＭＰＥＧデコードなどを行なってディスク９０から読み取られた情報の再生を行なう。
【００１８】
なおデコーダ１２は、ＥＦＭ復調したデータをデータバッファとしてのキャッシュメモリ２０に蓄積していき、このキャッシュメモリ２０上でエラー訂正処理等を行う。そしてエラー訂正され適正な再生データとされた状態で、キャッシュメモリ２０へのバファリングが完了される。また、本例ではＣＤ−ＴＥＸＴデータを検証する際のローデータ（ＲＡＷ＿ＤＡＴＡ・・・ディスク９０から読み出されインターリーブされていないデータ）のバッファリングエリアとしても用いられる。なお、ローデータのバッファリング処理については後述する。
再生装置７０からの再生出力としては、キャッシュメモリ２０でバファリングされているデータが読み出されて転送出力されることになる。
【００１９】
インターフェース部１３は、外部のホストコンピュータ８０と接続され、ホストコンピュータ８０との間で再生データやリードコマンド等の通信を行う。
即ちキャッシュメモリ２０に格納された再生データは、インターフェース部１３を介してホストコンピュータ８０に転送出力される。
またホストコンピュータ８０からのリードコマンドその他の信号はインターフェース部１３を介してシステムコントローラ１０に供給される。
【００２０】
サーボプロセッサ１４は、ＲＦアンプ９からのフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥや、デコーダ１２もしくはシステムコントローラ１０からのスピンドルエラー信号ＳＰＥ等から、フォーカス、トラッキング、スレッド、スピンドルの各種サーボドライブ信号を生成しサーボ動作を実行させる。
即ちフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥに応じてフォーカスドライブ信号、トラッキングドライブ信号を生成し、二軸ドライバ１６に供給する。二軸ドライバ１６はピックアップ１における二軸機構３のフォーカスコイル、トラッキングコイルを駆動することになる。これによってピックアップ１、ＲＦアンプ９、サーボプロセッサ１４、二軸ドライバ１６、二軸機構３によるトラッキングサーボループ及びフォーカスサーボループが形成される。
【００２１】
またサーボプロセッサ１４はスピンドルモータドライバ１７に対して、スピンドルエラー信号ＳＰＥに応じて生成したスピンドルドライブ信号を供給する。スピンドルモータドライバ１７はスピンドルドライブ信号に応じて例えば３相駆動信号をスピンドルモータ６に印加し、スピンドルモータ６のＣＬＶ回転を実行させる。またサーボプロセッサ１４はシステムコントローラ１０からのスピンドルキック／ブレーキ制御信号に応じてスピンドルドライブ信号を発生させ、スピンドルモータドライバ１７によるスピンドルモータ６の起動、停止、加速、減速などの動作も実行させる。
【００２２】
なお、スピンドルモータ６のＣＬＶ回転としての線速度については、システムコントローラ１０が各種速度に設定できる。
例えばデコーダ１２は、デコード処理に用いるためにＥＦＭ信号に同期した再生クロックを生成するが、この再生クロックから現在の回転速度情報を得ることができる。システムコントローラ１０もしくはデコーダ１２は、このような現在の回転速度情報と、基準速度情報を比較することで、ＣＬＶサーボのためのスピンドルエラー信号ＳＰＥを生成する。従って、システムコントローラ１１は、基準速度情報としての値を切り換えれば、ＣＬＶ回転としての線速度を変化させることができる。例えばある通常の線速度を基準として４倍速、８倍速などの線速度を実現できる。
これによりデータ転送レートの高速化が可能となる。
なお、もちろんＣＡＶ方式であっても回転速度の切換は可能である。
【００２３】
サーボプロセッサ１４は、例えばトラッキングエラー信号ＴＥの低域成分として得られるスレッドエラー信号や、システムコントローラ１０からのアクセス実行制御などに基づいてスレッドドライブ信号を生成し、スレッドドライバ１５に供給する。スレッドドライバ１５はスレッドドライブ信号に応じてスレッド機構８を駆動する。スレッド機構８には図示しないが、ピックアップ１を保持するメインシャフト、スレッドモータ、伝達ギア等による機構を有し、スレッドドライバ１５がスレッドドライブ信号に応じてスレッドモータ８を駆動することで、ピックアップ１の所要のスライド移動が行なわれる。
【００２４】
ピックアップ１におけるレーザダイオード４はレーザドライバ１８によってレーザ発光駆動される。
システムコントローラ１０はディスク９０に対する再生動作を実行させる際に、レーザパワーの制御値をオートパワーコントロール回路１９にセットし、オートパワーコントロール回路１９はセットされたレーザパワーの値に応じてレーザ出力が行われるようにレーザドライバ１８を制御する。
【００２５】
以上のようなサーボ及びデコード、エンコードなどの各種動作はマイクロコンピュータによって形成されたシステムコントローラ１０により制御される。
そしてシステムコントローラ１０は、ホストコンピュータ８０からのコマンドに応じて各種処理を実行する。
例えばホストコンピュータ８０から、ディスク９０に記録されている或るデータの転送を求めるリードコマンドが供給された場合は、まず指示されたアドレスを目的としてシーク動作制御を行う。即ちサーボプロセッサ１４に指令を出し、シークコマンドにより指定されたアドレスをターゲットとするピックアップ１のアクセス動作を実行させる。
その後、その指示されたデータ区間のデータをホストコンピュータ８０に転送するために必要な動作制御を行う。即ちディスク９０からのデータ読出／デコード／バファリング等を行って、要求されたデータを転送する。
【００２６】
ホストコンピュータ８０からのリードコマンド、即ち転送要求としては、要求するデータ区間の最初のアドレスとなる要求スタートアドレスと、その最初のアドレスからの区間長として要求データ長（データレングス）となる。
例えば要求スタートアドレス＝Ｎ、要求データ長＝３という転送要求は、ＬＢＡ「Ｎ」〜ＬＢＡ「Ｎ＋２」の３セクターのデータ転送要求を意味する。ＬＢＡとは論理ブロックアドレス（LOGICAL BLOCK ADDRESS ）であり、ディスク９０のデータセクターに対して与えられているアドレスである。
【００２７】
２．ＴＯＣ及びサブコード
次に、ディスク９０においてリードインエリアに記録されるＴＯＣ、及びサブコードについて説明する。
ディスク９０において記録されるデータの最小単位は１フレームとなる。９８フレームで１ブロック（１サブコーディングフレーム）が構成される。
【００２８】
１フレームの構造は図２のようになる。
１フレームは５８８ビットで構成され、先頭２４ビットが同期データと、これに続く３ビットによるマージンビットが設定され、続いて１４ビットがサブコードデータエリアとされる。そして、その後に１２シンボルのメインデータ及び４シンボルのパリティデータが配される。
【００２９】
この構成のフレームが９８フレームで１ブロックが構成され、９８個のフレームから取り出されたサブコードデータが集められて図３（ａ）のような１ブロックのサブコードデータが形成される。
９８フレームの先頭の第１、第２のフレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）からのサブコードデータは同期パターンとされている。そして、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）までで、各９６ビットのチャンネルデータ、即ちＰ，Ｑ，Ｒ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのサブコードデータが形成される。
【００３０】
このうち、アクセス等、再生に関わる各種制御には再生管理情報とされるＰチャンネルとＱチャンネルが用いられる。但し、Ｐチャンネルはトラックとトラックの間のポーズ部分を示しているのみで、より細かい制御はＱチャンネル（Ｑ1 〜Ｑ96）によって行なわれる。９６ビットのＱチャンネルデータは図３（ｂ）のように構成される。
Ｒチャンネル〜Ｗチャンネルのデータは、テキストデータ群を形成するために設けられるが、これについては後述する。
【００３１】
まずＱ1 〜Ｑ4 の４ビットはコントロールデータとされ、オーディオのチャンネル数、エンファシス、ＣＤ−ＲＯＭの識別などに用いられる。
即ち、４ビットのコントロールデータは次のように定義される。
『０＊＊＊』・・・・２チャンネルオーディオ
『１＊＊＊』・・・・４チャンネルオーディオ
『＊０＊＊』・・・・ＣＤ−ＤＡ（ＣＤデジタルオーディオ；CD-TEXTを含む）
『＊１＊＊』・・・・ＣＤ−ＲＯＭ
『＊＊０＊』・・・・デジタルコピー不可
『＊＊１＊』・・・・デジタルコピー可
『＊＊＊０』・・・・プリエンファシスなし
『＊＊＊１』・・・・プリエンファシスあり
【００３２】
次にＱ5 〜Ｑ8 の４ビットはアドレスとされ、これはサブＱデータのコントロールビットとされている。
このアドレス４ビットが『０００１』である場合は、続くＱ9 〜Ｑ80のサブＱデータはオーディオＱデータであることを示し、また『０１００』である場合は、続くＱ9 〜Ｑ80のサブＱデータがビデオＱデータであることを示している。
そしてＱ9 〜Ｑ80で７２ビットのサブＱデータとされ、残りのＱ81〜Ｑ96はＣＲＣとされる。
【００３３】
リードインエリアにおいては、そこに記録されているサブＱデータが即ちＴＯＣ情報となる。
つまりリードインエリアから読み込まれたＱチャンネルデータにおけるＱ9 〜Ｑ80の７２ビットのサブＱデータは、図４（ａ）のような情報を有するものである。サブＱデータは各８ビットのデータを有している。
【００３４】
まずトラックナンバが記録される。リードインエリアではトラックナンバは『００』に固定される。
続いてＰＯＩＮＴ（ポイント）が記され、さらにトラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥが記録されるが、このＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥは、ＰＯＩＮＴの値によって、次に述べるように意味が決定されている。
【００３５】
ＰＯＩＮＴの値が『０１ｈ』〜『９９ｈ』（ｈは１６進表現であることを示す）のときは、その値はトラックナンバを意味し、この場合ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにおいては、そのトラックナンバのトラックのスタートポイント（絶対時間アドレス）が分（ＰＭＩＮ），秒（ＰＳＥＣ），フレーム番号（ＰＦＲＡＭＥ）として記録されている。
【００３６】
ＰＯＩＮＴの値が『Ａ０ｈ』のときは、ＰＭＩＮに最初のトラックのトラックナンバが記録される。また、ＰＳＥＣの値によってＣＤ−ＤＡ，ＣＤ−Ｉ，ＣＤ−ＲＯＭ（ＸＡ仕様）が区別される。
ＰＯＩＮＴの値が『Ａ１ｈ』のときは、ＰＭＩＮに最後のトラックのトラックナンバが記録される。
ＰＯＩＮＴの値が『Ａ２ｈ』のときは、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにリードアウトエリアのスタートポイントが絶対時間アドレスとして示される。
【００３７】
例えば６トラックが記録されたディスクの場合、このようなサブＱデータによるＴＯＣとしては図５のようにデータが記録されていることになる。
図５に示すようにトラックナンバＴＮＯは全て『００ｈ』である。
ブロックＮＯ．とは上記のように９８フレームによるブロックデータとして読み込まれた１単位のサブＱデータのナンバを示している。
各ＴＯＣデータはそれぞれ３ブロックにわたって同一内容が書かれている。
図示するようにＰＯＩＮＴが『０１ｈ』〜『０６ｈ』の場合、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥとしてトラック＃１〜トラック＃６のスタートポイントが示されている。
【００３８】
そしてＰＯＩＮＴが『Ａ０ｈ』の場合、ＰＭＩＮに最初のトラックナンバとして『０１』が示される。またＰＳＥＣの値によってディスクが識別され、このディスクがＣＤ−ＤＡの場合は、図示するようにＰＳＥＣ＝『００ｈ』とされる。なお、ＣＤ−ＲＯＭ（ＸＡ仕様）の場合は、ＰＳＥＣ＝『２０ｈ』、ＣＤ−Ｉの場合は『１０ｈ』となる。
【００３９】
そしてＰＯＩＮＴの値として『Ａ１ｈ』の位置にＰＭＩＮに最後のトラックのトラックナンバが記録され、さらにＰＯＩＮＴの値として『Ａ２ｈ』の位置には、ＰＭＩＮ，ＰＳＥＣ，ＰＦＲＡＭＥにそれぞれリードアウトエリアのスタートポイントが示される。
ブロックｎ＋２７以降は、ブロックｎ〜ｎ＋２６の内容が再び繰り返して記録されている。
【００４０】
ディスク９０上で実際に音楽等のデータが記録されるトラック＃１〜＃ｎ、及びリードアウトエリアにおいては、そこに記録されているサブＱデータは図４（ｂ）に示されている情報を有する。
まずトラックナンバが記録される。即ち各トラック＃１〜＃ｎでは『０１ｈ』〜『９９ｈ』のいづれかの値となる。またリードアウトエリアではトラックナンバは『ＡＡｈ』とされる。
続いてインデックスとして各トラックをさらに細分化することができる情報が記録される。
【００４１】
そして、トラック内の経過時間としてＭＩＮ（分）、ＳＥＣ（秒）、ＦＲＡＭＥ（フレーム番号）が示される。
さらに、ＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥとして、絶対時間アドレスが分（ＡＭＩＮ），秒（ＡＳＥＣ），フレーム番号（ＡＦＲＡＭＥ）として記録されている。
【００４２】
このようにＴＯＣ及びサブコードが形成されているわけであるが、ディスク上のアドレス、即ちＡＭＩＮ，ＡＳＥＣ，ＡＦＲＡＭＥは、９８フレーム単位で記録されることが理解される。
この９８フレーム（１ブロック）は１サブコーディングフレームと呼ばれ、音声データとしての１秒間には７５サブコーディングフレームが含まれることになる。つまり、アドレスとしての『ＡＦＲＡＭＥ』がとりうる値は『０』〜『７４』となる。なお、後述するフレームチェック処理でデータの連続性がチェックされるのは、このサブコーディングフレーム単位となる。
【００４３】
３．テキストデータ
以降、図２及び図３に示す構造のサブコードに含まれるテキストデータについて説明を行うこととし、まず、図６によりテキストデータの包括的な構造について説明する。
サブコード内に含まれるテキストデータのみを抽出して構造的に見た場合、テキストデータは図６に示すようなものとなる。テキストデータとしての最も大きなデータ単位は、図６（ａ）に示す『テキストグループ』とされる。図６（ａ）においては複数のテキストグループが示されているが、各テキストグループのデータは同一内容とされており、従って、サブコード内においては、同一データ内容の所定数の複数のテキストグループが繰り返し記録されていることになる。
【００４４】
１つのテキストグループは、例えば最大２０４８パック（パックの定義については後述する）により形成するものとされるが、１テキストグループあたりのデータ読出しに要する時間等を考慮して、１テキストグループを５１２パック以内により形成することが推奨されている。この際、１テキストグループあたりのデータ総量としては６５００文字程度となる。
また１つのテキストグループは、図６（ｂ）に示すようにブロック＃０〜ブロック＃ｎにより形成され、例えば最大８ブロック（０≦ｎ≦７となる）であると規定されている。各ブロックは、同一の内容の情報をそれぞれ異なる言語により表記するためのテキストデータが格納されているものとされる。例えば、ブロック＃０には、当該ディスクに対応する各種情報を英語により表記するためのテキストデータが格納されており、ブロック＃１には、ブロック＃０と内容的には同一の情報を日本語により表記するためのテキストデータが格納されているものとされる。
【００４５】
この場合、１テキストグループは最大８ブロックにより形成可能であることから、テキストデータのフォーマットとしては最大８言語に対応することが可能とされる。
１つのブロックは、図６（ｃ）に示すようにパック＃０〜パック＃ｎのデータ単位により形成される。ここでは、１ブロックは最大２５６パックで形成され情報量としては例えば３６．８６４ＫＢｙｔｅとされている。なお、パック内のデータ構造等については、次の図７、図８及び図９により説明する。
【００４６】
図７（ａ）は、図３に示した１サブコーディングフレームをデータ領域別に示すものであり、前述のように１サブコーディングフレームは９８フレームにより形成される。
９８フレームの先頭の第１、第２フレーム（フレーム９８ｎ＋１，フレーム９８ｎ＋２）は、図３で説明したように同期パターンＳ０，Ｓ１の領域とされる。また、第３フレームから第９８フレーム（フレーム９８ｎ＋３〜フレーム９８ｎ＋９８）におけるＰチャンネルはサブコードＰのデータ領域とされ、ＱチャンネルはサブコードＱのデータ領域とされて、前述したようにアクセス等の管理のためのデータが格納される。
【００４７】
そして、第３フレームから第９８フレームにおけるＲチャンネル〜Ｗチャンネルの領域は図のようにパック０〜パック４とされる。各パックのデータサイズは固定長とされて、図７（ｂ）に示すようにシンボル０〜２３の２４シンボルにより形成される。１シンボルは図７（ｃ）に示すように、１フレームにおけるＲ，Ｓ，Ｔ，Ｕ，Ｖ，Ｗのチャンネルデータよりなる６ビットのデータ単位であり、この場合にはＲチャンネルデータがＭＳＢ、ＷチャンネルがＬＳＢとして定義される。
【００４８】
図８は、上記図７（ａ）に示す構造の１サブコーディングフレームから、４つのパック（パック０〜パック４）によるデータ構造を抜き出して示している。
１パックは、図７で説明したように、２４のシンボル（６ビット）により形成されることから、
６ビット×２４／８＝１８バイト
で示されるように１８バイトのデータサイズを有する。そして、図のように１パックは、先頭のＩＤ領域と続くテキストデータ領域により１６バイトを占有し、残りの２バイトはＣＲＣ領域となる。
また、前述のように１サブコーディングフレームにおいては４つのパックが設けられるが、これら４つのパックの集合により形成されるデータ単位はパケットとして定義されている。１パックは２４シンボルにより形成されることから、１パケットは、
２４（シンボル）×４（パック）＝９６（シンボル）
で示されるように９６のシンボルにより形成されるものとみることができる。
【００４９】
図９及び図１０は、図８で示した１パック分のデータをシリアルに表現したものである。
図９（ａ）から分かるように、本実施の形態におけるテキストデータのフォーマットにおいては、６ビットよりなるシンボルをシリアルに配列させたうえで、このデータ列を８ビット（１バイト）ごとに区切るようにしてデータを扱うように規定されている。
【００５０】
本実施の形態のテキストデータのフォーマットでは、図９（ｂ）及び図１０に示すように、パックの先頭からはヘッダ領域としてＩＤ１、ＩＤ２、ＩＤ３、ＩＤ４の４つのＩＤデータが設けられる。なお、ＩＤ１はＰａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ２はＴｒａｃｋ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ３はＳｅｑｕｅｎｃｅ＿Ｎｕｍｂｅｒ＿Ｉｎｄｉｃａｔｏｒ、ＩＤ４はＢｌｏｃｋ＿Ｎｕｍｂｅｒ＿ａｎｄ＿Ｃｈａｒａｃｔｅｒ＿Ｐｏｓｉｔｉｏｎ＿Ｉｎｄｉｃａｔｏｒとされているが、これらの内容については後述する。
【００５１】
本実施の形態のフォーマットとして８ビット（１バイト）ごとに区切ってデータを扱うことにより、これら各ＩＤはそれぞれ８ビット（１バイト）のデータ単位とされることになる。このため、図９（ｂ）に示すように、ヘッダ領域（ＩＤ１〜ＩＤ４）以降の残りの１２バイトがテキストデータ領域として確保され、残りの２バイトがＣＲＣ領域となる。
そして、上記１２バイトのテキストデータ領域も、図１０に示すパックの構造図に示すように、８ビットごとのｔｅｘｔ１〜ｔｅｘｔ１２のデータ単位により扱われるものとされる。
なお、以降の説明では、単に『ヘッダ』という場合はパックの先頭にあるヘッダ領域（ＩＤ１〜ＩＤ４）を示し、テキストグループ内における先頭のパックのヘッダについては『スタートヘッダ』ということとする。
【００５２】
ここで、本実施の形態のテキストデータのフォーマットにおいては、図１１に示すようにテキストデータ対応以外のＣＤのフォーマットに準じて、パックの先頭のＩＤ１の上位３ビットをモード（ＭＯＤＥ）として扱い、続く３ビットをアイテム（ＩＴＥＭ）として扱うことができるようにしている。
そして、上位３ビットのモードとしては、モード４を設定してこの３ビットに対して値『１００』を設定するようにしている。このモード４はＣＤ−ＴＥＸＴフォーマットが提案される前は未定義とされている。こうすることで、例えばテキストデータに対応していない再生装置等にテキストデータが格納されたＣＤを装填しても、モードとして認識不可能とされることでその動作を停止するだけであって、誤動作することはないようにされる。また、モード４としてはテキストデータがリードインエリアに記憶されているモードであるが、この他にも、プログラムエリア（主データが格納されているエリア）に対してテキストデータが記憶されているモード２が知られている。本例ではモード４を例に挙げて説明するが、本発明はモード２を適用している場合にも対応することが可能とされる。
【００５３】
なお、未定義のモードとしてはモード５及びモード６が存在するので、モード４の代わりにこれらのモードに対応する値を設定することも可能である。また、参考までに、使用済みのモードとしては、ＣＤ−Ｇに対応するモード１、ＣＤ−ＭＩＤＩに対応するモード３等が存在する。
なお、ここではアイテム（ＩＴＥＭ）としての値は特に設定されず、後述するように、ＩＤ１により定義する識別内容に応じて下位３ビット以降の値は適宜異なる（実際には下位４ビットのみが変更される）ものとなる。
【００５４】
次に、図１２及び図１３を参照して、本実施の形態が対応するテキストデータフォーマットにおけるヘッダ領域（ＩＤ１、ＩＤ２、ＩＤ３、及びＩＤ４）の各定義内容について説明する。図１２（ａ）〜（ｄ）はそれぞれＩＤ１〜ＩＤ４を示し、図１３はＩＤ１の定義内容を示している。
図１２（ａ）に示すＩＤ１（８ビット）は、当該パックのテキストデータ領域におけるｔｅｘｔ１以降に格納される文字列の内容の種類を識別するためのデータが設定されるものであり、『８０ｈ』〜『８Ｆｈ』の値をとるものとされる。ここで、ＩＤ１について設定される値として上位４ビットが１６進法によりすべて『８』が設定されているのは、図１１で説明したように、ＩＤ１の上位３ビットをモード（ＭＯＤＥ）として扱った場合に『１００』の値が得られるようにして、モード４として識別できるようにするためである。
【００５５】
ＩＤ１に設定される値『８０ｈ』〜『８Ｆｈ』に対応する定義内容は、図１３に示すように規定されている。この図によると、ＩＤ１が『８０ｈ』の場合には、ｔｅｘｔ１以降に格納される文字列の内容が、アルバムタイトル（ＴｉｔｌｅＯｆ Ａｌｂｕｍ Ｎａｍｅ・・・ＩＤ２が『００ｈ』の場合）又はトラックに記録された楽曲等の曲名（Ｔｒａｃｋ Ｔｉｔｌｅ・・・ＩＤ２が『０１ｈ〜６３ｈ』の場合）であることを示すことになる。
また、ＩＤ１が『８１ｈ』の場合には演奏者、指揮者、又はオーケストラ名であることを示し、『８２ｈ』の場合には作詞者名、『８３ｈ』の場合には作曲者名、『８４ｈ』の場合には編曲者名であることを示す。ＩＤ１が『８５ｈ』の場合には、当該ＣＤを供給する者（例えばレコード会社等）や演奏者などからのメッセージであることが示される。
【００５６】
また、ＩＤ１が『８６ｈ』の場合には、例えばカタログナンバやレコード会社の名前等により決められるディスクＩＤであることが示され、『８７ｈ』の場合にはジャンルを示すテキストデータであることが示され、『８８ｈ』の場合にはＴＯＣデータであることが示される。このＴＯＣデータは、例えばＱチャンネルのサブコードデータに準ずる内容を示すものとなる。また、『８９ｈ』の場合には、２ｎｄＴＯＣであることが示される。
ＩＤ１として『８Ａｈ』『８Ｂｈ』『８Ｃｈ』は予約（ＲＥＳＥＲＶＥＤ）とされている。
【００５７】
『８Ｄｈ』は、当該ＣＤの製造管理に関する情報や当該パック内に記録されている内容に関するコメント等であることが示され、『８Ｅｈ』はアルバムのＵＰＣ／ＥＡＮコードやトラックのＩＳＲＣコードであることが示される。
『８Ｆｈ』は、ブロック内のサイズインフォメーション（Ｓｉｚｅ Ｉｎｆｏｒｍａｔｉｏｎ）が示されている。
【００５８】
図１２（ｂ）に示すＩＤ２は、当該パックのテキストデータ領域におけるｔｅｘｔ１以降に格納される文字列がどのトラックに対応するのかをトラックナンバにより示すものとされ、ＩＤ２を形成する８ビットにより、『００ｈ』〜『６３ｈ』（１０進法では０〜９９）の値をとるものとされる。但し、トラックナンバは「１」からインクリメントされるようにして付されていくものであるため、トラックナンバとしては『０１ｈ』〜『６３ｈ』（１０進法では１〜９９）の値をとることになる。値『００ｈ』は、ディスク全体を代表することを意味するものとされる。
ＩＤ２のＭＳＢは、拡張用フラグとされているがここでは常に『０』を設定するものとされ、『１』が設定されると拡張用のフラグが立てられたことになる。
【００５９】
図１２（ｃ）に示すＩＤ３は、当該パックが属するブロック内において、当該パックが何番目のパックであるのかを示すパックのブロック内連番を示すものとされ、ＩＤ３を形成する８ビットにより、『００ｈ』〜『ＦＦｈ』（１０進法では０〜２５５）の値をとるものとされる。
【００６０】
図１２（ｄ）に示すＩＤ４は、現パックのブロック番号（文字コードの識別情報を含む）と、１まとまりの文字列の文字位置を示すものとされる。
ＭＳＢは当該パックにおけるテキストデータが１バイトコードか２バイトコードであるかを示す２バイトコードフラグの領域とされ、値として「１」の場合には２バイトコードであることが示され、「０」の場合には１バイトコードであることが示される。
ＭＳＢに続く上位第２ビットから第４ビットまでの３ビットは、当該パックを含むブロック（図６（ｂ）参照）のブロック番号が示され、２進法で『０００』〜『１１１』（１０進法では０〜７）の値を取るものとされる。図６により説明したようにブロックは最大８つ設けられて、ブロックナンバとしてはブロックナンバ０〜７の値を取り得ることになるが、上記３ビットにより取り得る値はこれに対応したものとなる。
【００６１】
ところで、現状として、少なくともブロック＃０においては、テキストデータとしてＡＳＣＩＩコードを含む８８５９−１コードのみを使用することが規定されている。つまり、ブロック＃０においては、一般的には言語として英語による表記を行うためのテキストデータが格納されることになる。なお、以降の説明においては、便宜上、ブロック０は言語として英語に対応し、文字コードとしてはＡＳＣＩＩコードを用いるものする。ＡＳＣＩＩコード（及び８８５９−１コード）は１バイトコードであることから、ブロック＃０に含まれる全パック内のＩＤ４においては、上位４ビットは『００００』となる。
【００６２】
ＩＤ４の下位４ビットは、現パックにおける文字位置の情報が格納される。つまり、現パックのテキストデータ領域における最初のｔｅｘｔ１に格納されている文字データが、１まとまりの文字列における何番目の文字であるのかを示すものとされ、図１３（ｄ）に示すように、２進法で『００００』〜『１１１１』の値をとる。なお、１６番目以上の文字である場合にはすべて『１１１１』となる。
また、ここでいう「１まとまりの文字列」とは、例えば、トラックの曲名データであれば、この１トラック分の曲名を形成する一連の文字列を意味するものである。
【００６３】
図１４には、トラックごとの曲名を示すテキストデータをテキストデータ領域に格納する場合の１パックの構造例が示されている。この場合、図１２（ａ）及び図１３により説明したように、ＩＤ１は『８０ｈ』とされ、ＩＤ２には、当該パックのテキストデータにより表記するタイトルのトラックに対応するトラックナンバが『０１ｈ』〜『６３ｈ』（トラック１〜９９）により適宜示される。ＩＤ３には、ブロック内における当該パックのブロック内連番が『００ｈ』〜『ＦＦｈ』により示される。ＩＤ４は当該パックを含む現ブロックのブロック番号（図６（ｂ）参照）が第２ビット〜第４ビットの３ビットにより示され、現ブロックが対応する文字コードが２バイトコードか１バイトコードであるかがＭＳＢにより示される。例えば、現パックのテキストデータがＡＳＣＩＩコードに対応するものであれば、前述のようにＩＤ４の上位４ビットは『００００』となる。
【００６４】
また、ＩＤ４の下位４ビットは、ｔｅｘｔ１に格納されている文字データが、１まとまりの文字列における何番目の文字であるのかを示す値が適宜示されることになる。トラックごとの曲名を示すテキストデータの場合、上記「１まとまりの文字列」とは、トラックごとの曲名に対応する文字列がこれに相当するものとされ、例えば、あるトラックの曲名が『ＴＨＩＳ ＩＳ Ａ ＰＥＮ』であるとして、このＴＨＩＳ＿ＩＳ＿Ａ＿ＰＥＮの文字列のうち、２番目の『Ｈ』の文字データが当該パックのｔｅｘｔ１に格納されているとすれば、当該パックのＩＤ４における下位４ビットは『０００１（１ｈ）』とされることになる。
【００６５】
この場合、『ＴＨＩＳ ＩＳ Ａ ＰＥＮ』のうち最初の文字データ『Ｔ』は、当該パックの直前のパックのテキストデータ領域に格納されていることになる。つまりテキストデータは、１まとまりの文字列データが連続するパックをまたがるようにしてテキストデータ領域に格納することが可能とされるフォーマットとされている。
そして、テキストデータ領域である各８ビットのｔｅｘｔ１〜ｔｅｘｔ１２には、本実施の形態のテキストデータフォーマットに則った規則に従って、各トラックの曲名を示す文字コードのデータが格納されることになる。
【００６６】
４．再生処理
本実施の形態におけるテキストデータの再生処理の概要を説明する。まず、ここでは全体の流れを説明し、詳細な説明については順次行なっていくこととする。
【００６７】
上記したように、「モード４］においてはテキストデータはディスク９０のサブコードデータの一部に記録されている。したがって、テキストデータを扱う場合は、まずサブコードデータ（Ｐ〜Ｗ）から不要なデータ（Ｐ、Ｑ）を排除してテキストデータ（Ｒ〜Ｗ）の抽出を行なうことになる。
この場合サブコードデータはデインターリーブを行なわないローデータとしてキャッシュメモリ２０に順次格納していく。ローデータとしては９６バイト（９６ｂｉｔ×８（Ｐ〜Ｗ））、即ち１サブコードフレームに相当するデータ量が１回のバファリング単位とされる。そして、キャッシュメモリ２０に格納されたサブコードデータの中から、所望するテキストデータの位置を識別する検出処理を行なう。この検出処理としてはテキストグループのスタートヘッダを検出するための処理とされる。以降、この処理をバファリング処理という。
【００６８】
バッファリング処理としては、サブコードデータにおいて図６（ａ）に示したテキストグループの先頭とされる位置（先頭パックのヘッダに相当する）を起点とし読み出しを行なうこと望ましいが、実際にはこれは困難な処理とされる。そこで、１回の読み込みではバファリング処理を行なうに際して必要なデータが得られない場合を想定して、キャッシュメモリ２０には少なくとも２テキストグループ分のデータ量に相当するサブコードデータを格納することができるようにして、この格納された２テキストグループ分のサブコードデータの中からスタートヘッダを検出するようにしている。
【００６９】
バッファリング処理を行なう場合、キャッシュメモリ２０は例えば図１５に示されている形態でマッピングされた状態で使用する。ローサブコードエリア（ＲＡＷ＿ＳＵＢ＿ＣＯＤＥ＿ＡＲＥＡ）は、例えば２テキストグループ分のデータ量に相当するのローサブコードデータ（ＲＡＷ＿ＳＵＢ＿ＣＯＤＥ＿ＤＡＴＡ（Ｐ〜Ｗ））を格納することができる領域とされる。
そして、後述するようにローサブコードエリアに格納されたサブコードデータに対してバッファリング処理を行ない、このバファリング処理によって検出された、スタートヘッダに基づいてローテキストデータ（ＲＡＷ＿ＴＥＸＴ＿ＤＡＴＡ（Ｒ〜Ｗ））の抽出（８ビット（Ｐ〜Ｗ）から６ビット（Ｒ〜Ｗ）への変換処理・・・以下、８ビット／６ビット変換処理という）を行なう。ここで、抽出されたローテキストデータは、図１５に示すローテキストエリア（ＲＡＷ＿ＴＥＸＴ＿ＡＲＥＡ）に格納される段階で、データ内容の有効性が検証される。
有効性が確認されたローテキストデータは、ローテキストエリアから読み出されてホストコンピュータ８０に対して転送されるようにされる。即ち、ホストコンピュータ８０に対しては、有効性が確認されたローテキストデータのみを転送することができるようになる。
【００７０】
ところで、図示している各エリアの容量を示す数値は一例である。
前記したように、テキストグループの１ブロックの情報量は上述したように例えば３６．８６４Ｋバイトとされる。したがって、ローテキストエリアに必要な容量としては少なくとも、３６．８６４×２＝７３．７２８Ｋバイト以上であれば良い。
また、ローサブコードエリアは、３６．８６４×８／６＝４９．１５２Ｋバイトが１フレーム分のデータ量に相当するので、２フレームに相当する容量としては４９．１５２×２＝９８．３０４Ｋｂｙｔｅとなる。したがって、ローサブコードエリアに必要な容量は、少なくとも９８．３０４Ｋｂｙｔｅ以上であれば良い。
【００７１】
５．バファリング処理
図１６、図１７は、バッファリング処理の流れを摸式的に説明するフローチャートを示す図である。なお、図１６に示されているフローチャートの結合子（１）は、図１７に示されているフローチャートの結合子（１）に対応したものである。即ち、バファリング処理としては図１６乃至図１７に示されている一連の処理行程によって実現される処理とされる。したがって、各図には連続したステップ番号を付している。
【００７２】
バッファリング処理の開始を指示するコマンドはホストコンピュータ８０から供給される（S001）。ここで、再生装置が受信するコマンドとしては、例えば「Ａ０コマンド」、「Ｐａｃｋｅｔコマンド」などのリードＴＯＣコマンドを拡張してＣＤ−ＴＥＸＴに格納されたテキストデータを読み込む処理を開始するためのコマンドとされる。
このようなコマンドを受信すると、「ＯＰコードチェック」、「ＣＤＢチェック」、「メディアチェック」などの各種チェック処理が行なわれる（S002）。
【００７３】
「ＯＰコードチェック」によって、受信したコマンドのＯＰコードが当該装置に対応しているものかの可否判別が行なわれ、「ＣＤＢチェック」によって、コマンド（１２バイト）の内容が規格に準拠しているかの可否判別が行なわれる。これらの判別結果が「可」とされた場合、「メディアチェック」によって、再生装置７０に装填されているディスク９０が、例えばオーディオＣＤであるか否か（つまり、ＣＤ−ＲＯＭなどではなくＣＤ−ＴＥＸＴとしてテキストデータを有する可能性のあるディスクであるか否か）の判別が行なわれる。なお、ＣＤ−ＴＥＸＴとは種別的にはオーディオＣＤ（ＣＤ−ＤＡ）に含まれるものである。
ディスク９０がオーディオＣＤ（オーディオトラックが存在する）か否かは、上述したＴＯＣにより判別できる。そして通常、ＴＯＣデータはディスク装填時に読み込んでいるため、即座に判別可能である。
【００７４】
ここで、ディスク９０がオーディオＣＤであると判別された場合は、「Ａｌｌｏｃａｔｉｏｎ ｌｅｎｇｔｈ＝０」か否か、即ち、要求するデータ長の確認を行ない（S003）、要求するデータがある場合（「０」でない場合）ステップS004に進む。
なお、各種チェック処理（S002）における判定が「否」であった場合は、その時点で所要のエラー処理が行なわれ、バファリング処理は行なわれないことになる。
【００７５】
要求するデータ長の確認（S003）が終了すると、ファームウエア内の状況の初期化を行なう（S004）。そして、例えば現在当該再生装置７０によってオーディオ再生が行なわれている場合は、その再生処理を強制的に終了する（S005）。但し、現在オーディオ再生処理を行なっていない場合は、この処理行程は省略される。 ステップS005を経ると、さらにキャッシュパラメータの初期化を行なう（S006）。これは、キャッシュメモリ２０の使用形態が、通常の状態から図１５に示した状態（ローサブコードエリアとローテキストエリアがマッピングされる状態）に移行するため、現在まで格納されているデータが不要となるので、これらのデータを無効にするための処理とされる。
そして、本実施の形態のバファリング処理を行なうために実行すべき割り込み処理の切替えを行なう（S007）。これは、例えばデインターリーブをオフにするなど、バファリング処理を行なうための所要の割り込み処理を実行させるためとされる。
【００７６】
図１６のフローチャートにおいて割り込み処理の切替え処理（S007）を経ると、図１７のフローチャートに示されていうように、ディスク９０のリードインエリアのＴＯＣに対するアクセス要求を行なう（S008）。これによりピックアップ１はディスク９０の内周側に記憶されているＴＯＣに対してアクセスを開始する。
さらに、ローサブコードデータが９６バイト分バファリングされた時点で「１」づつインクリメントされるパラメータとして設定される『Ｎ』、テキストグループの先頭を示すヘッダ情報とされるスタートヘッダが検出された回数を示すパラメータとして設定される『Ｍ』、及びＣＲＣのＮＧ回数を示すパラメータとして設定される『ＮＧ数』を初期値化「０」する（S009）。
アクセス開始後は、アクセス完了に対して待機状態となり（S010）、アクセスが完了した時点で、ローサブコードデータのバッファリングを開始する（S011）。即ち、デインターリーブをオフにするとともに、図１５に示したローサブコードエリアに対してローサブコードの格納を開始させる。
【００７７】
そして、ローサブコードエリアに対して所定量のローサブコードデータ（例えば１サブコードに相当するデータ量）が格納されるのを待つことになる（S012）。ここで、所定量のローサブコードデータが格納されると、その時点で割り込み処理として所要の通知処理が行なわれ、システムコントローラ１０ではローサブコードエリアに対してローサブコードデータが格納されたことを認識することができる。なお、この図に示すフローチャートとしてはステップS012の判別処理を便宜上一連の処理行程の一部として示しているが、実際には、この判別処理は随時行なわれているものとされる。つまり、ローサブコードエリアに対するローサブコードデータの読み込みも、随時行なわれている。したがって、以降説明する処理行程は、ローサブコードエリアに所定量のローサブコードデータが格納される度に、随時割り込み処理として行なわれるようにされる。
【００７８】
ローサブコードエリアに所定量のローサブコードデータが蓄えられると、これをカウントするパラメータ『Ｎ』をインクリメント（Ｎ＝Ｎ＋１）する処理を行なう（S013）。そして、蓄えられたローサブコードデータに対してＣＲＣのチェックを行なう（S014）。このＣＲＣチェックは、図８に示した４個のＣＲＣ領域に或る誤り検出符号に対して行われ、チェックによる判定結果としては、４個のＣＲＣ領域全てが「ＯＫ」とされた場合に「ＯＫ」とされ、一つでも「ＮＧ」があった場合には「ＮＧ」とされる。
ステップS014で、ＣＲＣが「ＯＫ」となった場合、即ちローサブコードエリアに蓄えられたローサブコードデータが有効であるとされた場合は、テキストグループの先頭を示すスタートヘッダのパターン（Ｓｔａｒｔ＿Ｈｅａｄｅｒ＿Ｐａｔｔｅｒｎ）のチェックを行なう（S016）。
【００７９】
そして、スタートヘッダの検出の有無の判別を行ない（S017）、スタートヘッダが検出されない場合は、ステップS012に戻る。
また、スタートヘッダが検出された場合は、検出されたスタートヘッダの数をカウントするパラメータ『Ｍ』をインクリメント（Ｍ＝Ｍ＋１）する処理を行ない（S018）、続いて、パラメータ『Ｍ』の値の判別を行なう（S019）。ここで、パラメータ『Ｍ』が「１」以下であると判別した場合は、『Ｃｏｕｎｔ１』にパラメータ『Ｎ』の値を設定して（S020）、ステップS012に戻る。なお、『Ｃｏｕｎｔ１』は、何回目のローサブコードデータの読み込みにおいて第一のスタートヘッダが検出されたかを示すパラメータとされる。
【００８０】
一方、ステップS019においてパラメータ『Ｍ』が「２」または「２」以上であると判別した場合は、『Ｃｏｕｎｔ２』にパラメータ『Ｎ』の値を設定する（S021）。この『Ｃｏｕｎｔ２』は、何回目のローサブコードデータの読み込みにおいて第二のスタートヘッダが検出されたかを示すパラメータとされる。
即ち、パラメータ『Ｍ』が「２」または「２」以上となった時点で、第一のスタートヘッダ及び、第二のスタートヘッダが検出されたことになる。つまり、第一、第二のスタートヘッダ間に１個のテキストグループがバファリングされたとみなすことができる。
【００８１】
以降、このようにして検出された第一、第二のスタートヘッダ間におけるテキストデータの有効性を検証する処理（２）に移行するが、これについては後で図２１にしたがい詳しく説明する。また、ステップS021を経て処理（２）に移行した場合でも、図１７に示したバファリング処理は継続して行なうようにしている。
これにより、後述する処理（２）においてテキストデータの有効性が確認されなかった場合でも、その時点で引き続きキャッシュメモリ２０のローサブコードエリアに格納されているローサブコードデータの検証を行なえば良い。したがって、改めてＴＯＣに対するアクセス処理などを行なう必要がないので、処理効率が向上する。
【００８２】
また、例えば２個のスタートヘッダが検出された時点でローサブコードデータのバッファリングを終了させたうえで、テキストデータの有効性の検証処理に移行するようにしても良い。これは、２個のスタートヘッダが検出されたことによって、その時点で期待されるテキストデータが得られたと見なすようにする処理とされる。これにより、２個のタートヘッダが検出された後は、システムコントローラ１０は前記検証処理のみを実行させれば良いので、処理負担を軽減することが可能である。
【００８３】
ところで、ステップS014においてＣＲＣが「ＮＧ」となった場合は、ＣＲＣのＮＧ回数を示すパラメータとして設定される『ＮＧ数』のインクリメント（ＮＧ数＝ＮＧ数＋１）を行ない（S022）、さらに、『ＮＧ数』が当該再生装置７０に設定されている『ＮＧ許容数』（例えば「４」回）以下であるか否かの判別を行なう（S023）。ここで、『ＮＧ数』が『ＮＧ許容数』以下であった場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
また、『ＮＧ数』が『ＮＧ許容数』以上であった場合は、リトライ処理としてステップS008に戻りＴＯＣに対するアクセス要求を行ない、さらに上述したステップS009からの処理を実行していくようにする。
【００８４】
なお、本例では『ＮＧ許容数』は例えば「４」として、『ＮＧ数』がこれを超えた場合に再びＴＯＣに対するアクセス要求を行なうようにしている。しかし、『ＮＧ数』が例えば２５６（全てのパックについて「ＮＧ」の判定）を超えるような場合、テキストデータを読むことができる見込みがないものと見なして、図１６、図１７に示すフローチャートの処理自体を終了させるようにしても良い。
【００８５】
この場合の処理行程としては、ステップS014、S022を経た後、例えば図１８に示されているようになる。この図１８において、図１７と同一の符号を付した処理ステップについては同じ処理行程を示している。
図示されているように、ステップS022において『ＮＧ数』のインクリメント処理を経ると、パラメータ『Ｍ』、即ち、テキストグループの先頭を示すヘッダ情報とされるスタートヘッダが検出された回数が「０」であるか否かの判別を行う（S701）。そして判別結果が「０」とされスタートヘッダが検出されないと判別した場合は、ローサブコードデータが例えば９６バイトを単位として何回バッファリングされたかを示すパラメータ『Ｎ』が所定値以上であるか否かの判別を行う（S702）。なお、ステップS702における所定値とは、ディスク９０にテキストデータが記憶されているか否かを判別するための閾値として設定される。即ち、ステップS014においてＣＲＣが「ＮＧ」になった時点で、ローサブコードデータが何回バッファリングされたかに基づいて、以降の処理が行われる。
【００８６】
例えば、パラメータ『Ｎ』が所定値以下であったと判別した場合は、さらに、『ＮＧ数』が例えば「６４」を超えたか否かの判別を行う（S703）。このステップS703における閾値とされる「６４」は、先述したようにテキストグループを形成する１ブロックが２５６パック（２５６パック＝６４サブコードフレーム）によって形成されていることに基づいている。
したがってステップS703において「ＮＧ数」が例えば「６４」を超えていたと判別した場合は、再生装置７０に装填されたディスク９０にはテキストデータが格納されていないと判断する（S704）。これにより、テキストデータの読み込むことができる見込みがないものと見なして、バッファリング処理を終了させる（S705）。
また、「ＮＧ数」が例えば「６４」を超えていないと判別した場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
【００８７】
また、ステップS702においてパラメータ「Ｎ」が所定値を超えていなかった場合には、『ＮＧ数』が当該再生装置７０に設定されている『ＮＧ許容数』（例えば「４」回）以下であるか否かの判別を行なう（S023）。ここで、『ＮＧ数』が『ＮＧ許容数』以下であった場合は、リトライ処理としてステップS012に戻り、引き続きサブコードデータが読み込まれるのを待つ。
また、『ＮＧ数』が『ＮＧ許容数』以上であった場合は、リトライ処理としてステップS008に戻りＴＯＣに対するアクセス要求を行ない、図１７で説明した場合と同様にステップS009からの処理を実行していくようにする。
【００８８】
このように、ステップS701、S702、S703を経ることによって、スタートヘッダが検出されず、サブコードデータのバッファリング回数が所定値以下であり、かつＣＲＣの「ＮＧ数」が例えば「６４」以上であった時点で、ディスク９０にテキストデータが格納されていないことを判別することができるようになる。したがって、ディスク９０がオーディオＣＤとしてテキストデータを有していないと判別した時点で、図１６、図１７に示したバッファリング処理を終了させることができる。
つまり、再生装置７０にテキストデータが記憶されていないオーディオＣＤが装填されている場合は、バッファリング処理が開始されると、連続してＣＲＣがＮＧとされる処理ステップを進むことになる。この場合、スタートヘッダは検出されないので、バファリングの回数（S702）及び「ＮＧ数」（S703）に基づいて、当該ディスク９０にテキストデータが記録されているか否かを判別することができるようになる。これにより、バッファリング処理が開始されてから、必要最小限のサブコードデータのバッファリングを行うことで、テキストデータの有無を判別することが可能になる。
【００８９】
ところで、ステップS014においてＣＲＣが「ＮＧ」とされた場合は、図１７において例えば破線で示されている結合子（３）に対応した、図１９に示されているフローチャートの処理を行なうことも考えられる。
この図に示されているフローチャートの処理行程としては、ステップS201に示されてるようにパラメータ『Ｍ』が「０」であるか否かの判別を行ない、ここでパラメータ『Ｍ』が「０」であると判別した場合には、図１７に示したステップS023に進み『ＮＧ数』の判定を行なうようにする。つまり、ステップS201でパラメータ『Ｍ』が「０」であった場合、まだスタートヘッダが検出されていない状態を示しており、したがって、再度スタートヘッダを検出する処理を行なうようにするため、ステップS023におけるＮＧ判定処理を経ることになる。
【００９０】
また、パラメータ『Ｍ』が「０」ではないと判別した場合は、ステップS202に進みパラメータ『Ｍ』が「２」であるか否かの判別を行なう。ここで、パラメータ『Ｍ』が「２」ではないと判別した場合は、図１７に示したステップS008に進みＴＯＣエリアに対するアクセス要求を行なう。一方、パラメータ『Ｍ』が「２」であると判別した場合は、サブコードデータのバッファリング処理を終了して（S203）テキストデータの有効性を検証する処理（２）に進む。
【００９１】
ステップ201及びステップS202の行程により、検出されているスタートヘッダの連続性が検出されるようになる。但し、図１７に示したフローチャートのステップS019において、パラメータ『Ｍ』が例えば「２」または「２」以上とされた場合は、ステップS012を経てテキストデータの有効性を検証する処理（２）に進む行程を説明している。したがって、パラメータ『Ｍ』が「２」または「２」以上とされている場合、スタートヘッダの検出に伴って実行される処理行程として、図１７のステップS019、S021を経て処理（２）に進むことになる。
【００９２】
しかしながら、前述したようにステップS012以降の処理行程は随時行なわれており、現在実行している各判別処理などに対して並行した読み込み処理が行なわれているものとされる。これは、処理中のデータに対して予め次のデータの読み込みを行なう先読み処理に相当する。したがって、ステップS014においてＣＲＣの判定結果が「ＮＧ」とされた場合でも、ステップ201及びステップS202の処理行程において先読みによって連続したスタートヘッダが検出された状態では、当該スタートヘッダに対応したテキストデータに対して有効性の検証を行なうことが可能とされるようにしている。
なお、図１９のフローチャートにおいて、テキストデータの有効性の検証を行なうまえにステップS203においてローサブコードデータのバッファリングを終了しているのは、ＣＲＣ判定が「ＮＧ］とされていることに加え、先読みによって得られたテキストデータを利用すれば良いということから、これ以上バファリング処理を継続しなくても良いという判断を下すことが可能とされるためである。
【００９３】
図２０はバファリング処理によるキャッシュメモリの内容を説明する図であり、図２０（ａ）は、図１７のフローチャートで説明した各パラメータの数値例、図２０（ｂ）は、キャッシュメモリ２０のアドレスに準じたデータ内容を摸式的に示す図である。
【００９４】
パラメータ『Ｎ』は、１フレーム分のサブコードデータがキャッシュメモリ２０のサブコードエリア格納された場合にインクリメントされ、この図に示す例では初期値とされる「０」から「５１７」までの数値が示されている。即ち、図１７におけるステップS012以降の処理が５１７回行なわれたことを示している。これに対応して、図２０（ｂ）に示すキャッシュメモリ２０では、Ｃａｓｈｅ＃１〜Ｃａｓｈｅ＃５１７が示されているが、パラメータ『Ｎ』に対応したエリアにはバッファリングされた１フレーム分のサブコードデータが格納されている。
【００９５】
パラメータ『Ｍ』は、スタートヘッダが検出された時点でインクリメントされ、この図に示す例では『Ｎ』＝「７」、及び『Ｎ』＝「５１６」となった場合に、インクリメントされている。したがって、『Ｎ』＝「７」の時点で第一のスタートヘッダが、また『Ｎ』＝「５１６」の時点で第二のスタートヘッダが検出されたことを示している。
『ＮＧ数』は『Ｎ』＝「１」の時点からインクリメントされ、『Ｎ』＝「４」以降は『ＮＧ数』＝「４」がホールドされている。即ち、『Ｎ』＝「５」以降はＣＲＣ判定が「ＯＫ」とされていることを示している。
【００９６】
『Ｃｏｕｎｔ１』はパラメータ『Ｍ』が１回目にインクリメンとされた時点でのパラメータ『Ｎ』の値が設定され、本例では「７」が設定されている。同様に『Ｃｏｕｎｔ２』はパラメータ『Ｍ』が２回目にインクリメントされた時点で、パラメータ『Ｎ』の値が設定され「５１６」が設定されている。
【００９７】
このようなことから、図２０（ｂ）に示されているように、キャッシュメモリ２０のローサブコードエリアでは、Ｃａｓｈｅ＃１〜Ｃａｓｈｅ＃４がＣＲＣ判定により「ＮＧ」とされたデータとされ、『Ｃｏｕｎｔ１』＝「７」〜『Ｃｏｕｎｔ２』＝「５１６」に相当する、Ｃａｓｈｅ＃７〜Ｃａｓｈｅ＃５１６までの間にテキストグループが存在すると判別することができる。
即ち、これまでの処理が、図１６乃至図１９で示したフローチャートの処理行程によって行なわれる。
なお、Ｃａｓｈｅ＃７〜Ｃａｓｈｅ＃５１６については、後に８ビット／６ビット変換されキャッシュメモリ２０におけるローテキストエリア内に移されることになるが、この処理については後述で詳しく説明することにする。
【００９８】
図１７のフローチャートのステップS016乃至ステップS017においてスタートヘッダを検出する行程を説明したが、ここではその概要を説明する。
例えば１０２４フレーム分のローサブコードデータをバッファリングすることによって、その中からスタートヘッダを検出することも考えられるが、ＣＤ−ＴＥＸＴとして記憶されているデータ容量が比較的小さい場合などは、処理効率が良いものではない。そこで、本例では、ローサブコードデータをローサブコードエリアに格納しつつ、並行して格納されているスタートヘッダの監視を行い、検出されたスタートヘッダの数が２以上である場合、その間に１個のテキストグループがあるという判断を下している。
【００９９】
スタートヘッダのパターンとしては「８０ｈ，００ｈ，００ｈ，Ｘ０ｈ」とされる４バイトのデータとされる。このデータ配列をビットで示すと
「８０ｈ」 ・・・ １０００００００ｂ
「００ｈ」 ・・・ ００００００００ｂ
となる。なお４バイト目の「Ｘ０ｈ」については、「００ｈ」または「８０ｈ」のいずれかであることを示している。つまり、このヘッダパターンは「８０ｈ，００ｈ」から、図１３で説明したようにアルバムタイトルヘッダであることがわかる。
【０１００】
ローサブコードデータがローサブコードエリアに格納された状態では図２１に示されているようになる。この図には、スタートヘッダを含んだＰ〜Ｗに至る８ビットのデータを示している。このデータにおいて、図７（ａ）で説明したパックの先頭（ヘッダ領域）をチェックし、これらのパターンが２回以上検出された場合に、１個のテキストグループが検出されたとすることができる。
【０１０１】
６．８ビット／６ビット変換
ローサブコードエリアに格納されたローサブコードは図２１に示したように８ビット（Ｐ〜Ｗ）とされているが、テキストデータは６ビット（Ｒ〜Ｗ）のデータとされる。したがって、効率の良い処理を行なうためには、８ビットのデータ（Ｐ〜Ｗ）のうちＰ、Ｑデータの２バイトを除去することが必要になる。そこで、後で図２３で説明するフローチャートの処理行程とされる８ビット／６ビット変換処理を行なうようにしている。
【０１０２】
図２２（ａ）は、図２１に示したＲ〜Ｗのデータ配列を、アルファベット（ａ〜ｘ）に対応させて示している。この状態ではＲ〜Ｗのデータは６ビット単位とされる。このように配列されている８ビットのデータからＰ、Ｑデータ（Ｘ印）を除去して再び８ビットに配列し直すと、図２２（ｂ）に示されているようになる。つまり、キャッシュメモリ２０のローテキストエリアには、バイト単位で扱うことができるテキストデータが格納される。
【０１０３】
この処理について、図２０を参照して説明する。
図２０（ｂ）に示されている『Ｃｏｕｎｔ１』〜『Ｃｏｕｎｔ２』とされるテキストグループを含んだデータは、図２２（ａ）に対応した８ビット（Ｐ〜Ｗ）のデータとされる。つまり、ローサブコードエリアには、不要なＰ、Ｑデータも格納されている。そこで、８ビット／６ビット変換を行なうことによって、『Ｃｏｕｎｔ１』〜『Ｃｏｕｎｔ２』におけるテキストグループのみをローテキストエリアに移して、該ローテキストエリアにおいて、後述する例えばトラックタイトルヘッダやサイズインフォメーションヘッダの検証処理を行なうようにしている。
【０１０４】
ローサブコードエリアの他にローテキストエリアを設けるようにした場合、キャッシュメモリ２０内に必要な領域が増えることになる。しかし、検証処理などを行なう場合、Ｒ〜Ｗデータの６ビット毎の検証を行なうよりも、バイト単位で検証を行なう方が、システムコントローラ１０の処理も単純化することができ、さらには、ホストコンピュータ８０に対する転送処理も簡単になる。
【０１０５】
７．テキストデータ有効性検証処理
図２３、図２４は、図１６、図１７で説明したバッファリング処理に続くテキストデータ有効性検証処理の流れを説明するフローチャートを示す図である。なお、図２３に示されているフローチャートの結合子（４）及び結合子（５）は、それぞれ図２４に示されているフローチャートの結合子（４）及び結合子（５）に対応したものである。即ち、テキストデータ有効性検証処理としては図２３乃至図２４に示されている一連の処理行程によって実現される処理とされる。
【０１０６】
テキストデータ有効性検証処理としては、まず図２２で説明した８ビット／６ビット変換を行ない、テキストデータに対応した６ビット（Ｒ〜Ｗ）のデータをローテキストエリアに格納していく（S301）。そして、パックのヘッダ領域の各ＩＤ（ＩＤ１〜ＩＤ４）を示すためのパラメータ『Ｕ』に「０」を設定し、さらにパラメータ『Ｍ』に「０」を設定する行なう（S302）。
【０１０７】
ところで、ステップS301における８ビット／６ビット変換が開始されると、ローテキストデータがローテキストエリアに順次格納されていくことになるが、ここで順次格納されてくるデータに対してスタートヘッダ（先頭パックのヘッダ領域）のサーチを行なう。
スタートヘッダのパターンは、上述したように例えば「８０ｈ，００ｈ，００ｈ，Ｘ０ｈ」とされている。これらのパターンはそれぞれ、図９（ｂ）に示したヘッダ領域のＩＤ１〜ＩＤ４に相当する。したがって、格納されてくるローテキストデータにこのパターンが含まれているか否かを判別することで、スタートヘッダを認識することができる。
【０１０８】
スタートヘッダのサーチ処理としては、先頭のＵ番目のデータ（ＩＤ１に相当する）が１０００００００ｂか否か（S303）、Ｕ＋１番目（ＩＤ２に相当する）のデータが００００００００ｂか否か（S304）、Ｕ＋２番目（ＩＤ３に相当する）のデータが００００００００ｂか否か（S305）、さらにＵ＋３番目（ＩＤ４に相当する）のデータが００００００００ｂまたは１０００００００ｂか否か（S306）の判別を行なう。
【０１０９】
ここでの判定結果として、いずれか一つでも一致しない場合は、パラメータ『Ｕ』のインクリメントを行ない（S313）再びステップS303からステップS306におけるスタートヘッダサーチを行なう。このようにパラメータ『Ｕ』をインクリメントすることにより、前回１番目のデータをＩＤ１に相当するものとしていたが、今回は前回の２番目のデータ、即ち前回ＩＤ２に相当するとしていたデータを、ＩＤ１としてサーチ処理を行なう。このように、被サーチデータをシフトさせていくことで、ローサブコードデータの中から所望するスタートヘッダパターンを検出するようにしている。
【０１１０】
ステップS303からステップS306において、全てのデータのパターンがスタートヘッダパターンに一致すると、パラメータ『Ｍ』をインクリメントする（S307）。
即ちパラメータ『Ｍ』は先程と同様にスタートヘッダの検出回数を示すものとして用いられている。
最初にステップ（S307）に到達した時点では『Ｍ』＝１とされ、これは第一のスタートヘッダが検出されたことを示す。したがって、ステップS308における『Ｍ』の値の判定は「ＮＯ」とされ、スターヘッダに続く２番目のパックのヘッダパターンの検出処理に移行する（S309）。
【０１１１】
ここで、２番目のパックのヘッダパターンの検出処理について説明する。
本例では、スタートヘッダに続くヘッダのタイプとして、例えばトラックタイトルヘッダまたはアルバムタイトルヘッダの検証を行なうこととしている。
図２５はＣＤ−ＴＥＸＴフォーマットに規定されているヘッダタイプの一例を示している。即ち、図１３の一部を詳細に示した図である。
図中（ａ）に示されている部分がアルバムタイトルヘッダとされており、先頭のＩＤ１が「８０ｈ」、続くＩＤ２は「００ｈ」とされる。したがって、少なくともＩＤ１、ＩＤ２がこのようなパターンとされていた場合は、当該ヘッダはアルバムタイトルヘッダとすることができる。
【０１１２】
また、図中（ｂ）で示されている部分がトラックタイトルヘッダとされており、先頭のＩＤ１が「８０ｈ」とされ、続くＩＤ２については曲順を示す「０１ｈ」「０２ｈ」・・・「６３ｈ」とされている。即ち、少なくともＩＤ１及びＩＤ２がこれらの値とされているパターン（例えば１曲目を示す「８０ｈ，０１ｈ」など）はトラックタイトルヘッダと見なすことができる。
そして、後述するようにアルバムタイトルヘッダ、またはトラックタイトルヘッダはパラメータ『Ｍ』＝１とされたスタートヘッダが検出された次（順方向）のパックの先頭、即ち１８バイト後から始まるテキストグループ内の２番目のパックのヘッダパターンとされる。したがって、第一のスタートヘッダとされているテキストグループ内の先頭パックのヘッダ及びこれに続く２番目のパックのヘッダとされる、２個のヘッダの内容によって第一のスタートヘッダが認識されるようにしている。
【０１１３】
したがって、２番目のパックのヘッダパターンを検出する場合のフローチャートは図２６に示されているようになる。但し、この図に示すフローチャートは、図２３のステップS309の処理内容を示している。
ステップS401において、まず次のパックの先頭とされるＵ＋１８番目のデータ（ＩＤ１に相当する）と、これに続くＵ＋１９番目のデータが「８０ｈ，０１ｈ」に一致しているか否かを判別し、各データがそれぞれ「８０ｈ，０１ｈ」に一致していると判別した場合は、所要のへッダ（トラックタイトルヘッダ）が検出されたと見なす（S402）。
【０１１４】
また、各データが「８０ｈ，０１ｈ」に一致していない場合は、Ｕ＋１８番目のデータ、Ｕ＋１９番目のデータ、及びこれに続くＵ＋２０番目のデータ（ＩＤ３に相当する）が、「８０ｈ，００ｈ，０１ｈ」に一致しているか否かを判別する（S402）。ここで判別するヘッダタイプは、ＩＤ１、ＩＤ２による「８０ｈ，００ｈ」からアルバムタイトルヘッダとされる。また、ＩＤ３に示されている「０１ｈ」は上述したようにシーケンスナンバが示されている。これは後述する図２９に示されているが、先頭パックが「００ｈ」、２番目のパックが「０１ｈ」・・・というように、ブロック内における当該パックの順位を示すことができるようになっている。
【０１１５】
したがって、先頭パックのヘッダ（スタートヘッダ）としては「８０ｈ，００ｈ，００ｈ」とされる。そして、記憶されているアルバムタイトルが比較的長いものとされ、例えば先頭パックと２番目のパックにまたがって記憶されている場合は、「８０ｈ，００ｈ，０１ｈ」となる。したがって、２番目のパックの先頭はＩＤ１、ＩＤ２によるトラックタイトルヘッダ「８０ｈ，０１ｈ」、またはＩＤ１、ＩＤ２、及びＩＤ３によるアルバムタイトルヘッダ「８０ｈ，００ｈ，０１ｈ」となる。
したがって、各ヘッダがそれぞれ「８０ｈ，００ｈ，０１ｈ」に一致している判別した場合は、所要のへッダ（アルバムタイトルヘッダ）が検出されたと見なし（S403）、また、一致していないと判別した場合は所要のへッダが検出されなかったとみなす（S404）。
【０１１６】
なお、パックのヘッダ領域はＩＤ１〜１Ｄ４によって形成されるが、これら全てのデータを検出する必要はなく、説明したように少なくとも、ヘッダの判別が可能とされるＩＤの検出を行なうことができれば良い。
また、この図のフローチャートでは例えば、例えばトラックタイトルヘッダ、アルバムタイトルヘッダの検出を行なう例を挙げているが、先頭パックに続く２番目のパックのヘッダであることを検出することができれば、検出項目はいずれのものであっても良い。
【０１１７】
図２３のフローチャートに戻り説明を続ける。
ステップS309を経た後、所要のヘッダが検出されたか否かを判別する（S310）。そして、所要のヘッダが検出された場合は、システムコントローラ１０はＵ番目のデータが格納されているローテキストエリアのアドレスをスタートアドレス（Ｓｔａｒｔ＿Ａｄｒｅｓｓ）であると認識して記憶する（S311）。そして、ステップS313によってパラメータ『Ｕ』のインクリメントを行ない、再度スタートヘッダのサーチ処理を行なう。
【０１１８】
また、ステップS310で所要のヘッダが検出されなかったと判別した場合は、パラメータ『Ｍ』のデクリメントを行ない（S312）、パラメータ『Ｍ』を元の値に戻す。これは、第一のスタートへッダについて、所要のヘッダが検出されなかったという結果に基づいて、再び第一のスタートへッダのサーチを行なうためである。したがって、第一のスタートへッダに対して所要のヘッダが検出されるまで、ステップS308からステップS309に進むようにされる。そして第一のスタートへッダに対して所要のヘッダが検出され、パラメータ『Ｍ』が「２」となった時点で、結合子（４）に対応した処理に進む。
【０１１９】
パラメータ『Ｍ』が「２」となると図２４に示されているように、システムコントローラ１０はＵ番目のデータが格納されているローテキストエリアのアドレスをエンドアドレス（Ｅｎｄ＿Ａｄｒｅｓｓ）であると認識して記憶する（S314）。そして、エンドアドレスの値とスタートアドレスの値の差を求め、この差、即ち各アドレス間のデータ長と、テキストデータの最小単位として規定されているパックの長さ（Ｐａｃｋ＿Ｌｅｎｇｔｈ・・・１８バイト）と比較する（S315）。ここでアドレス間のデータ長がパックの長さよりも長いと判別した場合は、次に、前記各アドレス間のデータ長が、１ブロックが最大２５６パックで形成された場合の最大データ長（Ｍａｘ．ＴＥＸＴ＿Ｌｅｎｇｔｈ・・・３６．８６４Ｋバイト）以下であるか否かを判別する（S316）。そして、前記各アドレス間のデータ長が最大データ長以下であると判別した場合は、サイズインフォメーションヘッダのチェックを行なう（S319）。
つまり、ステップS315、S316を経ることによって第一のスタートヘッダに続く第二のスタートへッダが存在する見なすことができる。そして、さらに第二のスタートへッダの存在を確認するために、この第二のスタートへッダから所定量遡った位置に在る、サイズインフォメーションヘッダのチェック（S319）に移行する。
【０１２０】
なお、ステップS315において各アドレス間のデータ長がパックよりも短い場合や、またステップS316において各アドレス間のデータ長が前記最大データ長よりも長いと判別した場合、システムコントローラ１０はステップS317に進み、エンドアドレスをヘッダの起点であると認識して記憶し、パラメータ『Ｍ』を初期値化「０」する処理を行なう（S318）。これは、第二のスタートへッダが検出されなかったという結果に基づいて、再び第一のスタートへッダのサーチを行なうためである。したがって、パラメータ『Ｍ』を「０」にした後は、結合子（５）を介して図２３に示すステップS303に進む。
【０１２１】
この処理においては、図２５（ｃ）に示したサイズインフォメーションヘッダ＃１〜＃３の検出を行なう。
ところで、サイズインフォメーションヘッダ（＃１〜＃３）としては、図２５（ｃ）に示されているように先頭のＩＤ１が「８Ｆｈ」とされ、続くＩＤ２はそれぞれ「００ｈ」「０１ｈ」「０２ｈ」とされている。即ち、少なくともＩＤ１及びＩＤ２がこれらの値とされているパターンはサイズインフォメーションヘッダと見なすことができる。また、このサイズインフォメーションは、テキストグループの最後の３個のパックのヘッダとされているので、本例では第二のスタートヘッダから遡って検出するようにしている。
【０１２２】
したがって、サイズインフォメーションヘッダチェック（S319）の処理としては、例えば図２７のフローチャートに示されているようにされる。
まずステップS501において、最後のパックの先頭とされるＵ−１８番目のデータ（ＩＤ１に相当する）と、これに続くＵ−１７番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，０２ｈ」に一致しているか否かを判別し、各データがそれぞれ「８Ｆｈ，０２ｈ」に一致していると判別した場合はステップS502に進む。
ステップS502では、最後から２番目のパックの先頭とされるＵ−３６番目のデータ（ＩＤ１に相当する）と、これに続くＵ−３５番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，０１ｈ」に一致しているか否かを判別し、各データがそれぞれ「８Ｆｈ，０１ｈ」に一致していると判別した場合はステップS503に進む。
そして、ステップS503では、最後から３番目のパックの先頭とされるＵ−５４番目のデータ（ＩＤ１に相当する）と、これに続くＵ−５３番目のデータ（ＩＤ２に相当する）が「８Ｆｈ，００ｈ」に一致しているか否かを判別する。
【０１２３】
ステップS501からステップS503を経ることにより、各データがそれぞれ所望するデータ内容に一致していた場合はステップS504に進み、３個のサイズインフォメーションヘッダが検出されたと見なす。
また、ステップS501からステップS503において、一つでも内容が一致しないものが在れば、不一致が検出された時点でステップS505に進みサイズインフォメーションヘッダが検出されていないと見なす。
【０１２４】
このようにして得られたサイズインフォメーションの検出結果に基づいて、図２４に示すステップS319以降の処理を行なう。ステップS319を経た後は、まずサイズインフォメーションヘッダが検出されたか否かの検出を行ない（S320）、ここで、サイズインフォメーションヘッダが検出された場合は、所望するテキストデータが得られたと見なし、図１６、図１７によって開始されているバファリング処理を終了して（S321）、ステップS311で認識したスタートアドレスとステップS314で認識したエンドアドレスの間のテキストデータをホストコンピュータ８０に転送する（S322）。
【０１２５】
再生装置７０としては、上記したような処理によりテキストデータの誤検出を低減することができるので、ホストコンピュータ８０に対しては精度の高いテキストデータを転送することができる。そして、ホストコンピュータ８０では、ディスク９０から読み出された精度の良いテキストデータを利用して所要の表示処理を行なうことができるようになる。
【０１２６】
８．データ例
図２８はバファリング処理を経て、キャッシュメモリ２０のローサブコードエリアに格納されたローサブコードデータの一例を示す図である。
この図に示すローサブコードデータは、ＣＲＣのＮＧ数が例えば９回、バファリングフレーム数（パラメータ『Ｎ』）が例えば１００回とされるデータである。したがって、バファリングされたデータの先頭から９×９６＝８６４バイトは無効とされる。即ち、アドレス０から８６３（ｄｅｃｉ）までのデータは図２０（ｂ）に示したＣＲＣ＿ＮＧ領域に相当する。したがって、９フレーム以降からＣＲＣが「ＯＫ」とされている。
また、スタートヘッダとしては８６４番目からＰ、Ｑデータを含んだ第一のスタートヘッダパターン（２０ｈ，００ｈ，００ｈ，００ｈ・・・実線で囲む）が示され、これは例えば『Ｃｏｕｎｔ１』に対応したデータとされる。そして、１９４４番目から同じくＰ、Ｑデータを含んだ第二のスタートヘッダパターン（２０ｈ，００ｈ，００ｈ，００ｈ）が示されているが、これが『Ｃｏｕｎｔ２』に対応したデータとされる。したがって、この第一、第二のスタートヘッダの間に、所望するテキストデータが存在していると見なし、テキストデータ有効性検証処理を行なう。
【０１２７】
図２９はバファリング処理、テキストデータ有効性検証処理を経て、ローテキストエリアからホストコンピュータ８０に転送されるローテキストデータの一例を示す図である。
この図のデータの先頭に実線で囲んだスタートヘッダに相当するアルバムタイトルヘッダ「８０ｈ，００ｈ，００ｈ，００ｈ」が示され、このスタートヘッダパターンの次に、下線によりアルバムタイトルヘッダ「８０ｈ，００ｈ，０１ｈ」が示されていることが解る。これは、上記したようにスタートヘッダパターンから数えて１８バイト後に位置している。したがって、実線で囲んだ先頭からのデータが第一のスタートヘッダパターンとすることができる。
【０１２８】
なお、この図に示すデータ例では、アルバムタイトルが２つのパックにまたがっているので、１曲目のトラックタイトルヘッダ「８０ｈ，０１ｈ」は３番目のパックのヘッダとされる。したがって、ＩＤ３のシーケンスナンバは「０２ｈ］とされている。つまり、当該ディスク９０のアルバムタイトルが１パックに収まる比較的短い場合は、２番目のパックが１曲目のタイトルに対応し、ＩＤ１〜ＩＤ３までの内容は、「８０ｈ，０１ｈ，０１ｈ」となる。
【０１２９】
また同じく実線で囲んだ８１１番目から実線で囲んだスタートヘッダパターンが示され、このスタートヘッダパターンを所定量遡った位置に、サイズインフォメーションヘッダパターン（「８Ｆｈ，０２ｈ」、「８Ｆｈ，０１ｈ」、「８Ｆ，００ｈ」）が示されていることが解る。したがって、８１１番目からのデータが第二のスタートヘッダパターンとすることができる。
【０１３０】
したがって、これら２個のスタートヘッダに囲まれたデータが、所望するテキストデータとされる。即ち、図２９に示す例では、各スタートヘッダ（「８０ｈ，００ｈ，００ｈ，００ｈ」）の間のデータが、ローテキストエリアからホストコンピュータ８０に転送されるようになる。
【０１３１】
９．変形例
以下、本発明の変形例を説明する。
上記実施の形態では、例えば２個の連続したスタートヘッダを検出して、各スタートヘッダの間の所定のデータ内容の検証を行なう例としたが、例えば図３０の摸式図に示されているように２個以上のスタートヘッダＨ１、Ｈ２、Ｈ３・・・を検出して、これらのスタートヘッダがＣＤ−ＴＥＸＴのフォーマットとして規定されているパターンであった場合にテキストデータの有効性を確認するようにしても良い。
また、例えば２個以上のスタートヘッダを検出した場合、スタートヘッダＨ１、Ｈ２に囲まれたデータの内容（テキストデータ（１））と、スタートヘッダＨ２、Ｈ３に囲まれたデータの内容（テキストデータ（２））を比較して、双方のデータ内容が一致していることを確認した場合には、テキストデータ（（１）及び（２））の有効性を確認するようにしても良い。
【０１３２】
また、上記実施の形態ではバファリング処理によって検出された２個のスタートヘッダの間に在る、アルバムタイトルヘッダ、トラックタイトルヘッダやサイズインフォメーションヘッダの内容が所定のものとされていれば、当該トラックタイトルヘッダやサイズインフォメーションヘッダに対応したテキストデータの有効性を確認したが、他のヘッダ内容によっても有効性の確認を行なうことができる。
【０１３３】
例えば、ヘッダ（図２９の実線で囲んだ部分に相当する）の内容チェックとして、最初の１バイト（ＩＤ１：Ｐａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ）をチェックする場合を例に挙げる。ここで、第一のスタートヘッダがＵ番目にバファリングされ、第二のスタートヘッダがＵ＋Ｎ番目に在るとする。そして、検証対象とする任意のヘッダがＵ＋Ｍ番目（但し、Ｍ＜Ｎ）とした場合、処理の流れとしては図３１のフローチャートに示されているようになる。
【０１３４】
図３１のに示されているように、まず、ＩＤ１が「８０ｈ」であるか否かを判別する（S601）。ここで、ＩＤ１が「８０ｈ」であると判別した場合は、さらにＩＤ２が「０」以上かつ「６３」以下であるか否かを判別する（S602）。そして、ＩＤ２が「０」以上かつ「６３」以下であったと判別した場合は、図１３に示したように、アルバムタイトルヘッダまたはトラックタイトルヘッダであると見なすことができ、テキストデータの有効性を確認することができる（S615）。
また、ＩＤ２が「０」以上かつ「６３」以下ではないと判別した場合、即ちＣＤ−ＴＥＸＴのフォーマットで規定されている値ではない場合には、テキストデータとしての有効性を確認しないで、無効なデータであると認識する（S616）。
【０１３５】
以降、同様にして、ステップS603からステップＳ614に至るまで、各ステップ毎にＩＤ１の内容が「８１ｈ」から「８Ｆｈ」のいずれかに一致しているか否かの判別を行なう。なお、「８１ｈ」から「８Ｆｈ」についてのデータ内容（識別内容）は、図１３に示したものとされる。
このようにしてステップS603〜ステップＳ614においての判別結果が、ＣＤ−ＴＥＸＴのフォーマットで規定されている値に一致していない場合は、ＩＤ１に対応したテキストデータは無効なデータであると認識する（S617）。一方、ステップS603〜ステップＳ614において、一つでも「８１ｈ」から「８Ｆｈ」に一致しているものがあったと判別した場合には、その時点でテキストデータの有効性を確認することができる（S615）。
なお、この図に示すフローチャートでは、一つの任意のヘッダとして例えばＩＤ１（Ｐａｃｋ＿Ｔｙｐｅ＿Ｉｎｄｉｃａｔｏｒ）のチェックを行なう例を挙げたが、他のヘッダ（ＩＤ２、ＩＤ３、ＩＤ４）について同様の処理を行なうようにしても良い。
【０１３６】
また、ローサブコードエリアに対してローサブコードデータをバファリングした時点で、パックの先頭のＩＤを全てスタートヘッダ（テキストグループの先頭のヘッダ）であるか否かを検出することができるハードウエアを構成するようにすることにより、システムコントローラ１０の処理負担が軽減され、バッファリングを行なうデータ量を必要最小限に低減することができる。
【０１３７】
なお、上記実施の形態は、テキストデータがディスク９０のＴＯＣ領域に記憶されている「モード４」を例に挙げて説明したが、テキストデータがプログラムエリア（主データのエリア）に記憶されている「モード２」に対しても適用することができる。
【０１３８】
【発明の効果】
以上、説明したように本発明は、例えばオーディオＣＤの一種とされるＣＤ−ＴＥＸＴに記憶されている、テキストデータ（文字情報）を構成するテキストグループの先頭にあるスタートヘッダ（先頭パックのヘッダ）を検出するようにしている。これにより、当該テキストグループの開始位置、終了位置を検出することができる。そして、前記スタートヘッダ間にある所定のデータ内容の検証や比較を行なうことにより、前記スタートヘッダの間のデータに対して、テキストデータとしての有効性を確認することができ、テキストデータの誤検出を低減することができるようになる。
【０１３９】
例えば、前記スタートヘッダが検出されるとパックが形成されていることを想定することができる。つまり、前記スタートヘッダの間に在るデータに対して、パックのヘッダに相当するデータ内容を検証し、この検証結果に基づいて前記スタートヘッダ間のデータを前記テキストデータとして認識することができるようになる。したがって、第一のスタートヘッダから順方向における所定の位置にあるパックのヘッダ（例えばアルバムタイトルヘッダ、トラックタイトルヘッダ）と、第二のスタートヘッダから逆方向における所定の位置にあるパックのヘッダ（例えばサイズインフォメーションヘッダ）のパターンを検出することにより、テキストデータの有効性を確認することができる。
つまり、前記スタートヘッダ間の所要の位置にＣＤ−ＴＥＸＴフォーマットに規定されているパックのヘッダに対応したデータパターンを検出することにより、テキストデータの有効性確認が可能となる。
【０１４０】
また、スタートヘッダ間における例えばヘッダ（ＩＤ１・・・パックインジケータ）などの所定の位置にあるデータ内容が、規定されている所定のデータ内容に一致している場合にも、テキストデータの有効性を確認することができる。つまり、読み込まれたデータと規定されているデータの内容の一致、不一致を判定することにより検証結果を得ることができるので、テキストデータの有効性確認の精度を向上することができる。
【０１４１】
また、複数の連続したスタートヘッダを検出するとともに、これらのスタートヘッダの間にある複数のテキストグループに相当するデータ内容を比較して、この比較結果が一致していた場合は、当該テキストグループに相当するテキストデータの有効性を確認することができる。つまり、テキストデータ全体を比較しているので、データの整合性に基づいた有効なテキストデータを得ることができるようになる。
【０１４２】
さらに、スタートヘッダが所定回数検出された時点で、管理情報の読み込みを終了させて、検出されているスタートヘッダに対応した文字情報の検証処理に移行することで、必要以上のデータの読み込み動作を抑制することができ、システムコントローラにかかる負担を抑制することができるようになる。
【０１４３】
また、上記したテキストデータの検証処理を行なう場合、管理情報から文字情報とされるテキストデータのみを抽出して行なうことにより、必要最小限のデータによって検証処理を行なうことができ、処理自体が簡単になるとともに、検証結果が有効であった場合についても、ホストコンピュータに対する転送処理が簡単になる。
【０１４４】
さらに、ディスクからインターリーブされた状態で読み出されたデータ形態の管理情報を、デインターリーブされる前に検出するので、デインターリーブ処理を省略することができるようになる。
【０１４５】
また、前記テキストデータに対する誤り検出符号に基づいて、当該テキストデータに誤りが検出されたときに、スタートヘッダが検出されないまま、それまでに前記テキストデータの誤りが所定回数以上検出されていた場合には、ディスクにテキストデータが記録されていないと判断するようにしている。したがって、必要以上のデータの読み込み動作を抑制したうえで、オーディオＣＤとＣＤ−ＴＥＸＴの識別を行うことができるようになる。
【０１４６】
さらに、ディスクにテキストデータが記録されていないと判断した時点で、ディスクに記録されている情報の読み出しを行うバファリング処理を終了させることで、システムコントローラにかかる負担を抑制することができるようになるという利点がある。
【図面の簡単な説明】
【図１】本発明の実施の形態の再生装置の構成を説明するブロック図である。
【図２】ディスク（ＣＤ）のフレーム構造の説明図である。
【図３】ディスク（ＣＤ）のサブコーディングの説明図である。
【図４】ディスク（ＣＤ）のサブＱデータの説明図である。
【図５】ディスク（ＣＤ）のＴＯＣデータの説明図である。
【図６】テキストデータの構造を包括的に示す説明図である。
【図７】サブコーディングフレームとテキストデータとの構造的な関係を示す説明図である。
【図８】テキストデータとしてパケットの構造を示す説明図である。
【図９】テキストデータの構造として、シンボル単位のデータからパックを形成する過程を説明するための説明図である。
【図１０】パックの構造を示す説明図である。
【図１１】ＩＤ１の構造を示す説明図である。
【図１２】ＩＤ１〜ＩＤ４の構造をそれぞれ示す説明図である。
【図１３】ＩＤ１の定義内容を示す説明図である
【図１４】テキストデータとしてトラックの曲名を格納する場合のパックの構造を示す説明図である。
【図１５】再生処理時のキャッシュメモリのマッピング例を説明する図である。
【図１６】バッファリング処理の行程を説明するフローチャートである。
【図１７】図１７に続くバッファリング処理の行程を説明するフローチャートである。
【図１８】図１７のフローチャートに対応して、ＮＧが検出されている場合にサブコードデータのバッファリングを終了させる処理に進む流れを説明するフローチャート。
【図１９】ＮＧが検出されている場合にサブコードデータのバッファリングを終了させ、有効性を検出する処理に進む流れを説明するフローチャート。
【図２０】再生処理時のキャッシュメモリのローサブコードエリアの内容を摸式的に説明する図である。
【図２１】キャッシュメモリのローサブコードエリアに格納されているローサブコードデータを説明する図である。
【図２２】８ビット／６ビット変換の概要を説明する図である。
【図２３】テキストデータ有効性検証処理の行程を説明するフローチャートである。
【図２４】図２２に続くテキストデータ有効性検証処理の行程を説明するフローチャートである。
【図２５】ヘッダタイプの一例を説明する図である。
【図２６】２番目のパックのヘッダの検証処理を説明するフローチャートである。
【図２７】サイズインフォメーションの検証処理を説明するフローチャートである。
【図２８】ローサブコードデータのデータ例を説明する図である。
【図２９】テキストデータのデータ例を説明する図である。
【図３０】本発明の変形例を説明する摸式図である。
【図３１】本発明の他の変形例を説明するフローチャートである。
【符号の説明】
１ ピックアップ、９ ＲＦアンプ、１０ システムコントローラ、１２ デコーダ、１３ インターフェース部、１４ サーボプロセッサ、２０ キャッシュメモリ、７０ 再生装置、８０ ホストコンピュータ、９０ ディスク
Claims (14)
- 主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、
前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、
前記管理情報検出手段によって検出された、前記管理情報を順次格納することができるようにされている管理情報記憶手段と、
前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、
前記ヘッダ情報検出手段によって検出される第一のヘッダ情報を起点とした順方向における所定の位置のデータ内容を検証する第一の検証手段と、
前記第一のヘッダ情報に続いて検出される第二のヘッダ情報を起点とした逆方向における所定の位置のデータ内容を検証する第二の検証手段と、
前記第一、第二の検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であるか否かを判断することができる判断手段と、
を備えたことを特徴とする再生装置。 - 前記管理情報記憶手段は、前記管理情報を格納することができる管理情報格納領域と、前記文字情報を格納することができる文字情報格納領域によって形成され、
前記文字情報格納領域には、前記管理情報格納領域に格納された前記管理情報のうち前記文字情報のみが格納されるようにしたことを特徴とする請求項１に記載の再生装置。 - 前記記録媒体上の前記管理情報はインターリーブされたデータ形態とされているとともに、前記管理情報検出手段はデインターリーブされる前の管理情報を検出するようにされていることを特徴とする請求項１に記載の再生装置。
- 主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、
前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、
前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、
前記管理情報記憶手段に順次格納される前記管理情報に含まれる文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、
前記ヘッダ情報検出手段によって検出される第一のヘッダ情報と、該第一のヘッダ情報に続いて検出される第二のヘッダ情報の間の所定の位置にあるデータ内容が、前記文字情報において規定されている所定のデータ内容に一致しているか否かを検証する検証手段と、
前記検証手段の検証結果に基づいて、前記第一、第二のヘッダ情報の間にある前記文字情報が有効であると判断することができる判断手段と、
を備えたことを特徴とする再生装置。 - 前記管理情報記憶手段は、前記管理情報を格納することができる管理情報格納領域と、前記文字情報を格納することができる文字情報格納領域によって形成され、
前記文字情報格納領域には、前記管理情報格納領域に格納された前記管理情報のうち前記文字情報のみが格納されるようにしたことを特徴とする請求項４に記載の再生装置。 - 前記記録媒体上の前記管理情報はインターリーブされたデータ形態とされているとともに、前記管理情報検出手段はデインターリーブされる前の管理情報を検出するようにされていることを特徴とする請求項４に記載の再生装置。
- 主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、
前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、
前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、
前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、
ヘッダ情報検出手段によって検出される前記ヘッダ情報の間にあるデータを一つの単位として複数単位のデータの内容を比較を行ない、比較したデータの内容が同等であった場合に、当該データが前記文字情報として有効であると判断することができる判断手段と、
を備えたことを特徴とする再生装置。 - 前記管理情報記憶手段は、前記管理情報を格納することができる管理情報格納領域と、前記文字情報を格納することができる文字情報格納領域によって形成され、
前記文字情報格納領域には、前記管理情報格納領域に格納される前記管理情報のうち前記文字情報のみが格納されるようにされていることを特徴とする請求項７に記載の再生装置。 - 前記記録媒体上の前記管理情報はインターリーブされたデータ形態とされているとともに、前記管理情報検出手段はデインターリーブされる前の管理情報を検出するようにされていることを特徴とする請求項７に記載の再生装置。
- 主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、
前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、
前記管理情報検出手段によって検出された前記管理情報を順次格納することができるようにされている管理情報記憶手段と、
前記管理情報記憶手段に順次格納される前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、
前記ヘッダ情報検出手段によって検出される所要のヘッダ情報に基づいて文字情報の検証処理を行なう検証手段と、
を備え、前記ヘッダ情報検出手段によって所要のヘッダ情報が２回検出された場合、前記再生手段による前記管理情報の読み出しを終了するとともに、前記管理情報検出手段による前記管理情報の検出を終了したうえで、前記検証手段は前記ヘッダ情報に基づいた前記文字情報の検証処理を行なうようにしたことを特徴とする再生装置。 - 前記管理情報記憶手段は、前記管理情報を格納することができる管理情報格納領域と、前記文字情報を格納することができる文字情報格納領域によって形成され、
前記文字情報格納領域には、前記管理情報格納領域に格納される前記管理情報のうち前記文字情報のみが格納されるようにされていることを特徴とする請求項１０に記載の再生装置。 - 前記記録媒体上の前記管理情報はインターリーブされたデータ形態とされているとともに、前記管理情報検出手段はデインターリーブされる前の管理情報を検出するようにされていることを特徴とする請求項１０に記載の再生装置。
- 主データの再生管理情報と文字情報を含む管理情報が記録された記録媒体から情報を読み出すことができる再生手段と、
前記再生手段によって、前記記録媒体から読み出される管理情報を検出することができる管理情報検出手段と、
前記管理情報検出手段によって検出された前記管理情報を所定の単位毎に順次格納することができるようにされている管理情報記憶手段と、
前記文字情報に対する誤り検出符号に基づいて、前記管理情報記憶手段に格納される前記管理情報に含まれる前記文字情報の誤り検出を行う誤り検出手段と、前記管理情報記憶手段に前記所定の単位とされる前記管理情報が格納された場合に、格納された前記管理情報に含まれる前記文字情報の所要のヘッダ情報を検出するヘッダ情報検出手段と、
前記誤り検出手段によって前記管理情報記憶手段に格納されている前記文字情報に誤りが検出された場合に、前記ヘッダ情報検出手段によって前記ヘッダ情報が検出されないまま、それまでに前記誤り検出手段によって検出された前記文字情報の誤り回数が前記管理情報の所定の単位数以上となったら、前記記録媒体に前記文字情報が記憶されていないと判別するようにした文字情報有無識別手段と、
を備えたことを特徴とする再生装置。 - 前記文字情報有無識別手段によって、前記記憶媒体に前記文字情報が記録されていないと判別した場合は、前記再生手段は前記記録媒体からの前記管理情報の読み出しを終了するようにしたことを特徴とする請求項１３に記載の再生装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP00794699A JP4092804B2 (ja) | 1998-08-06 | 1999-01-14 | 再生装置 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10-223388 | 1998-08-06 | ||
| JP22338898 | 1998-08-06 | ||
| JP00794699A JP4092804B2 (ja) | 1998-08-06 | 1999-01-14 | 再生装置 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2000113644A JP2000113644A (ja) | 2000-04-21 |
| JP2000113644A5 JP2000113644A5 (ja) | 2006-03-09 |
| JP4092804B2 true JP4092804B2 (ja) | 2008-05-28 |
Family
ID=26342359
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP00794699A Expired - Lifetime JP4092804B2 (ja) | 1998-08-06 | 1999-01-14 | 再生装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4092804B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3695581B2 (ja) * | 2001-08-08 | 2005-09-14 | ソニー株式会社 | 記録装置および記録方法、記録媒体、並びに、電子カメラ |
| JP3998611B2 (ja) | 2003-08-12 | 2007-10-31 | 富士通テン株式会社 | 記録媒体再生装置 |
| US7539092B2 (en) | 2004-05-17 | 2009-05-26 | Sanyo Electric Co., Ltd. | Optical disk playback apparatus and decoder determining text information |
-
1999
- 1999-01-14 JP JP00794699A patent/JP4092804B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000113644A (ja) | 2000-04-21 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4671611B2 (ja) | 記録媒体および情報再生方法 | |
| JP3899596B2 (ja) | 再生装置および再生方法 | |
| JP2002032922A (ja) | 光ディスク及び光ディスク装置 | |
| JP4016169B2 (ja) | ドライブ装置 | |
| JP3915228B2 (ja) | 再生方法および記録媒体 | |
| JP4092804B2 (ja) | 再生装置 | |
| KR100534051B1 (ko) | 재생방법 및 기록매체 | |
| JP3793093B2 (ja) | ディスクプレーヤ及びその記録内容情報表示方法 | |
| JP2000067511A (ja) | 再生装置 | |
| EP1703507A1 (en) | Recording medium, recording apparatus, reproducing apparatus, recording method, and reproducing method | |
| JPH1196689A (ja) | 記録媒体およびその再生装置 | |
| JPH04368667A (ja) | デジタルデータ処理装置 | |
| JPH11120707A (ja) | ディスク媒体、ディスク再生装置およびディスク再生方法 | |
| JP2786937B2 (ja) | デジタル信号記録媒体再生装置 | |
| JP3921858B2 (ja) | 再生装置 | |
| JPS63241779A (ja) | デイスク再生装置 | |
| JP3941771B2 (ja) | ディスク状記録媒体の記録方法 | |
| JP3941834B2 (ja) | ディスク状記録媒体の再生方法 | |
| KR100243211B1 (ko) | 오디오동기신호처리방법 | |
| JP2010134980A (ja) | データ記録再生装置及び記録再生方法 | |
| JPH10154389A (ja) | 情報記録媒体並びにこれを再生する再生装置、及び情報記録媒体の模擬装置 | |
| KR100396886B1 (ko) | 호스트 컴퓨터로 광기기 디스크 드라이브의 서브코드데이터 제공 방법 | |
| CN100524490C (zh) | 光盘再生装置和译码器 | |
| JPH02148217A (ja) | Ｃｄ−ｒｏｍディスク再生装置 | |
| JP2002050110A (ja) | ディスクドライブ装置、記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060112 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060112 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080207 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080212 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080225 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110314 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110314 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130314 Year of fee payment: 5 |