Sub-saluran CD-ROM berbeda saat membuang disk yang sama?

Saya membuat salinan cadangan gim video lama dengan CloneCD 5.3.3.0 di komputer Windows 10 x64 saya dengan drive Samsung SH-S223L.

Salah satunya adalah Hellfire untuk PC (ekspansi Diablo 1):

• Disk memiliki COMPACT disc DATA STORAGElogo
• Nomor seri: S0011770
• SID-Kode Pabrik: IFPI 1218
• CD-Master SID-Code: IFPI L032
• Tanggal pembuatan ISO 9660 PVD: 1997-11-18 16:30:00.00

Saya menggunakan rekomendasi profil 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

Sejauh yang saya tahu permainan tidak memiliki perlindungan tetapi ketika saya membuang disk dua kali saya berakhir dengan file subchannel yang berbeda ( .sub). The .ccddan .imgfile yang identik, hanya .subberbeda, saya checksum SHA1 digunakan dan hex editor untuk memverifikasi ini.
Saya mengunggah dua .subfile dump di sini .
Saya harus menyebutkan bahwa saya memiliki dua salinan disc ini dan perilakunya identik dengan kedua disc.

Saya juga membuang beberapa media CD-ROM lainnya, kadang-kadang saya mendapatkan perilaku ini terkadang subchannel konsisten di seluruh dump.

Apa penjelasan dari perilaku ini?

Edit:

Saya membuang CD-ROM yang sama lagi dengan drive Lite-On iH124-14 dan saya melihat perilaku yang sama ( .subfile yang berbeda ).
Saya juga memeriksa media untuk kesalahan dengan KProbe 2 dan saya mendapatkan hasil berikut:

Edit:

Tampaknya kondisi disk dan / atau kurangnya ketepatan drive ditambahkan ke fakta bahwa subchannel tidak memiliki mekanisme kontrol kesalahan (kecuali saluran Q) menjelaskan mengapa saya mendapatkan .subfile yang berbeda saat membuang media yang sama beberapa kali.

Saya harus menyebutkan bahwa saya juga mendapatkan drive Plextor PX-712A dan berhasil mendapatkan .subfile yang konsisten di seluruh dump dengan menggunakan Disc Image Creator . Perangkat lunak ini memanfaatkan 0xD8instruksi alih-alih 0xBEinstruksi untuk membaca disk, menghasilkan gambar yang lebih akurat. Hanya beberapa drive (kebanyakan Plextor) yang mendukung instruksi ini.

Saya juga sebenarnya memiliki dua salinan fisik dari CD-ROM ini yang saya dumping (nomor seri yang sama, kode IFPI yang sama dan informasi yang diukir dengan laser yang sama). Jika saya membuang disk yang sama beberapa kali dengan Disc Image Creator, saya mendapatkan .subfile yang konsisten tetapi tidak jika saya membuang disk pertama dan kemudian disk kedua.
Saya kira itu terkait dengan kondisi media karena salah satunya memiliki beberapa goresan dan lebih banyak kesalahan C1 / C2.

Berbagai format CD sedikit terlibat, dan spesifikasi resmi ("buku merah" untuk CD audio, "buku kuning" untuk CD data) tidak tersedia secara bebas. Tetapi Anda dapat menemukan beberapa detail dalam standar yang tersedia seperti Ecma-130.

CD audio asli (juga disebut CD-DA) dimodelkan pada piringan hitam, yang berarti juga digunakan adalah trek spiral data audio kontinu (DVD kemudian digunakan trek melingkar). Diselipkan dalam data audio ini dengan cara yang sangat kompleks adalah 8 sub-saluran (P ke W), di mana sub-saluran Q berisi informasi pengaturan waktu (secara harfiah dalam hitungan menit / detik / fraksi detik) dan nomor trek saat ini. Untuk tujuan awal, ini sudah cukup: Untuk bermain terus-menerus, lensa hanya disesuaikan sedikit untuk mengikuti trek. Untuk mencari, lensa akan bergerak sambil mendekodekan subchannel Q sampai trek yang tepat ditemukan. Posisi ini agak kasar, tetapi sepenuhnya memadai untuk mendengarkan musik.

Masih hari ini, banyak drive CD komputer tidak dapat sepenuhnya memposisikan lensa secara akurat dan menyinkronkan sirkuit decoding sehingga pembacaan sampel audio dimulai pada posisi yang tepat. Inilah sebabnya mengapa banyak program ripping CD memiliki mode "paranoia", di mana mereka melakukan tumpang tindih membaca dan membandingkan hasilnya dengan menyesuaikan untuk "jitter" ini. Sebagai bagian dari aliran audio, subchannel juga tunduk pada jitter, dan itulah sebabnya Anda mendapatkan file subchannel yang berbeda ketika Anda menyalin pada drive CD yang tidak dapat mengatur posisi dengan akurat.

Ketika spesifikasi data CD (CD-ROM) dikembangkan untuk memperluas spesifikasi CD-DA, pentingnya untuk secara akurat mengatasi dan membaca data dikenali, sehingga frame audio 2352 byte dibagi lagi menjadi 12 byte sinkronisasi dan 4 header byte (untuk alamat sektor), meninggalkan 2336 byte tersisa untuk data dan tingkat tambahan koreksi kesalahan. Dengan menggunakan skema ini, sektor dapat ditangani dengan tepat tanpa harus bergantung pada informasi saluran Q saja. Oleh karena itu efek jitter tidak berlaku, Anda selalu mendapatkan data yang sama ketika Anda membuang CD-ROM, dan tidak ada kepintaran tambahan dalam pembuangan.

Edit dengan lebih detail:

Menurut Ecma-130 , data diacak dalam beberapa tahap: 24 byte membentuk Bingkai-F1 , byte dari 106 frame ini didistribusikan ke 106 F2-Frame , yang mendapatkan 8 byte tambahan koreksi kesalahan. Frame-frame tersebut pada gilirannya masing-masing mendapatkan byte tambahan ("byte kontrol") untuk membuatnya menjadi F3-Frame . Byte tambahan berisi informasi subchannel (satu subchannel untuk setiap posisi bit). Sekelompok 98 F3-Frame disebut bagian , dan 98 byte kontrol yang terkait berisi dua byte sinkronisasi dan 96 byte data subchannel nyata. Subchannel Q juga memiliki 16 bit koreksi kesalahan CRC di 96 bit tersebut.

Gagasan di balik ini adalah untuk mendistribusikan data pada permukaan disk sedemikian rupa sehingga goresan, kotoran dll tidak mempengaruhi banyak bit kontinu, sehingga koreksi kesalahan dapat memulihkan data yang hilang selama goresan tidak terlalu besar.

Sebagai konsekuensinya, perangkat keras drive CD perlu membaca bagian yang lengkap setelah memposisikan ulang lensa untuk mengetahui di mana ia berada dalam aliran data. Penguraian berbagai tahapan dilakukan oleh perangkat keras, yang perlu menyinkronkan dirinya ke 2 byte sinkronisasi dalam aliran byte kontrol. Semua model drive CD memerlukan jumlah waktu yang berbeda untuk disinkronkan dibandingkan dengan model lain (Anda dapat mengujinya dengan membaca dari dua drive yang berbeda, jika Anda memilikinya), tergantung bagaimana perangkat keras diimplementasikan. Juga, banyak model tidak selalu mengambil waktu yang sama persis untuk menyinkronkan, sehingga mereka dapat memulai sedikit lebih awal atau terlambat, dan menampilkan data yang diuraikan tidak selalu pada byte yang sama.

Jadi ketika program ripping mengeluarkan perintah READ CD(0xBE), ia menyediakan panjang transfer dan alamat mulai (atau lebih tepatnya, waktu saluran-Q). Drive memposisikan lensa, menguraikan frame, mengekstrak saluran-Q, membandingkan waktu, dan ketika menemukan waktu yang tepat, ia mulai mentransfer. Transfer ini tidak selalu dimulai pada byte yang sama seperti yang dijelaskan di atas, sehingga hasil dari beberapa READ CDperintah dapat bergeser satu sama lain. Itu sebabnya Anda melihat file subchannel berbeda dari ripper Anda.

Bergantung pada perangkat keras dan keadaan saat lensa disesuaikan, ini lebih atau kurang acak jika transfer memulai beberapa sampel lebih awal atau beberapa sampel terlambat. Jadi satu-satunya pola yang akan Anda lihat dalam hasil adalah bahwa shift adalah kelipatan dari panjang transfer.

Beberapa model drive sebenarnya memiliki perangkat keras yang akurat yang akan selalu memulai transfer pada saat yang sama. Standar mendefinisikan sedikit dalam mode halaman 0x2a ("Kemampuan CD / DVD dan Halaman Status Mekanik") yang menunjukkan jika itu yang terjadi, tetapi pengalaman dunia nyata menunjukkan bahwa beberapa drive yang mengklaim tepat sebenarnya tidak. (Di Linux, Anda dapat menggunakan sg_modesdari sg3-utilespaket untuk membaca halaman mode, saya tidak tahu alat apa yang digunakan di Windows).

Menurut artikel Wikipedia ini

Sebuah frame terdiri dari 33 byte, dimana 24 byte adalah data audio atau pengguna, delapan byte adalah koreksi kesalahan (yang dihasilkan CIRC), dan satu byte untuk subkode.

Ini menunjukkan tidak ada koreksi kesalahan untuk subchannel.

Saya juga menemukan pertanyaan lain di tempat lain . Ini tentang CD audio tetapi saya pikir ini membahas masalah yang tepat:

Yang bisa saya katakan adalah bahwa saya tidak pernah berhasil mendapatkan dua pembacaan sub-saluran yang identik (file * .SUB) ketika membaca dari CD-DA / CD-TEXT yang sama. Apakah itu normal ketika membaca dalam mode RAW karena data tidak terkoreksi karena format CD-DA / CD-TEXT tidak membawa EDC / ECC di semua sub-saluran?

Jawabannya ada:

Hanya data audio yang mengalami pengkodean Reed-Solomon (C1 & C2). Data saluran subkode (saluran P ... W) tidak dikenai interleaving atau proteksi kesalahan.

Meskipun dirkt mungkin benar dalam jawaban lain untuk pertanyaan Anda bahwa Anda mungkin tidak memerlukan .subfile, jawabannya tidak secara eksplisit menjawab pertanyaan Anda:

Apa penjelasan dari perilaku ini?

Jawaban saya: Anda mendapatkan .subfile yang berbeda karena sub-saluran tidak memiliki koreksi kesalahan. Kesalahan baca diperbaiki (atau setidaknya terdeteksi) saat membaca audio atau data pengguna, tetapi kesalahan baca bisa lewat apa adanya ketika itu terjadi di bit subchannel. Kesalahan khusus karena goresan atau debu dapat muncul selama satu sesi membaca, tidak muncul selama yang lain dll - karenanya .subfile yang berbeda.

Jawaban diperluas untuk menanggapi komentar:

Saya memiliki dua salinan dari disk ini yang dalam kondisi sangat baik (tidak ada goresan yang terlihat) dan perilakunya masih sama. Saya juga memiliki CD-ROM game lama lainnya dalam kondisi terburuk yang memiliki .subfile konsisten di beberapa dump.

Saya curiga (sayangnya tanpa bukti keras) CD yang berbeda mungkin dibuat dengan kualitas yang berbeda. Dalam kasus ketika sub-saluran tidak menjadi masalah, disk dengan kualitas lebih rendah mungkin masih lulus tes kualitas yang dirancang untuk mendeteksi ketidakkonsistenan data saja. Atau mungkin hanya masalah probabilistik: satu disk memiliki titik lemah (sedikit yang memberikan pembacaan tidak konsisten) di mana koreksi kesalahan dapat memperbaikinya; lain kebetulan memilikinya di daerah subchannel.

Satu bit subchannel semacam itu sudah cukup untuk memberi Anda checksum yang berbeda, sementara ribuan bit "ragu-ragu" di area data pengguna dapat diperbaiki secara diam-diam ketika diperlukan, jika hanya mereka yang didistribusikan, sehingga algoritma koreksi kesalahan berhubungan dengan tidak-terlalu- banyak dari mereka sekaligus.

Jawaban diperluas sebagai reaksi terhadap hasil KProbe 2.

Sejauh yang saya tahu kesalahan C1 diperbolehkan (untuk jumlah tertentu) karena mereka diam-diam diperbaiki ( lebih lanjut di sini ). Koreksi ini berfungsi karena bit koreksi kesalahan. Seperti yang saya katakan sebelumnya, subchannels tidak memiliki redundansi secara umum ( dirkt menyebutkan Q-subchannel CRC error correction tetapi itu tidak banyak berubah dalam kesimpulan saya). Apalagi jika kesalahan terjadi di sana, tidak ada cara untuk mengetahuinya, kecuali Anda tahu sebelumnya apa data subchannel yang benar.

Jadi, Anda memiliki total 1.855 kesalahan yang Anda ketahui. Ulangi tes ini (serius, lakukan!) Dan Anda mungkin memiliki mis 1790 kesalahan; atau 1892. Namun output yang diperbaiki sama setiap kali Anda membaca.

Jika ada satu bit subchannel untuk setiap 32 bit data maka saya katakan Anda mungkin memiliki sekitar 1855/32 bit subchannel yang dibaca dengan kesalahan yang tidak terdeteksi. Itu sekitar 58 bit. Yah, hampir, karena berkat Q-subchannel CRC beberapa kesalahan ini dapat dideteksi setidaknya. Karena Q adalah salah satu dari delapan sub-saluran, saya memperkirakan Anda memiliki sekitar 50 bit yang salah di sub-saluran lainnya. Lain kali Anda membaca, Anda mungkin mendapatkan beberapa bit ini tanpa kesalahan, dan beberapa kesalahan subchannel baru di tempat lain. Jadi Anda akan mendapatkan .subfile yang berbeda . Dan Anda masih tidak akan tahu pasti mana bit yang dibaca dengan benar pertama kali atau kedua.