同じディスクをダンプする場合、CD-ROMサブチャネルは異なりますか？

Samsung SH-S223Lドライブを搭載したWindows 10 x64コンピューターで、CloneCD 5.3.3.0を使用して古いビデオゲームのバックアップコピーを作成しています。

それらの1つは、Hellfire for PC（Diablo 1拡張）です。

• ディスクにはCOMPACT disc DATA STORAGEロゴがあります
• シリアルナンバー： S0011770
• 工場SIDコード： IFPI 1218
• CDマスターSIDコード： IFPI L032
• ISO 9660 PVD作成日： 1997-11-18 16:30:00.00

redump.org CloneCDプロファイルの推奨事項を使用します。

[CloneCD ReadPrefs]
ReadSubData=1
RegenerateData=0
ReadSubAudio=1
AbortOnReadError=0
FastErrorSkip=0
ReadSpeedData=8
ReadSpeedAudio=8
IntelligentBadSectorScan=1
SectorSkip=1
NoErrorReport=0
FirstSessionOnly=0
AudioQuality=3

私の知る限り、ゲームには保護がありませんが、ディスクを2回ダンプすると、異なるサブチャネルファイル（.sub）になります。.ccdおよび.imgファイルは、同一であり、.sub異なる点は、I使用SHA1チェックサムとこれを確認するバイナリエディタ。ここに
2つの.subファイルダンプをアップロードしました。
私はこのディスクの2つのコピーを所有しており、動作は両方のディスクで同一であることを言及する必要があります。

また、他のいくつかのCD-ROMメディアをダンプしました。時々、サブチャネルがダンプ全体で一貫している場合にこの動作が発生することがあります。

この動作の説明は何ですか？

編集：

Lite-On iH124-14ドライブを使用して同じCD-ROMを再度ダンプしましたが、同じ動作（異なる.subファイル）が表示されます。
また、KProbe 2でメディアのエラーをチェックしたところ、次の結果が得られました。

編集：

ディスクの状態やドライブの精度の不足が、サブチャネルにエラー制御メカニズム（Qチャネルを除く）がないという事実に追加されたよう.subです。同じメディアを複数回ダンプするときに異なるファイルを取得する理由を説明しています。

また、Plextor PX-712Aドライブを入手.subし、Disc Image Creatorを使用してダンプ全体で一貫したファイルを取得することもできました。このソフトウェアは、0xD8指示の代わりに0xBE指示を利用してディスクを読み取るため、より正確な画像が得られます。この命令をサポートしているドライブはほとんどありません（主にPlextor）。

また、私は実際に、ダンプしているこのCD-ROMの2つの物理コピーを所有しています（同じシリアル番号、同じIFPIコード、同じレーザー彫刻情報）。Disc Image Creatorを使用して同じディスクを複数回ダンプすると、一貫した.subファイルが得られますが、最初のディスクをダンプしてから2番目のディスクをダンプすることはできません。
そのうちの1つにはいくつかのスクラッチがあり、C1 / C2エラーが多いため、メディアの状態に関連していると思います。

さまざまなCD形式が少し関与しており、公式仕様（オーディオCDの「レッドブック」、データCDの「イエローブック」）は自由に入手できません。ただし、Ecma-130などの利用可能な標準で詳細を確認できます。

オリジナルのオーディオCD（CD-DAとも呼ばれます）はビニールレコードでモデル化されました。つまり、連続したオーディオデータのスパイラルトラックも使用することを意味します（DVDは後に円形トラックを使用しました）。非常に複雑な方法でこのオーディオデータ内にインターリーブされるのは8つのサブチャネル（P〜W）で、そのうちQサブチャネルにはタイミング情報（分/秒/秒の端数）と現在のトラック番号が含まれます。当初の目的ではこれで十分でした。連続再生の場合、レンズはトラックに合わせてわずかに調整されました。シークするために、レンズは、正しいサブトラックが見つかるまでQサブチャネルをデコードしながら移動します。この位置は少し粗いですが、音楽を聴くには完全に適切です。

今日でも、多くのコンピューターCDドライブはレンズを完全に正確に配置してデコード回路を同期させることができないため、オーディオサンプルの読み取りは正確な位置から開始されます。これが、多くのCDリッピングプログラムに「パラノイア」モードがあり、重複読み取りを実行し、結果を比較してこの「ジッタ」を調整する理由です。オーディオストリームの一部として、サブチャネルもジッターの影響を受けやすいため、正確に配置できないCDドライブをリッピングすると、異なるサブチャネルファイルが取得されます。

データCD（CD-ROM）仕様がCD-DA仕様を拡張するために開発されたとき、データの正確なアドレス指定と読み取りの重要性が認識されたため、2352バイトのオーディオフレームは12同期バイトと4ヘッダーバイトに分割されました（残りの2336バイトをデータおよび追加レベルのエラー修正用に残します。このスキームを使用すると、Qチャネル情報のみに依存することなく、セクターを正確にアドレス指定できます。したがって、ジッター効果は適用されず、CD-ROMをダンプするときに常に同じデータが取得され、ダンプの追加の賢さは必要ありません。

詳細を編集します。

Ecma-130によると、データは段階的にスクランブルされます。24バイトがF1-Frameを構成し、これらのフレームの106バイトが106個のF2-Frameに分配され、8バイトのエラー訂正が追加されます。これらのフレームは、それぞれ追加のバイト（「制御バイト」）を取得してF3-Frameにします。余分なバイトにはサブチャネル情報が含まれています（各ビット位置に1つのサブチャネル）。98個のF3フレームのグループはセクションと呼ばれ、98個の関連制御バイトには2つの同期バイトと96バイトの実際のサブチャネルデータが含まれます。さらに、Qサブチャネルには、これらの96ビットで16ビットのCRCエラー修正があります。

この背後にある考え方は、スクラッチ、汚れなどが多くの連続したビットに影響を与えないようにディスクの表面にデータを配布することです。そのため、スクラッチがなければ大きすぎる。

結果として、CDドライブのハードウェアは、レンズを再配置した後、データストリームのどこにあるかを見つけるために、セクション全体を読み取る必要があります。さまざまなステージのスクランブル解除はハードウェアによって行われます。ハードウェアは、制御バイトストリームの2つの同期バイトに同期する必要があります。すべてのCDドライブモデルは、ハードウェアの実装方法に応じて、他のモデルと比較して同期に異なる時間を必要とします（2つの異なるドライブがあれば、それらを読み取ることでテストできます）。また、多くのモデルは同期するのに必ずしも正確に同じ時間を要するわけではないため、少し早くまたは遅く開始し、デスクランブルされたデータを常に同じバイトで出力することはできません。

したがって、リッピングプログラムがREAD CD（0xBE）コマンドを発行すると、転送長と開始アドレス（または、Qチャネル時間）が提供されます。ドライブはレンズの位置決め、フレームのデスクランブル、Qチャネルの抽出、時間の比較を行い、正しい時間を見つけると転送を開始します。この転送は、上で説明したように常に同じバイトで始まるとは限らないため、複数のREAD CDコマンドの結果が互いにずれる場合があります。そのため、リッパーとは異なるサブチャネルファイルが表示されます。

ハードウェアとレンズ調整時の状況に応じて、転送がいくつかのサンプルを早く開始するか、いくつかのサンプルを遅く開始するかは、ほぼランダムです。したがって、結果に表示される唯一のパターンは、シフトが転送長の倍数であることです。

一部のドライブモデルには、正確なハードウェアがあり、常に同時に転送を開始します。標準では、モードページ0x2a（「CD / DVD機能および機械的ステータスページ」）でビットが定義されていますが、実際の経験では、正確であると主張するドライブは実際にはそうではないことが示されています。（Linuxでは、パッケージから使用sg_modesしてsg3-utilesモードページを読み取ることができます。Windowsで使用するツールはわかりません）。

このウィキペディアの記事によると

フレームは33バイトで構成され、そのうち24バイトはオーディオまたはユーザーデータ、8バイトはエラー訂正（CIRC生成）、1バイトはサブコード用です。

これは、サブチャネルのエラー修正がないことを示しています。

私は別の場所でも別の質問を見つけました。オーディオCDについてですが、正しい問題に対処していると思います。

私が言えることは、同じCD-DA / CD-TEXTから読み取るときに、2つの同一のサブチャネル読み取り値（* .SUBファイル）を取得できなかったことだけです。CD-DA / CD-TEXT形式はすべてのサブチャネルでEDC / ECCを伝送しないため、データが修正されないため、RAWモードで読み取る場合は正常ですか？

そこの答え：

オーディオデータのみがリードソロモンコーディング（C1およびC2）の対象となります。サブコードチャネルデータ（チャネルP ... W）は、インターリーブまたはエラー保護の対象になりません。

一方でdirktは右であることができるあなたの質問に別の答えあなたが必要ないかもしれないという.subファイルが、答えは明示的にあなたの質問に対処していません。

この動作の説明は何ですか？

私の答え：.subサブチャネルにはエラー修正がないため、異なるファイルを取得します。読み取りエラーは、オーディオまたはユーザーデータの読み取り中に修正（または少なくとも検出）されますが、読み取りエラーはサブチャネルビットで発生した場合、そのまま渡すことができます。スクラッチやほこりによる特定のエラーは、ある読み取りセッション中に表示され、別の読み取りセッション中には表示されない.sub場合があります。したがって、ファイルが異なります。

コメントに対応するために展開された回答：

このディスクのコピーが2つあり、1つは良好な状態（目に見える傷はありません）で、動作は同じです。また、他の古いゲームCD-ROMが最悪の状態で、.sub複数のダンプ間で一貫したファイルを持っています。

（残念ながら確固たる証拠はありませんが）異なるCDが異なる品質で製造されている可能性があります。サブチャネルが重要でない場合でも、低品質のディスクはデータの不整合のみを検出するように設計された品質テストに合格する場合があります。または、単に確率的な問題である可能性があります。1つのディスクに、エラー修正で修正できる弱点（一貫性のない読み取り値を与えるビット）があります。別のサブチャネル領域にたまたまある。

このようなサブチャネルビットは、さまざまなチェックサムを提供するのに十分ですが、十分に分散されている場合、ユーザーデータ領域の数千の「未決定」ビットも必要に応じて静かに修正される可能性があるため、エラー修正アルゴリズムは一度に多くのそれら。

KProbe 2の結果に応じて回答が拡大しました。

私の知る限り、C1エラーは（ある程度は）許可されています（それらは静かに修正されているためです（詳細はこちら））。この修正は、エラー修正ビットが原因で機能します。前に言ったように、サブチャネルには一般にそのような冗長性はありません（dirktはQサブチャネルCRCエラー訂正について言及していますが、私の結論ではあまり変わりません）。さらに、そこでエラーが発生した場合、正しいサブチャネルデータが何かを事前に知らない限り、それを知る方法はありません。

そのため、合計1855のエラーがあります。テストを繰り返して（真剣にやってください！）、たとえば1790エラーが発生する可能性があります。または1892。ただし、修正された出力は、読むたびに同じです。

32データビットごとに1つのサブチャネルビットがある場合、おそらく、検出されないエラーで読み取られた約1855/32サブチャネルビットがあります。これは約58ビットです。ほとんどの場合、QサブチャネルCRCのおかげで、これらのエラーの少なくとも一部が検出される可能性があるためです。Qは8つのサブチャネルの1つであるため、他のサブチャネルには約50個のエラービットが残っていると推定されます。次回読むときは、これらのビットのいくつかがエラーなしで表示され、他の場所で新しいサブチャネルエラーがほとんど表示されないことがあります。したがって、別の.subファイルを取得します。それでも、これらのビットのどれが最初に正しく読み取られたのか、2番目に正しく読み取られたのかはわかりません。