同じディスクをダンプする場合、CD-ROMサブチャネルは異なりますか？
SamsungSH-S223Lドライブを搭載したWindows10x64コンピューターでCloneCD5.3.3.0を使用して古いビデオゲームのバックアップコピーを作成しています。
それらの1つはPC用のHellfire（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のみが異なります。これを確認するために、SHA1チェックサムと16進エディターを使用しました。
2つの.subファイルダンプをアップロードしました ここ 。
私はこのディスクのコピーを2つ所有しており、動作は両方のディスクで同じです。
また、他のいくつかのCD-ROMメディアをダンプしましたが、この動作が発生する場合があり、サブチャネルがダンプ間で一貫している場合があります。
この振る舞いの説明は何ですか？
編集：
Lite-On iH124-14ドライブを使用して同じCD-ROMを再度ダンプしましたが、同じ動作が見られます（異なる.subファイル）。
KProbe 2でメディアのエラーもチェックしたところ、次の結果が得られました。
編集：
サブチャネルにエラー制御メカニズム（Qチャネルを除く）がないという事実に加えて、ディスクの状態やドライブの精度の欠如が、同じメディアマルチプルをダンプしたときに異なる.subファイルを取得する理由を説明しているようです回数。
また、Plextor PX-712Aドライブを入手し、 Disc Image Creator を使用して、ダンプ間で一貫した.subファイルを取得できたことに言及する必要があります。このソフトウェアは、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-DA仕様を拡張するためにデータCD（CD-ROM）仕様が開発されたとき、データを正確にアドレス指定して読み取ることの重要性が認識されたため、2352バイトのオーディオフレームは12の同期バイトと4つのヘッダーバイトに分割されました（セクターアドレス）、残りの2336バイトをデータ用に残し、追加レベルのエラー修正を行います。このスキームを使用すると、Qチャネル情報のみに依存することなく、セクターを正確にアドレス指定できます。したがって、ジッター効果は適用されず、CD-ROMをダンプするときに常に同じデータを取得し、ダンプをさらに巧妙にする必要はありません。
Edit詳細：
Ecma-1 によると、データは段階的にスクランブルされます。24バイトがF1-Frameを構成し、これらのフレームのうち106個は106F2-Framesに分散され、8バイトのエラー訂正が追加されます。これらのフレームはそれぞれ追加のバイト（「制御バイト」）を取得してF3-Framesにします。追加のバイトには、サブチャネル情報が含まれます（ビット位置ごとに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つのディスクには、エラー訂正によって修正できる弱点（一貫性のない読み取り値を与えるビット）があります。別の人はたまたまそれをサブチャネルエリアに持っています。
そのようなサブチャネルビットの1つで、さまざまなチェックサムを提供できますが、ユーザーデータ領域の数千の「未決定」ビットでも、十分に分散されていれば、必要に応じてサイレントに修正される可能性があるため、エラー訂正アルゴリズムはあまりにも多くのことを処理しません。一度にそれらの多く。
KProbe2の結果に反応して回答が拡大しました。
私の知る限り、C1エラーはサイレントに修正されるため（ある程度まで）許可されます（ 詳細はこちら ）。この訂正は、エラー訂正ビットのために機能します。前に述べたように、サブチャネルには一般にそのような冗長性はありません（dirktはQサブチャネルのCRCエラー訂正について言及していますが、それはあまり変わりません私の結論）。さらに、そこでエラーが発生した場合、正しいサブチャネルデータが何であるかを事前に知らない限り、それを知る方法はありません。
つまり、あなたが知っている合計1855のエラーがありました。テストを繰り返して（真剣に、それをしてください！）、あなたは例えば1790エラー;または1892。それでも、修正された出力は、読むたびに同じです。
32データビットごとに1つのサブチャネルビットがある場合、検出されないエラーで読み取られたサブチャネルビットが約1855/32ある可能性があります。それは約58ビットです。 QサブチャネルCRCのおかげで、これらのエラーのいくつかは少なくとも検出される可能性があるためです。 Qは8つのサブチャネルの1つであるため、他のサブチャネルには約50の誤ったビットが残っていると推定されます。次に読むときに、エラーなしでこれらのビットのいくつかを取得し、他の場所でいくつかの新しいサブチャネルエラーを取得する可能性があります。したがって、別の.subファイルを取得します。それでも、これらのビットのどちらが最初または2回目に正しく読み取られたかはわかりません。