JP3921858B2 - 再生装置 - Google Patents
再生装置 Download PDFInfo
- Publication number
- JP3921858B2 JP3921858B2 JP00794499A JP794499A JP3921858B2 JP 3921858 B2 JP3921858 B2 JP 3921858B2 JP 00794499 A JP00794499 A JP 00794499A JP 794499 A JP794499 A JP 794499A JP 3921858 B2 JP3921858 B2 JP 3921858B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- text
- retry
- group
- reading
- 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 - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/10—Digital recording or reproducing
- G11B20/18—Error detection or correction; Testing, e.g. of drop-outs
- G11B20/1816—Testing
- G11B2020/183—Testing wherein at least one additional attempt is made to read or write the data when a first attempt is unsuccessful
Landscapes
- Signal Processing For Digital Recording And Reproducing (AREA)
Description
【発明の属する技術分野】
本発明は、例えばCD−TEXTなど、記録媒体上に1つのグループを形成するデータが繰り返し記録されている領域を有する記録媒体から、少なくともそのグループデータを再生することのできる再生装置に関するものである。
【0002】
【従来の技術】
いわゆる一般のオーディオ用のCD(COMPACT DISC)のフォーマットに準拠したうえで、そのサブコードデータとして所要の文字情報を記録したCD−TEXTが知られている。記録される文字情報としては、例えばディスクのタイトルやアーティスト名、楽曲名などの情報とされ、これらの情報を読み出して表示することによって、ユーザーはそのオーディオCDに収録されてる情報の内容などを文字で確認することが可能である。
なお、このCD−TEXTにおける文字情報は、例えばディスクのTOC領域(リードイン領域)などにおけるサブコードとして、内容的に1つのグループを形成するデータ(文字情報)が繰り返し記録されているものである。
【0003】
【発明が解決しようとする課題】
ところで、例えばCD−TEXTの場合は、文字情報についてはエラー訂正手段が付与されていない。このため文字情報の抽出はディスクのリーダビリティに大きく依存することになる。換言すれば、読出を行う領域に汚れや傷などがある場合は、文字情報を適正に抽出することが困難であった。
文字情報が適正に得られない場合は、ある程度の回数は読出のリトライを行うことになるのだが、リトライを何回か実行しても文字情報がうまく読み込めない場合もある。
また、リトライによって文字情報の読込に成功したとしても、その読込成功までに比較的長い時間がかかってしまうという場合もある。
【0004】
【課題を解決するための手段】
本発明はこのような問題点に鑑みて、1つのグループを形成するデータが繰り返し記録された領域を有する記録媒体から、少なくともそのグループを形成するデータ(例えばCD−TEXTにおける文字情報グループ)を読み出す動作に関して、リトライ動作を工夫することで、読込の成功率を大きく向上させること、及びリトライ動作を効率化させることを目的とする。
【0005】
このために再生装置として、記録媒体からグループを形成するデータを読み出すことができる読出手段と、読出手段によって読み出されたデータをバファリングする格納手段と、格納手段に1つのグループを形成する全データが適正にバファリングされることに応じて、当該グループとなるデータの出力処理を行う出力手段と、格納手段に1つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データがバファリングされている場合は読出手段における読出位置のアクセスを伴わない第1のリトライ動作を実行させ、一方、そのグループの先頭データがバファリングされていない場合は読出手段における読出位置のアクセスを伴なう第2のリトライ動作を実行させるリトライ制御手段とを備えるようにする。
つまり読み出すべきデータが繰り返し記録されたグループデータであることにより、リトライ動作としてアクセスが不要と判断した場合はそのまま読出を続行させてバッファリングのリトライ(第1のリトライ動作)を行い、一方、アクセスが必要と判断された場合、例えばディスク上の傷や汚れなどに起因する読込エラーの可能性がある場合などは、読出位置のアクセスを伴ったリトライ(第2のリトライ動作)を行なうというように、状況に応じてリトライ動作を切り換えることで、読込の成功率を向上させるとともに、リトライ動作の効率化を実現する。
【0006】
【発明の実施の形態】
以下、本発明の実施の形態として、CD−TEXTとしてのディスクに対応してデータ(オーディオデータ及びサブコードとしての文字情報)を再生できる再生装置を例にあげる。なお、サブコードとして記録される文字情報を「テキストデータ」ともいうこととする。
また説明上、本発明でいうアクセスを伴わない第1のリトライ動作を「バファリングリトライ」、アクセスを伴なう第2のリトライ動作を「アクセスリトライ」ということとする。
説明は次の順に行う。
1.再生装置の構成
2.TOC及びサブコード
3.テキストデータ
4.テキストデータの読出処理
【0007】
1.再生装置の構成
【0008】
図1は本例の再生装置70の要部のブロック図である。
CD方式のディスク90(例えばCD−TEXT)は、ターンテーブル7に積載され、再生動作時においてスピンドルモータ6によって一定線速度(CLV)もしくは一定角速度(CAV)で回転駆動される。そしてピックアップ1によってディスク90にエンボスピット形態で記録されているデータの読み出しが行なわれることになる。本例ではCLV方式として説明を続ける。
なおこの再生装置70はDVD(DIGITAL VERSATILE DISC)も再生可能であり、この場合相変化ピット形態で記録されているデータの読み出しが行なわれることになる。
【0009】
ピックアップ1内には、レーザ光源となるレーザダイオード4や、反射光を検出するためのフォトディテクタ5、レーザ光の出力端となる対物レンズ2、レーザ光を対物レンズ2を介してディスク記録面に照射し、またその反射光をフォトディテクタ5に導く光学系が形成される。
対物レンズ2は二軸機構3によってトラッキング方向及びフォーカス方向に移動可能に保持されている。
またピックアップ1全体はスレッド機構8によりディスク半径方向に移動可能とされている。
【0010】
ディスク90からの反射光情報はフォトディテクタ5によって検出され、受光光量に応じた電気信号とされてRFアンプ9に供給される。
RFアンプ9には、フォトディテクタ5としての複数の受光素子からの出力電流に対応して電流電圧変換回路、マトリクス演算/増幅回路等を備え、マトリクス演算処理により必要な信号を生成する。例えば再生データであるRF信号、サーボ制御のためのフォーカスエラー信号FE、トラッキングエラー信号TEなどを生成する。
RFアンプ9から出力される再生RF信号は2値化回路11へ、フォーカスエラー信号FE、トラッキングエラー信号TEはサーボプロセッサ14へ供給される。
【0011】
RFアンプ9で得られた再生RF信号は2値化回路11で2値化されることでいわゆるEFM信号(8−14変調信号;CDの場合)もしくはEFM+信号(8−16変調信号;DVDの場合)とされ、デコーダ12に供給される。
デコーダ12ではEFM復調、デインターリーブ、エラー訂正処理等を行ない、また必要に応じてCD−TEXTとしてのディスクにサブコードとして記録されているテキストデータのデコード、CD−ROMデコード、またはMPEGデコードなどを行なってディスク90から読み取られた情報の再生を行なう。
【0012】
なおデコーダ12は、EFM復調したオーディオデータをデータバッファとしてのキャッシュメモリ20に蓄積していき、このキャッシュメモリ20上でエラー訂正処理等を行う。そしてエラー訂正され適正な再生データとされた状態で、キャッシュメモリ20へのバファリングが完了される。
また、CD−TEXTとしてのディスク90に記録されるテキストデータは、同じく記録されているオーディオデータとは異なってインターリーブ処理は施されておらず、またエラー訂正コードは付加されていないため、テキストデータのデコード時には、デインターリーブを行わないで、サブコードをデコードしたデータをそのままキャッシュメモリ20にバファリングすることになる。そしてキャッシュメモリ20上でCRCチェックによるエラー検出を行うことになる。
なお後述するが、テキストデータはサブコードP〜Wのうち、R〜Wのデータとして記録されている。これに対してバファリング時にはP、Qも含めてキャッシュメモリ20に取り込んでいくことになり、その後キャッシュメモリ20に取り込まれたサブコードに対してエラー検出やテキストデータの抽出を行うものである。P、Qを含めてバファリングされるサブコードデータをロウデータ(RAW_DATA・・・ディスク90から読み出されインターリーブされていないデータ)と呼ぶこととする。
【0013】
再生装置70からの再生出力としては、キャッシュメモリ20にバファリングされているデータが読み出されてインターフェース部13から転送出力されることになる。
インターフェース部13は、外部のホストコンピュータ80と接続され、ホストコンピュータ80との間で再生データやリードコマンド等の通信を行う。
即ちキャッシュメモリ20に格納された再生データは、インターフェース部13を介してホストコンピュータ80に転送出力される。
またホストコンピュータ80からのリードコマンドその他の信号はインターフェース部13を介してシステムコントローラ10に供給される。
【0014】
サーボプロセッサ14は、RFアンプ9からのフォーカスエラー信号FE、トラッキングエラー信号TEや、デコーダ12もしくはシステムコントローラ10からのスピンドルエラー信号SPE等から、フォーカス、トラッキング、スレッド、スピンドルの各種サーボドライブ信号を生成しサーボ動作を実行させる。
即ちフォーカスエラー信号FE、トラッキングエラー信号TEに応じてフォーカスドライブ信号、トラッキングドライブ信号を生成し、二軸ドライバ16に供給する。二軸ドライバ16はピックアップ1における二軸機構3のフォーカスコイル、トラッキングコイルを駆動することになる。これによってピックアップ1、RFアンプ9、サーボプロセッサ14、二軸ドライバ16、二軸機構3によるトラッキングサーボループ及びフォーカスサーボループが形成される。
【0015】
またサーボプロセッサ14はスピンドルモータドライバ17に対して、スピンドルエラー信号SPEに応じて生成したスピンドルドライブ信号を供給する。スピンドルモータドライバ17はスピンドルドライブ信号に応じて例えば3相駆動信号をスピンドルモータ6に印加し、スピンドルモータ6のCLV回転を実行させる。またサーボプロセッサ14はシステムコントローラ10からのスピンドルキック/ブレーキ制御信号に応じてスピンドルドライブ信号を発生させ、スピンドルモータドライバ17によるスピンドルモータ6の起動、停止、加速、減速などの動作も実行させる。
【0016】
なお、スピンドルモータ6のCLV回転としての線速度については、システムコントローラ10が各種速度に設定できる。
例えばデコーダ12は、デコード処理に用いるためにEFM信号に同期した再生クロックを生成するが、この再生クロックから現在の回転速度情報を得ることができる。システムコントローラ10もしくはデコーダ12は、このような現在の回転速度情報と、基準速度情報を比較することで、CLVサーボのためのスピンドルエラー信号SPEを生成する。従って、システムコントローラ11は、基準速度情報としての値を切り換えれば、CLV回転としての線速度を変化させることができる。例えばある通常の線速度を基準として4倍速、8倍速などの線速度を実現できる。
これによりデータ転送レートの高速化が可能となる。
なお、もちろんCAV方式であっても回転速度の切換は可能である。
【0017】
サーボプロセッサ14は、例えばトラッキングエラー信号TEの低域成分として得られるスレッドエラー信号や、システムコントローラ10からのアクセス実行制御などに基づいてスレッドドライブ信号を生成し、スレッドドライバ15に供給する。スレッドドライバ15はスレッドドライブ信号に応じてスレッド機構8を駆動する。スレッド機構8には図示しないが、ピックアップ1を保持するメインシャフト、スレッドモータ、伝達ギア等による機構を有し、スレッドドライバ15がスレッドドライブ信号に応じてスレッドモータ8を駆動することで、ピックアップ1の所要のスライド移動が行なわれる。
【0018】
ピックアップ1におけるレーザダイオード4はレーザドライバ18によってレーザ発光駆動される。
システムコントローラ10はディスク90に対する再生動作を実行させる際に、レーザパワーの制御値をオートパワーコントロール回路19にセットし、オートパワーコントロール回路19はセットされたレーザパワーの値に応じてレーザ出力が行われるようにレーザドライバ18を制御する。
【0019】
以上のようなサーボ及びデコード、エンコードなどの各種動作はマイクロコンピュータによって形成されたシステムコントローラ10により制御される。
そしてシステムコントローラ10は、ホストコンピュータ80からのコマンドに応じて各種処理を実行する。
例えばホストコンピュータ80から、ディスク90に記録されている或るデータの転送を求めるリードコマンドが供給された場合は、まず指示されたアドレスを目的としてシーク動作制御を行う。即ちサーボプロセッサ14に指令を出し、シークコマンドにより指定されたアドレスをターゲットとするピックアップ1のアクセス動作を実行させる。
その後、その指示されたデータ区間のデータをホストコンピュータ80に転送するために必要な動作制御を行う。即ちディスク90からのデータ読出/デコード/バファリング等を行って、要求されたデータを転送する。
【0020】
ホストコンピュータ80からのリードコマンド、即ち転送要求としては、要求するデータ区間の最初のアドレスとなる要求スタートアドレスと、その最初のアドレスからの区間長として要求データ長(データレングス)となる。
例えば要求スタートアドレス=N、要求データ長=3という転送要求は、LBA「N」〜LBA「N+2」の3セクターのデータ転送要求を意味する。LBAとは論理ブロックアドレス(LOGICAL BLOCK ADDRESS )であり、ディスク90のデータセクターに対して与えられているアドレスである。
【0021】
2.TOC及びサブコード
次に、ディスク90(CD方式のディスク)においてリードインエリアに記録されるTOC、及びサブコードについて説明する。
ディスク90において記録されるデータの最小単位は1フレームとなる。98フレームでサブコードデータとしての1ブロック(1サブコードフレーム)が構成される。
【0022】
1フレームの構造は図2のようになる。
1フレームは588ビットで構成され、先頭24ビットが同期データと、これに続く3ビットによるマージンビットが設定され、続いて14ビットがサブコードデータエリアとされる。そして、その後に12シンボルのメインデータ及び4シンボルのパリティデータが配される。
【0023】
この構成のフレームが98フレームで1ブロックが構成され、98個のフレームから取り出されたサブコードデータが集められて図3(a)のような1ブロックのサブコードデータが形成される。
98フレームの先頭の第1、第2のフレーム(フレーム98n+1,フレーム98n+2)からのサブコードデータは同期パターンとされている。そして、第3フレームから第98フレーム(フレーム98n+3〜フレーム98n+98)までで、各96ビットのチャンネルデータ、即ちP,Q,R,S,T,U,V,Wのサブコードデータが形成される。
【0024】
このうち、アクセス等、再生に関わる各種制御には再生管理情報とされるPチャンネルとQチャンネルが用いられる。ただし、Pチャンネルはトラックとトラックの間のポーズ部分を示しているのみで、より細かい制御はQチャンネル(Q1 〜Q96)によって行なわれる。96ビットのQチャンネルデータは図3(b)のように構成される。
Rチャンネル〜Wチャンネルのデータは、テキストデータ群を形成するために設けられるが、これについては後述する。
【0025】
まずQ1 〜Q4 の4ビットはコントロールデータとされ、オーディオのチャンネル数、エンファシス、CD−ROMの識別などに用いられる。
即ち、4ビットのコントロールデータは次のように定義される。
『0***』・・・・2チャンネルオーディオ
『1***』・・・・4チャンネルオーディオ
『*0**』・・・・CD−DA(CDデジタルオーディオ;CD-TEXTを含む)
『*1**』・・・・CD−ROM
『**0*』・・・・デジタルコピー不可
『**1*』・・・・デジタルコピー可
『***0』・・・・プリエンファシスなし
『***1』・・・・プリエンファシスあり
【0026】
次にQ5 〜Q8 の4ビットはアドレスとされ、これはサブQデータのコントロールビットとされている。
このアドレス4ビットが『0001』である場合は、続くQ9 〜Q80のサブQデータはオーディオQデータであることを示し、また『0100』である場合は、続くQ9 〜Q80のサブQデータがビデオQデータであることを示している。
そしてQ9 〜Q80で72ビットのサブQデータとされ、残りのQ81〜Q96はCRCとされる。
【0027】
リードインエリアにおいては、そこに記録されているサブQデータが即ちTOC情報となる。
つまりリードインエリアから読み込まれたQチャンネルデータにおけるQ9 〜Q80の72ビットのサブQデータは、図4(a)のような情報を有するものである。サブQデータは各8ビットのデータを有している。
【0028】
まずトラックナンバが記録される。リードインエリアではトラックナンバは『00』に固定される。
続いてPOINT(ポイント)が記され、さらにトラック内の経過時間としてMIN(分)、SEC(秒)、FRAME(フレーム番号)が示される。
さらに、PMIN,PSEC,PFRAMEが記録されるが、このPMIN,PSEC,PFRAMEは、POINTの値によって、次に述べるように意味が決定されている。
【0029】
POINTの値が『01h』〜『99h』(hは16進表現であることを示す)のときは、その値はトラックナンバを意味し、この場合PMIN,PSEC,PFRAMEにおいては、そのトラックナンバのトラックのスタートポイント(絶対時間アドレス)が分(PMIN),秒(PSEC),フレーム番号(PFRAME)として記録されている。
【0030】
POINTの値が『A0h』のときは、PMINに最初のトラックのトラックナンバが記録される。また、PSECの値によってCD−DA,CD−I,CD−ROM(XA仕様)が区別される。
POINTの値が『A1h』のときは、PMINに最後のトラックのトラックナンバが記録される。
POINTの値が『A2h』のときは、PMIN,PSEC,PFRAMEにリードアウトエリアのスタートポイントが絶対時間アドレスとして示される。
【0031】
例えば6トラックが記録されたディスクの場合、このようなサブQデータによるTOCとしては図5のようにデータが記録されていることになる。
図5に示すようにトラックナンバTNOは全て『00h』である。
ブロックNO.とは上記のように98フレームによるブロックデータとして読み込まれた1単位のサブQデータのナンバを示している。
各TOCデータはそれぞれ3ブロックにわたって同一内容が書かれている。
図示するようにPOINTが『01h』〜『06h』の場合、PMIN,PSEC,PFRAMEとしてトラック#1〜トラック#6のスタートポイントが示されている。
【0032】
そしてPOINTが『A0h』の場合、PMINに最初のトラックナンバとして『01』が示される。またPSECの値によってディスクが識別され、このディスクがCD−DA(CD−TEXTを含む)の場合は、図示するようにPSEC=『00h』とされる。なお、CD−ROM(XA仕様)の場合は、PSEC=『20h』、CD−I(CDインタラクティブ)の場合は『10h』となる。
【0033】
そしてPOINTの値として『A1h』の位置にPMINに最後のトラックのトラックナンバが記録され、さらにPOINTの値として『A2h』の位置には、PMIN,PSEC,PFRAMEにそれぞれリードアウトエリアのスタートポイントが示される。
ブロックn+27以降は、ブロックn〜n+26の内容が再び繰り返して記録されている。
【0034】
ディスク90上で実際に音楽等のデータが記録されるトラック#1〜#n、及びリードアウトエリアにおいては、そこに記録されているサブQデータは図4(b)に示されている情報を有する。
まずトラックナンバが記録される。即ち各トラック#1〜#nでは『01h』〜『99h』のいづれかの値となる。またリードアウトエリアではトラックナンバは『AAh』とされる。
続いてインデックスとして各トラックをさらに細分化することができる情報が記録される。
【0035】
そして、トラック内の経過時間としてMIN(分)、SEC(秒)、FRAME(フレーム番号)が示される。
さらに、AMIN,ASEC,AFRAMEとして、絶対時間アドレスが分(AMIN),秒(ASEC),フレーム番号(AFRAME)として記録されている。
【0036】
このようにTOC及びサブコードが形成されているわけであるが、ディスク上のアドレス、即ちAMIN,ASEC,AFRAMEは、98フレーム単位で記録されることが理解される。
この98フレーム(1ブロック)は1サブコードフレームと呼ばれ、音声データとしての1秒間には75サブコードフレームが含まれることになる。つまり、アドレスとしての『AFRAME』がとりうる値は『0』〜『74』となる。なお、後述するフレームチェック処理でデータの連続性がチェックされるのは、このサブコードフレーム単位となる。
【0037】
3.テキストデータ
以降、図2及び図3に示す構造のサブコードに含まれるテキストデータについて説明を行うこととし、先ず、図6によりテキストデータの包括的な構造について説明する。
サブコード内に含まれるテキストデータのみを抽出して構造的に見た場合、テキストデータは図6に示すようなものとなる。テキストデータとしての最も大きなデータ単位は、図6(a)に示す『テキストグループ』とされる。図6(a)においては複数のテキストグループが示されているが、各テキストグループのデータは同一内容とされており、従って、サブコード内においては、同一データ内容の所定数の複数のテキストグループが繰り返し記録されていることになる。
【0038】
1つのテキストグループは、例えば最大2048パック(パックの定義については後述する)により形成するものとされるが、1テキストグループあたりのデータ読出に要する時間等を考慮して、1テキストグループを512パック以内により形成することが推奨されている。この際、1テキストグループあたりのデータ総量としては6500文字程度となる。
また1つのテキストグループは、図6(b)に示すようにブロック#0〜ブロック#nにより形成され、例えば最大8ブロック(0≦n≦7となる)であると規定されている。各ブロックは、同一の内容の情報をそれぞれ異なる言語により表記するためのテキストデータが格納されているものとされる。例えば、ブロック#0には、当該ディスクに対応する各種情報を英語により表記するためのテキストデータが格納されており、ブロック#1には、ブロック#0と内容的には同一の情報を日本語により表記するためのテキストデータが格納されているものとされる。
【0039】
この場合、1テキストグループは最大8ブロックにより形成可能であることから、テキストデータのフォーマットとしては最大8言語に対応することが可能とされる。
1つのブロックは、図6(c)に示すようにパック#0〜パック#nのデータ単位により形成される。ここでは、1ブロックは最大256パックで形成され情報量としては例えば36.864KByteとされている。なお、パック内のデータ構造等については、次の図7、図8及び図9により説明する。
【0040】
図7(a)は、図3に示した1サブコードフレームをデータ領域別に示すものであり、前述のように1サブコードフレームは98フレームにより形成される。98フレームの先頭の第1、第2フレーム(フレーム98n+1,フレーム98n+2)は、図3で説明したように同期パターンS0,S1の領域とされる。また、第3フレームから第98フレーム(フレーム98n+3〜フレーム98n+98)におけるPチャンネルはサブコードPのデータ領域とされ、QチャンネルはサブコードQのデータ領域とされて、前述したようにアクセス等の管理のためのデータが格納される。
【0041】
そして、第3フレームから第98フレームにおけるRチャンネル〜Wチャンネルの領域は図のようにパック0〜パック4とされる。各パックのデータサイズは固定長とされて、図7(b)に示すようにシンボル0〜23の24シンボルにより形成される。1シンボルは図7(c)に示すように、1フレームにおけるR,S,T,U,V,Wのチャンネルデータよりなる6ビットのデータ単位であり、この場合にはRチャンネルデータがMSB、WチャンネルがLSBとして定義される。
【0042】
図8は、上記図7(a)に示す構造の1サブコードフレームから、4つのパック(パック0〜パック4)によるデータ構造を抜き出して示している。
1パックは、図7で説明したように、24のシンボル(6ビット)により形成されることから、
6ビット×24/8=18バイト
で示されるように18バイトのデータサイズを有する。そして、図のように1パックは、先頭のID領域と続くテキストデータ領域により16バイトを占有し、残りの2バイトはCRC領域となる。
また、前述のように1サブコードフレームにおいては4つの連続したパックが設けられるが、これら4つのパックの集合により形成されるデータ単位はパケットとして定義されている。1パックは24シンボルにより形成されることから、1パケットは、
24(シンボル)×4(パック)=96(シンボル)
で示されるように96のシンボルにより形成されるものとみることができる。
【0043】
図9及び図10は、図8で示した1パック分のデータをシリアルに表現したものである。
図9(a)から分かるように、テキストデータのフォーマットにおいては、6ビットよりなるシンボルをシリアルに配列させたうえで、このデータ列を8ビット(1バイト)ごとに区切るようにしてデータを扱うように規定されている。
【0044】
そして図9(b)及び図10に示すように、パックの先頭からはヘッダ領域としてID1、ID2、ID3、ID4の4つのIDデータが設けられる。なお、ID1はPack_Type_Indicator、ID2はTrack_Number_Indicator、ID3はSequence_Number_Indicator、ID4はBlock_Number_and_Character_Position_Indicatorとされる。
【0045】
そして図9(a)のようにシリアルに配列されるデータを8ビット(1バイト)ごとに区切って扱うことにより、これら各IDはそれぞれ8ビット(1バイト)のデータ単位とされることになる。このため、図9(b)に示すように、ヘッダ領域(ID1〜ID4)以降の残りの12バイトがテキストデータ領域として確保され、残りの2バイトがCRC領域となる。
そして、上記12バイトのテキストデータ領域も、図10に示すパックの構造図に示すように、8ビットごとのtext1〜text12のデータ単位により扱われるものとされる。
【0046】
なお以上のように各パックの先頭はヘッダ領域(ID1〜ID4)とされるが、多数のパックにより構成されるテキストグループ(図6参照)における先頭のパックのヘッダは『スタートヘッダ』と位置づけられ、テキストグループとしての先頭であることを示す特定のパターンを有するものとなる。
そして、TOC領域(ディスクのリードイン領域)でのサブコードデータとしてテキストグループは連続して繰り返し記録されているものであるが、スタートヘッダから次のスタートヘッダの直前までのデータが、1つのテキストグループのデータ群であると識別できるようにされている。
【0047】
ところでCD方式のディスクとして、テキストデータがリードインエリアのサブコードとして記録されている方式がモード4、プログラムエリア(オーディオデータが格納されているエリア)のサブコードにテキストデータが記録されている方式がモード2とされている。
本例ではモード4を例に挙げて説明するが、本発明はモード2を適用している場合にも対応することが可能とされる。
なお参考までに、モード1はCD−G(グラフィック)、モード3はCD−MIDIとされる。
【0048】
以上のようにCD−TEXTでは、サブコードを利用してディスクのタイトル、曲名、アーティスト等の付加情報を記録するものである。
そして上記のようにこれらテキストデータはテキストグループと呼ばれる単位で繰り返し記録され、テキストグループは最大8つのブロック(最大8ヶ国語)、ブロックは最大256パックで構成されるので、許容される最大情報量は、36864バイトとなる。
1パック(24シンボル)×6(R〜W)×256(パック)×8(ブロック)=294912bits=36864Bytes
【0049】
また1サブコードフレームは98バイトから成り、同期パターンS0,S1を除いて96バイトのP〜Wのデータがある。従って、最大テキストデータ量は、サブコードP,Qを考慮して、
{36864×(8/6)}/96=512サブコードフレーム
つまり、1つのテキストグループは最大で512サブコードフレーム内にあることになる。
ディスク内周(リードイン領域)では、約9サブコードフレーム/トラックだとすると、およそ57トラックに渡って1つのテキストグループが記録されている事になる。
CDでは、リードイン領域がディスクの半径23mmから25mmの間に規定されていて、トラックピッチが1.6μmであることを考慮すると、(2500−2300)/1.6=1250トラックとなり、最大テキストデータがおよそ22回、リードイン領域に繰り返し記録されている。
【0050】
4.再生処理
以下、本例の再生装置におけるテキストデータの再生時の処理を説明していく。
上記したように、モード4においてはテキストデータはディスク90のリードイン領域のサブコードデータの一部に記録されている。したがって、テキストデータを扱う場合は、まずサブコードデータ(P〜W)から不要なデータ(P、Q)を排除してテキストデータ(R〜W)の抽出を行なうことになる。
この場合サブコードデータはデインターリーブ及びエラー訂正を行なわないロウデータとしてキャッシュメモリ20に順次格納(バファリング)していく。ロウデータとしては96バイト(96bit×8(P〜W))、すなわち1フレームに相当するデータ量が1回のバファリング単位とされる。そして、キャッシュメモリ20に格納されたサブコードデータの中から、所望するテキストデータの位置を識別する検出処理を行なう。この検出処理としてはテキストグループのスタートヘッダを検出するための処理とされる。
【0051】
バッファリング処理としては、サブコードデータにおいて図6(a)に示したテキストグループの先頭とされる位置(先頭パックのヘッダに相当する)を起点とし読み出しを行なうこと望ましいが、実際にはこれは困難な処理とされる。これはCDのリードイン領域にはアドレスが存在しないためである。
そこで、1回の読み込みではバファリング処理を行なうに際して必要なデータが得られない場合を想定して、キャッシュメモリ20には少なくとも2テキストグループ分のデータ量に相当するサブコードデータを格納するようにし、格納された2フレーム分のデータの中からスタートヘッダを検出するようにしている。
【0052】
なおバファリングが開始されてから1024サブコードフレーム分(256パック×8ブロック/4(1サブコードフレームに4バック))貯えられるまでバファリングを続ける仕様も考えられるが、常にこのようにバファリングすることは、もしテキストデータが長くなかった場合には無駄なバファリングが行われることになり、時間的にもロスとなる。そこで、バファリングしながら、不要なサブコードP,Qも含んだテキストグループの先頭を示すデータパターン(スタートヘッダー)の存在を監視していくこととしている。
2つ以上のスタートヘッダーが見つかれば、最初のスタートヘッダーから次のスタートヘッダーの直前までのサブコードデータの中に、所望するテキスト情報が存在するはずである。
【0053】
本例では、説明の都合上、サブコードのバファリングの最中に、スタートヘッダーを2つ見つけたらバファリングを止めて、テキスト情報の抜き出し及び、検証を行うものとする。
ただし、本例における最も大きな特徴は、適切なバファリングができなかった際のリトライ処理にあるので、バファリングの方法は以下説明する例に限定されず、どのようなバファリング方式でも適応できる。
【0054】
また本例の特徴であるリトライ動作としては、ピックアップ1のアクセスを伴うアクセスリトライと、ピックアップ1のアクセスは実行しないバファリングリトライがある。
アクセスリトライは、読出リトライ時に、ディスク盤面上のアクセス位置(目的位置)を故意に変えてからテキスト情報を読み出す動作となる。一方、バファリングリトライは、ピックアップ1による読出を継続させながら、バファリングをやり直すものである。
【0055】
上述したようにテキストグループは繰り返し記録されているため、あるテキストグループで読出が不調となっても、リトライ時にはピックアップ1の読出動作をそのまま継続させても、次のテキストグループの読出が適正に実行できる可能性がある。その様な場合はバファリングリトライが好適である。
【0056】
一方、ディスクの読み取り面に、傷や汚れが付着している場合や、記録層の物理的状態のむらや形成ばらつき、ディスクの歪み等の原因で、情報単位が繰り返し記録されている領域内で場所により、読み出す信号品質に差異があるときはアクセスリトライが好適である。つまり信号品質が悪化する領域での情報(テキストグループ)の読み出しを避けて、信号品質が良好な領域での情報(テキストグループ)の読み出しを行う方が、得られる情報の信頼性を考慮すると得策である事は自明である。これは、CD−TEXTのテキストデータのようにエラー訂正手段を持たず、信号品質(エラーレート)に強く依存する情報の再生に於いて有効となる。
【0057】
以下、図11〜図15によりテキストデータの読出処理を具体的に説明していく。
図11〜図14はは、システムコントローラ10によるテキストデータの読出処理を示すフローチャートである。
【0058】
テキストデータの読出(即ちテキストデータのバファリング処理の開始)を指示するコマンドはホストコンピュータ80から供給される。ここで、再生装置70が受信するコマンドとしては、例えば「A0コマンド」、「Packetコマンド」などのリードTOCコマンドを拡張してCD−TEXTデータを読み込む処理を開始するためのコマンドとされる。
このようなコマンドを受信すると、システムコントローラ10の処理は図11のステップF101からF102に進み、「OPコードチェック」、「CDBチェック」、「メディアチェック」などの各種チェック処理を行なう。
【0059】
「OPコードチェック」によって、受信したコマンドのOPコードが当該装置に対応しているものかの可否判別が行なわれ、「CDBチェック」によって、コマンド(12バイト)の内容が規格に準拠しているかの可否判別が行なわれる。これらの判別結果が「可」とされた場合、「メディアチェック」によって、再生装置70に装填されているディスク90が、例えばオーディオCDであるか否か(つまりCD−ROM等ではなく、CD−TEXTとしてテキストデータを有する可能性のあるディスクであるか否か)の判別が行なわれる。なお、CD−TEXTとは種別的にはオーディオCD(CD−DA)に含まれるものである。
ディスク90がオーディオCD(オーディオトラックが存在する)か否かは、上述したTOCデータにより判別できる。そして通常、TOCデータはディスク装填時に読み込んでいるため、即座に判別可能である。
【0060】
ここで、ディスク90がオーディオCDでないと判別された場合は、ステップF103からF104に進み、そのとき装填されているディスク90はテキストデータが存在しないディスクであるとしてコマンドに応じたテキスト読みだし処理を終了させる。例えばホストコンピュータ80にエラーを返すなどの処理を行ってコマンド実行を終了する。
【0061】
一方、オーディオCDであってテキストデータの存在の可能性がある場合は、ステップF105に進み、テキストデータのバファリングの準備を行う。
まずオーディオ再生モードを強制終了させる。
テキストデータの読出時には、デインターリーブやエラー訂正を行わないことで、オーディオトラックの再生時とは処理が異なることになるため、もしテキスト読出コマンドが供給された時点で、オーディオデータの再生を行っていたような場合は、その動作を強制終了させデインターリーブやエラー訂正処理をオフとすることが必要になる。またもちろん、オーディオデータはディスク90のプログラムエリアに記録されているが、テキストデータ(モード4の場合)はリードインエリアに移行して読出を行わなければならないことからも、オーディオ再生モードを終了させる必要が生じる。
なお、モード2の場合はテキストデータはオーディオトラックのサブコードとして記録されているが、インターリーブやエラー訂正のオフの必要から、オーディオ再生モードを終了させる必要があることは同様となる。
【0062】
続いてステップF106で、制御パラメータの初期化及びキャッシュメモリ20のデータの破棄を行う。
キャッシュデータの破棄は、この後テキストデータのバファリングを行うために当然必要になる処理である。
また制御パラメータとしては、変数M、変数CRCNGのリセットを行う。変数Mはスタートヘッダ検出回数を示す変数、変数CRCNGはCRCチェックでエラーとなった回数を示す変数である。
【0063】
次にステップF107でリードイン領域へのピックアップ1のアクセスを実行させる。
このステップF107でのアクセス処理は図12に詳しく示しているが、まずステップF151に示すように、ピックアップをプログラムエリアの先頭にアクセスさせる。
図15にディスク90を半径方向にみた場合のエリア構成を示しているが、ディスク90の最内周側はリードインエリア、最外周側はリードアウトエリアとされ、その間がプログラムエリアとされてオーディオトラックが記録されている。このプログラムエリアはCDフォーマットの絶対時間アドレス(分/秒/フレーム)として「00:02:00」の位置であるが、ステップF151ではまずこの位置にピックアップ1をアクセスさせる処理となる。
続いてステップF152で時変乱数αを発生させる。例えばαは0≦α≦63の範囲でのランダムな数とする。
【0064】
そしてステップF153で、ジャンプすべきトラック数を(240+α)トラックとし、内周側へトラックジャンプを実行させる。
つまり本例ではアドレス「00:02:00」のトラックから(240+α)トラック数減算したトラックを目的としてアクセスを実行させる。この場合、フォーカスサーボはオンのまま、トラッキングサーボをオフしてピックアップを目的のトラックに向けて移動させる。そしてトラックを横切った数をカウントしていき、これをジャンプすべきトラック数と逐次比較して、その値に到達したときにステップF154からF155に進み、アクセス終了、即ち各サーボをオンにして、ピックアップの移動にブレーキをかけて静定させる。
【0065】
CDのリードインエリアでは盤面上に物理アドレスが無いため、物理アドレスを頼って目的の場所にアクセスする事ができない。そこで上記のように一度アドレスの或る領域(プログラムエリアの先頭)にアクセスを行い、そこからディスクの内周に向かってトラックを横切る本数を監視しながらジャンプして、ピックアップをリードインエリアへと移動させる。この時、ジャンプする本数を時変乱数を利用して生成すれば、アクセスするディスク盤面上の位置が毎回異なる様になる。
このようにアクセス目的がランダムに設定されることは、後述するアクセスリトライを効果的に実行するためであり、その点については後述する。
【0066】
なお、ここで挙げたトラック数「240」や「α」のとりうる範囲は一例に過ぎず、再生装置の都合により決められる。
重要なのは時変乱数αを使って、アクセス先を毎回異なる様にした点である。つまり本例では図15に目的範囲APとして示したような範囲内で、ランダムな位置にアクセスが行われることになる。
ところで、ジャンプするトラック本数のカウントは必ずしも正確ではないので、乱数を用いなくとも、2もしくはそれ以上の種類のトラックジャンプ数を設定して交互に利用するような処理方式でもよい。
【0067】
図12に示したアクセス処理が終了すると、システムコントローラ10の処理は図11のステップF108に進み、データバファリングモードを設定する。ここでは、インターリーブされておらず、またエラー訂正コードを持たないテキストデータに対応させるため、デコーダ12等においてデインターリーブやエラー訂正処理をオフとする処理を行う。
【0068】
以上の処理を終えたら、図13のステップF109に進んで、サブコードデータのバファリングを開始する。
本例では、1つのサブコードフレーム単位でバファリングを行っていく。そして1つのサブコードフレーム分のデータがバファリングされる毎に、ステップF110からF111に進み、CRCチェックを行う。
上述したように1つのサブコードフレームには4つのパックが含まれるが、各パックについてのCRCチェックを行い、全てのパックのCRCチェックがOKであれば、バファリングしたロウデータ(サブコードデータ)の信頼性が確保されたとする。つまりCRCチェックOKとしてステップF112に進む。
一方、1つでもCRCエラーとなったパックが存在した場合は、バファリングしたサブコードの信頼性が確保できないとして、ステップF118に進んでリトライ判別処理を行い、必要なリトライ動作を実行することになる。
【0069】
4つのパックのCRCチェックがOKでステップF112に進んだ場合は、スタートヘッダの有無のチェックを行う。
即ちバファリングされた4つのパックの各ヘッダにおいて、テキストグループの先頭であることを示す特定のパターンであるスタートヘッダとされているものが存在するか否かを確認する。
4つのパックのうちにスタートヘッダが存在しない場合は、そのままステップF117に進んで、バファリング処理を継続し、同様の処理を繰り返す。
【0070】
4つのパックのうちにスタートヘッダが存在した場合、つまり4つのパックのうちのいずれかがテキストグループの先頭のパックであった場合は、ステップF113に進んでスタートヘッダ検出回数を示す変数Mをインクリメントし、ステップF114で変数M=2であるか否かを判別する。
変数M=2でなければステップF117に進んで、バファリング処理を継続する。
【0071】
もしバファリングの過程でCRCエラーとなることがないままスタートヘッダが2回確認された場合や、もしくはCRCエラーとなっても後述するリトライ処理を行うことで、データの信頼性が確保された状態でのバファリングデータの中でスタートヘッダが2回確認された場合は、ステップF114からF115に進み、サブコードのバファリングを終了する。
つまり、スタートヘッダが2回検出できたということは、バファリングされたデータとして最初のスタートヘッダから次のスタートヘッダまでの直前のデータとして、1つのテキストグループが確保されていることになるため、バファリング完了と判断するものである。
そしてステップF116で、バファリングされたローパスフィルタデータとしてのサブコードからP、Qデータの除去や必要なデコード処理などを行って、テキストグループを構成するテキストデータを抽出し、ホストコンピュータ80に転送する処理を行うことになる。そして転送処理を終えることで、コマンドに応じたテキスト再生動作を終了させる。
【0072】
ところで上記のようにステップF111でCRCエラーとなった場合は、ステップF118のリトライ判別処理に移ることになる。
このリトライ判別処理は図14に詳しく示される。
【0073】
まずステップF171で、CRCエラーとなったことに応じてCRCエラー回数を示す変数CRCNGをインクリメントする。
次にステップF172で、CRCエラーとる直前までにキャッシュメモリ20に確保されているロウデータ(サブコードデータ)の有効性を判断し、有効なロウデータとしてサブコードフレームが1024フレーム以上確保されているか否かを確認する。
テキストグループの最大長は、256パック×8ブロック=2048パックであり、1サブコードフレームに4パック存在するため、テキストグループの最大長=512サブコードフレームとなる。従って1024サブコードフレームとは、最大長のテキストグループの2つ分のデータ量に相当する。
この1024この有効なサブコードフレームが既に確保されている場合とは、そのバファリングデータ中には1つのテキストグループが確保されている場合であることを意味する。従って、その場合はステップF172から図13のステップF115に進み、バファリングを終了し、テキストデータの抽出/転送処理に移行してよい。
【0074】
また、有効なサブコードフレームが1024個未満であった場合でも、ステップF173でM=2、つまりスタートヘッダが2回確認されていることが検出できれば、その場合も、1つのテキストグループ分のデータが確保されていることになるため、図13のステップF115に進み、バファリングを終了し、テキストデータの抽出/転送処理に移行してよい。
【0075】
このステップF172、F173の処理は例えば何らかの事情で図13のステップF112でのスタートヘッダ検出が良好にできなかった場合などにおいてステップF118のリトライ判別処理に進んだ場合などに、実際は不要となるリトライ処理が実行されてしまうことを防止するためのものとなる。
【0076】
1つのテキストグループがキャッシュメモリ20内に確保できておらず、実際にリトライ処理が必要になった場合は、まずステップF174で変数M=1であるか否かを判断する。
変数=1であって、すでに1回スタートヘッダが検出されている場合は、ステップF178に進んで、制御パラメータの初期化、つまり、変数M、変数CRCNGのリセットを行うとともに、キャッシュメモリ20のデータの破棄を行う。そしてステップF179でバファリングリトライ開始として図11のステップF108に進み、上述してきたバファリング動作を行う。
【0077】
このバファリングリトライとは、単にキャッシュメモリ20内のデータを破棄し、一方ピックアップ1の位置はそのままで、バファリングのリトライを行うものである。
【0078】
ピックアップ1のアクセスを伴わないでリトライを行う理由は次の通りである。
まず、既にスタートヘッダが1回検出されていることから、現在トレースしているピックアップ位置でのテキストデータ再生に関するディスク90のリーダビリティはさほど悪くないと判断でき、従って、ピックアップ1はそのまま現状の位置からトレースを行っていれば、テキストグループの抽出(2つのスタートヘッダ検出)が完了する可能性が高いためである。
また、このようにアクセスを行わないでもリトライを成功に導く可能性が高い場合には、アクセスを実行することで無駄な時間を浪費することや、場合によってはリーダビリティの良くない場所にアクセスしてしまい、再びCRCエラーを招く可能性が生じることを避けるという意味もある。
【0079】
一方、ステップF174でM=1ではないと判断された場合は、ステップF175に進んで、バファリングされている有効なサブコードフレームが、ある設定値N(N≧1)以上であるか否かを判別する。
設定値Nとは、再生装置70の都合で決められるパラメータであり、これはディスク90がテキストデータを記録したディスクであるか否かを判別するためのしきい値となる。
【0080】
有効なサブコードフレーム数が設定値Nを越えていなかった場合は、ステップF176で、変数CRCNGが64を越えているか否かを判断する。
そして変数CRCNGが64を越えていなければ、図13のステップF117に戻って、その時点ではリトライは行わずにバファリング処理を継続する。
【0081】
もし、ある時点でステップF175で有効なサブコードフレーム数が設定値Nを越えておらず、しかも、ステップF176で、変数CRCNGが64を越えていると判断された場合は、ステップF181で、現在のディスク90にはテキストデータは存在しないと判断し、図11のステップF104に進んで、ホストコンピュータ80にエラー(テキスト無し)を返して処理を終了する。
【0082】
これはディスク90がテキストデータの記録されていないオーディオCDであった場合の処理となる。
そしてテキスト再生時には上記のようにデインターリーブがオフとされていることから、ディスク90としてテキストデータのないオーディオCDが装填されていた場合は、全てのサブコードフレームのバファリング時にCRCエラーとなる。従ってステップF176から図13のF117に戻ってサブコードフレーム単位でバファリングが行われていくと、64個目のサブコードフレームのバファリングにおいてステップF176で変数CRCNGが64となる。
つまりバファリングを開始してからわずか64サブコードフレームのバファリングを行った時点で、そのディスク90にはテキストデータが存在しないことを確認でき、換言すれば、ディスク90にテキストデータが存在しない場合には、バファリング開始後、非常に迅速にテキストデータが存在しないとして処理を終了させることができる。従って無駄な動作がいつまでも行われることはない。
【0083】
なお、CRCNGが「64」以上となったことでテキストデータ無しと判断するのは、テキストグループを構成する1つのブロックが最大256パックからなることによる(256パック=64サブコードフレーム)。
【0084】
ディスク90がテキストデータが含まれるCD−TEXTであった場合には、有効サブコードフレーム数がN未満のまま変数CRCNGが64に達することはまずない。
これも換言すれば、CD−TEXTの場合は、変数CRCNGが64に達するよりも早く、ステップF175で有効サブコードフレーム数がN以上となることを意味する。
【0085】
この場合は、ステップF177で変数CRCNGがある許容数未満であれば、リトライ動作に移行しないまま、図13のF117に戻ってサブコードフレーム単位でバファリングを継続する。
ある時点で、ステップF177で変数CRCNGがある許容数以上となったことが検出された場合は、ステップF180に進んでアクセスリトライを行うことになる。
【0086】
即ち図11のステップF106に進んで、制御パラメータの初期化、つまり、変数M、変数CRCNGのリセットを行うとともに、キャッシュメモリ20のデータの破棄を行う。そしてステップF107で、上記図12の処理としてのアクセスを実行する。つまり上述した時変乱数を利用することで、最初にアクセスした場所と異なる場所にアクセスする。そしてステップF108以降、バファリングを再開する。
【0087】
このアクセスリトライとは、キャッシュメモリ20内のデータを破棄するとともに、ピックアップ1の位置も変更させるものである。
このアクセスリトライを行う理由は次のようになる。
変数CRCNGの数が許容値を超えるということは、少なくとも現在ピックアップ1でトレースしている位置は、テキストデータ再生におけるリーダビリティが悪いと判断できるものである。この場合、そのままの位置でピックアップ1によるトレースを続行しても、適正なバファリングができる確率が低い。場合によってはいつまでたっても有効なサブコードデータが確保できない可能性もある。そこでその様な場合は、アクセスリトライによりピックアップ1のトレース位置を変更させて、リトライを行うことが好適となる。
例えばリトライ前のトレース位置が、傷や汚れの影響でリーダビリティが悪化していたような場合は、トレース位置を変更させることで、適正な読出が可能となる確率が大幅に向上する。
【0088】
以上のように本例では、CRCエラーの場合に、状況に応じてバファリングリトライとアクセスリトライを使い分けるようにしており、これによってCRCエラーとなった原因等に応じて最も適切なリトライが可能となる。
即ちリトライ動作としてアクセスが不要と判断できる場合、つまりリーダビリティがさほど悪くなく、そのまま読出を続行させることが有利であると判断された場合はバファリングリトライを行うようにし、一方、読出位置(トレース位置)を変えた方が良いと判断される場合はアクセスリトライを行なうようにしているため、状況に応じて最も適切なリトライ動作が実行されることになり、データ読込の成功率を格段に向上させることができるとともに、リトライ動作が効率化され、短時間で読み込み成功に導くことができるという効果がある。
【0089】
ところで本出願人は、以上のような本例の処理の効果を確認する実験を行った。
まず市販されているCD−TEXT(テキストデータ量1660バイト)を、CD−Rにコピーし、かつそれをリーダビリティの悪いディスクとして作成した。C1エラーレートは最大50/secとなるディスクであった。そしてそのディスクを用いて、ファームウエアA、B、Cの各場合でテキストデータ読出の実験を行った。
【0090】
ファームウエアAは、変数CRCNG数が許容値を越えた場合に従来方式のリトライを行うものである。つまりリトライ時にはピックアップアクセスを伴うが、本例のようにアクセス位置をランダムに変更することは行わないもの(つまり図12のステップF152の処理がなく、ステップF153でα=0となる処理)である。
ファームウエアBは、本例でいうアクセスリトライを行うのみで、バファリングリトライは実行しないものである。
ファームウエアCは本例の処理を行うものである。
この実験の結果は図16のようになり、つまり本例(ファームウエアC)による処理では、リーダビリティの悪いディスクであっても安定にデータ読出ができることが確認された。
【0091】
なお、本発明は、テキストデータがディスク90のプログラムエリアに記録されている「モード2」に対しても適用することができる。
またテキストデータがプログラムエリアに記録されるモード2の場合は、アドレスにたよってアクセスを行うことができるため、アクセスリトライの際に、毎回異なる目標アドレスを設定してアクセスを行うことが可能となる。
【0092】
また本発明はCD−TEXT以外のCD方式のディスクや、DVDなど、他の種のディスクであっても、同じ内容が繰り返し記録されているデータの読出処理に広く適用できるものである。
繰り返し記録されるデータの例としては、具体的には、CDのTOCデータ、DVDのリードインデータ、書換可能なDVDのディフェクト管理情報などがある。
もちろん繰り返しデータの記録エリアとしてのアドレスの有無に限らず適用できる。
【0093】
【発明の効果】
以上、説明したように本発明では、CD−TEXTにおけるテキストデータなどの、1つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データ(例えば上述したスタートヘッダ)がバファリングされている場合は、読出位置のアクセスを伴わない第1のリトライ動作(バファリングリトライ)を実行させ、一方、そのグループの先頭データがバファリングされていない場合は読出位置のアクセスを伴なう第2のリトライ動作(アクセスリトライ)を実行させるようにしている。
即ちリトライ動作としてアクセスが不要と判断できる場合、つまりデータが繰り返し記録されているためそのまま読出を続行させることが有利であると判断された場合は第1のリトライ動作を行うようにし、一方、読出位置を変えた方が良いと判断される場合は第2のリトライ動作を行なうようにしているため、状況に応じて最も適切なリトライ動作が実行されることになり、データ読込の成功率を格段に向上させることができるとともに、リトライ動作が効率化され、短時間で読み込み成功に導くことができるという効果がある。
【0094】
またリトライの実行判断は、格納手段へバッファリングされたデータについてエラーが検出されたか否かにより行うことで、適切にリトライ動作に移行できるという効果がある。
また、第2のリトライ動作が実行される場合に、読出位置のアクセスは、そのアクセス目的位置が所定範囲内でランダムに選択されることで、第2のリトライ動作のたびに、読出位置が変わることになる。これは例えば記録媒体上の傷や汚れなどにより読み込みエラーとなったような場合に、その部位を避けることができることになり、従ってリトライ時の読込成功率を大きく向上させる一因となる。なお、読出位置が変わっても、グループデータは繰り返し記録されているものであるため、必要なデータの読出には支障はない。
【0095】
また、バッファリングされたデータについて所定数以上のエラーが検出された場合には、読み出すべきグループデータが存在しないとしてリトライ動作を実行させずに動作を終了させることで、そもそも読出が不可能な場合にリトライ動作を繰り返してしまうというような無駄な動作を避けることができるという効果がある。
【図面の簡単な説明】
【図1】本発明の実施の形態の再生装置のブロック図である。
【図2】ディスク(CD)のフレーム構造の説明図である。
【図3】ディスク(CD)のサブコーディングの説明図である。
【図4】ディスク(CD)のサブQデータの説明図である。
【図5】ディスク(CD)のTOCデータの説明図である。
【図6】テキストデータの構造を包括的に示す説明図である。
【図7】サブコードフレームとテキストデータとの構造的な関係を示す説明図である。
【図8】テキストデータとしてパケットの構造を示す説明図である。
【図9】テキストデータの構造として、シンボル単位のデータからパックを形成する過程を説明するための説明図である。
【図10】パックの構造を示す説明図である。
【図11】実施の形態のテキストデータ読出時の処理のフローチャートである。
【図12】実施の形態のテキストデータ読出時におけるアクセス処理のフローチャートである。
【図13】実施の形態のテキストデータ読出時の処理のフローチャートである。
【図14】実施の形態のテキストデータ読出時におけるリトライ判別処理のフローチャートである。
【図15】実施の形態のアクセス動作の説明図である。
【図16】実施の形態の効果を確認する実験結果の説明図である。
【符号の説明】
1 ピックアップ、9 RFアンプ、10 システムコントローラ、12 デコーダ、13 インターフェース部、14 サーボプロセッサ、20 キャッシュメモリ、70 再生装置、80 ホストコンピュータ、90 ディスク
Claims (4)
- 1つのグループを形成するデータが繰り返し記録された領域を有する記録媒体から、少なくとも前記グループを形成するデータを読み出すことができる読出手段と、
前記読出手段によって読み出されたデータをバファリングする格納手段と、
前記格納手段に1つのグループを形成する全データが適正にバファリングされることに応じて、当該グループとなるデータの出力処理を行う出力手段と、
前記格納手段に1つのグループを形成する全データが適正にバファリングできなかった場合において、そのグループの先頭データがバファリングされている場合は前記読出手段における読出位置のアクセスを伴わない第1のリトライ動作を実行させ、一方、そのグループの先頭データがバファリングされていない場合は前記読出手段における読出位置のアクセスを伴なう第2のリトライ動作を実行させるようにするリトライ制御手段と、
を備えたことを特徴とする再生装置。 - 前記リトライ制御手段は、前記格納手段へバッファリングされたデータについてエラーが検出された場合に、1つのグループを形成する全データが適正にバファリングできなかったとして、前記第1のリトライ動作もしくは前記第2のリトライ動作の実行制御を行うことを特徴とする請求項1に記載の再生装置。
- 前記第2のリトライ動作において、前記読出手段の読出位置のアクセスは、そのアクセス目的位置が所定範囲内でランダムに選択されることを特徴とする請求項1に記載の再生装置。
- 前記リトライ制御手段は、前記格納手段へバッファリングされたデータについて所定数以上のエラーが検出された場合に、リトライ動作を実行させずに動作を終了させることを特徴とする請求項1に記載の再生装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP00794499A JP3921858B2 (ja) | 1999-01-14 | 1999-01-14 | 再生装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP00794499A JP3921858B2 (ja) | 1999-01-14 | 1999-01-14 | 再生装置 |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2000207851A JP2000207851A (ja) | 2000-07-28 |
JP2000207851A5 JP2000207851A5 (ja) | 2006-02-23 |
JP3921858B2 true JP3921858B2 (ja) | 2007-05-30 |
Family
ID=11679616
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP00794499A Expired - Fee Related JP3921858B2 (ja) | 1999-01-14 | 1999-01-14 | 再生装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3921858B2 (ja) |
-
1999
- 1999-01-14 JP JP00794499A patent/JP3921858B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2000207851A (ja) | 2000-07-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4374698B2 (ja) | 記録装置 | |
JP3901748B2 (ja) | ディスク状記録媒体及びその記録装置並びに再生装置 | |
JP4277452B2 (ja) | 記録装置、再生装置 | |
JP4806839B2 (ja) | 記録装置、記録方法 | |
US6714509B2 (en) | Disk recording medium and disk drive apparatus | |
KR100743576B1 (ko) | 디스크드라이브장치, 디스크포맷방법 | |
EP1128366A2 (en) | Recording medium, recording apparatus, and reading apparatus | |
JP4016169B2 (ja) | ドライブ装置 | |
JP3994539B2 (ja) | 再生装置 | |
JP4889853B2 (ja) | 記録装置及び記録媒体 | |
JP3921858B2 (ja) | 再生装置 | |
JP2005536002A (ja) | 高密度光ディスク、高密度光ディスクへのアドレスまたは/及びサーボ情報記録方法、高密度光ディスクに記録されたデータの再生方法 | |
JP3941771B2 (ja) | ディスク状記録媒体の記録方法 | |
JP3941834B2 (ja) | ディスク状記録媒体の再生方法 | |
JP3953987B2 (ja) | 光ディスク再生方法、光ディスク再生装置 | |
JP3955981B2 (ja) | 光ディスク再生方法、光ディスク再生装置 | |
JP4935946B2 (ja) | 記録装置、記録方法 | |
JP2002050110A (ja) | ディスクドライブ装置、記録媒体 | |
JP2001266493A (ja) | 識別方法、記録再生装置及び記録媒体 | |
JP2001028170A (ja) | ディスク記録媒体、及びディスクドライブ装置 | |
JP2001210009A (ja) | 再生装置、記録装置およびダビング装置 | |
JP2009272036A (ja) | 記録装置、記録方法及び記録媒体 | |
JP2005078673A (ja) | 再生装置及びフォーマット判定方法 | |
JP2001236770A (ja) | ディスク記録媒体、記録装置、再生装置 | |
JP2002216352A (ja) | ディスクドライブ装置、データ記録方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060106 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060106 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070104 |
|
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: 20070130 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070212 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100302 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110302 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120302 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120302 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130302 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140302 Year of fee payment: 7 |
|
LAPS | Cancellation because of no payment of annual fees |