Підканал CD-ROM відрізняється при завантаженні одного і того ж диска?

Я роблю резервні копії старих відеоігор із CloneCD 5.3.3.0 на комп’ютері Windows 10 x64 з приводом Samsung SH-S223L.

Один з них - Hellfire для ПК (розширення Diablo 1):

• На диску є COMPACT disc DATA STORAGEлоготип
• Серійний номер: S0011770
• Заводський SID-код: IFPI 1218
• CD-Master SID-код: IFPI L032
• Дата створення 96D 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

Наскільки я знаю, гра не захищає, але коли я скидаю диск двічі, я стикаюся з різними файлами підканалів ( .sub). .ccdІ .imgфайли ідентичні, тільки .subвідрізняється, я використовував SHA1 контрольні суми і шістнадцятковий редактор , щоб перевірити це.
Я завантажив два .subвідвалів файлу тут .
Я мушу зазначити, що у мене є дві копії цього диска, і поведінка однакова з обома дисками.

Я також скидав кілька інших носіїв компакт-дисків, іноді я отримую таку поведінку, інколи підканал узгоджується з дампами.

Яке пояснення такої поведінки?

Редагувати:

Я знову скинув той самий компакт-диск із приводом Lite-On iH124-14 і бачу однакову поведінку (різні .subфайли).
Я також перевірив носій на наявність помилок з KProbe 2 і отримую такий результат:

Редагувати:

Здається, що стан диска та / або недостатня точність накопичувача додали до того, що підканал не має механізму управління помилками (крім Q-каналу) пояснює, чому я отримую різні .subфайли при скиданні одного і того ж носія кілька разів.

Треба зазначити, що мені також вдалося отримати диск Plextor PX-712A і мені вдалося отримати послідовні .subфайли через звалища за допомогою Disc Image Creator . Це програмне забезпечення використовує 0xD8інструкції замість 0xBEінструкцій для читання диска, в результаті чого з’являються більш точні зображення. Лише кілька дисків (в основному Plextor) підтримують цю інструкцію.

Крім того, у мене фактично є дві фізичні копії цього компакт-диска, який я скидаю (той самий серійний номер, ті ж коди IFPI та така ж гравірована лазерна інформація). Якщо я скидаю один і той же диск кілька разів разом з Disc Image Creator, я отримую .subфайли, які відповідають послідовності, але не, якщо я скидаю перший диск, а потім другий диск
Я думаю, що це пов'язано з умовами медіа, оскільки одна з них має кілька подряпин та більше помилок C1 / C2.

Різні формати компакт-дисків дещо задіяні, і офіційні характеристики ("червона книга" для аудіо компакт-диска, "жовта книга" для компакт-дисків з даними) є у вільному доступі. Але ви можете знайти деякі деталі в доступних стандартах, таких як Ecma-130.

Оригінальний аудіо компакт-диск (також його називали CD-DA) був змодельований на вініловій платівці, а значить, він також використовує спіральну доріжку безперервних аудіоданих (DVD згодом використовували кругові доріжки). Дуже складними способами переплетені в межах цих аудіоданих є 8 підканалів (P - W), з яких підканал Q містить інформацію про час (буквально в хвилинах / секундах / частках секунд) та поточний номер треку. Для початкової мети цього було достатньо: для безперервної гри об’єктив просто трохи відрегулювали, щоб слідкувати за доріжкою. Для пошуку об'єктив рухався б під час розшифровки підканалу Q, поки не знайдеться правильна доріжка. Це позиціонування трохи грубе, але цілком адекватне для прослуховування музики.

На сьогоднішній день багато компакт-дисків комп'ютера не можуть повністю точно розташувати об'єктив і синхронізувати схему декодування, щоб зчитування аудіо-зразків починалося з точного положення. Ось чому багато програм для копіювання компакт-дисків мають режим "параної", де вони перекривають читання та порівнюють результати, щоб налаштувати цей "тремтіння". Як частина аудіопотоку, підканал також підлягає тремтінню, і саме тому ви отримуєте різні файли підканалів, коли ви копіюєте на компакт-диску, який не може точно розмістити.

Коли специфікація CD (CD-ROM) для даних була розроблена для розширення специфікації CD-DA, важливість точної адреси та зчитування даних була визнана, тому аудіокадр 2352 байт був розділений на 12 байтів синхронізації та 4 байти заголовка (для адреса сектора), залишаючи решта 2336 байтів для даних та додатковий рівень виправлення помилок. Використовуючи цю схему, сектори можна вирішити точно, не покладаючись лише на інформацію Q-каналу. Тому ефект тремтіння не застосовується, ви завжди отримуєте однакові дані, коли ви скидаєте компакт-диск, і додаткова кмітливість у демпінгу не потрібна.

Редагувати з додатковою інформацією:

Згідно з даними Ecma-130 , дані шифруються поетапно: 24 байти складають F1-кадр , байти 106 цих кадрів розподіляються на 106 F2-кадрів , які отримують 8 зайвих байтів виправлення помилок. Ці кадри в свою чергу отримують додатковий байт ("керуючий байт"), щоб перетворити їх у F3-Frames . Додатковий байт містить інформацію про підканали (по одному підканалу для кожної бітової позиції). Група з 98 F3-кадрів називається секцією , і 98 пов'язаних керуючих байтів містять два байти синхронізації та 96 байт реальних даних про підканали. Крім того, у підканалу Q є 16 біт виправлення помилок CRC у цих 96 бітах.

Ідея цього полягає в тому, щоб розподіляти дані на поверхні диска таким чином, щоб подряпини, бруд тощо не впливали на безліч безперервних бітів, тому виправлення помилок може відновити втрачені дані до тих пір, поки подряпини не будуть занадто великий.

Як наслідок, апаратному пристрою компакт-дисків потрібно прочитати повний розділ після перестановки об'єктива, щоб з’ясувати, де він знаходиться в потоці даних. Дефрагментація різних етапів здійснюється апаратними засобами, яким потрібно синхронізуватись до 2-х байтів синхронізації в потоці керування-байтом. Для всіх моделей приводів компакт-дисків потрібна різна кількість часу для синхронізації порівняно з іншими моделями (ви можете перевірити це, прочитавши з двох різних дисків, якщо вони є), залежно від способу реалізації обладнання. Крім того, багато моделей не завжди займають синхронізацію в той самий час, тому вони можуть початись трохи рано чи пізно та виводити декламовані дані не завжди в один байт.

Отже, коли програма копіювання видає READ CDкоманду (0xBE), вона надає довжину передачі та адресу старту (а точніше - час Q-каналу). Привід позиціонує об'єктив, розшифровує кадри, витягує Q-канал, порівнює час, і коли знаходить правильний час, він починає передавати. Ця передача не завжди починається в тому ж байті, як пояснено вище, тому результат кількох READ CDкоманд може бути зміщений один проти одного. Ось чому ви бачите різні файли підканалів від вашого ріпера.

Залежно від обладнання та обставин, коли лінза налаштована, це більш-менш випадково, якщо передача починається кілька зразків рано чи кілька зразків пізно. Тож єдиний шаблон, який ви побачите в результатах, - це те, що зсуви кратні довжині передачі.

Деякі моделі приводів насправді мають точне обладнання, яке завжди почне передачу одночасно. Стандарт визначає трохи в режимі сторінки 0x2a ("CD-DVD-можливості та сторінки механічного статусу"), що вказує, чи це так, але досвід у реальному світі показує, що деякі диски, які претендують на точність, насправді ні. (Під Linux, ви можете використовувати sg_modesз sg3-utilesпакета для читання сторінок режиму, я не знаю , що інструмент для використання під Windows).

Відповідно до цієї статті у Вікіпедії

Кадр містить 33 байти, з яких 24 байти - це аудіо або користувацькі дані, вісім байтів - виправлення помилок (CIRC), а один байт - для субкоду.

Це говорить про відсутність виправлення помилок для підканалу.

Я також знайшов інше питання в іншому місці . Мова йде про аудіо компакт-диски, але я думаю, що це вирішує правильну проблему:

Я можу сказати лише те, що мені ніколи не вдалося отримати два однакових показання підканалу (* .SUB файл) під час читання з одного CD-DA / CD-TEXT. Це нормально при читанні в режимі RAW, оскільки дані не виправляються, оскільки формат CD-DA / CD-TEXT не містить EDC / ECC у всіх підканалах?

Відповідь там:

Рід-Соломоновому кодуванню піддаються лише аудіодані (C1 і C2). Дані каналу субкоду (канали P ... W) не піддаються перемежуванню або захисту від помилок.

Хоча dirkt може бути правильним в іншій відповіді на ваше запитання про те, що вам можуть не знадобитися .subфайли, відповідь прямо не стосується вашого питання:

Яке пояснення такої поведінки?

Моя відповідь: ви отримуєте різні .subфайли, оскільки у підканалів немає виправлення помилок. Помилки читання виправляються (або принаймні виявляються) під час читання аудіо- чи користувацьких даних, але помилка читання може передаватися такою, яка є, коли вона виникає в біті підканалу. Окремі помилки через подряпини чи пил можуть з’являтися під час одного сеансу читання, не з’являтися під час іншого тощо - отже, .subфайли, які відрізняються.

Відповідь розширено на адресу коментаря:

У мене дві копії цього диска, одна з яких у відмінному стані (жодної видимої подряпини), і поведінка все одно. У мене також є інші старі ігрові компакт-диски в гіршому стані, які мають послідовний .subфайл у кількох дампах.

Я підозрюю (на жаль, без важких доказів), що різні компакт-диски, можливо, були виготовлені з різною якістю. У випадку, коли підканали не мають значення, диск нижчої якості все ще може пройти тести якості, призначені лише для виявлення невідповідності даних. Або це може бути просто ймовірнісна справа: один диск має своє слабке місце (трохи, яке дає непослідовні показання), де виправлення помилок може виправити це; інша трапляється, щоб вона була в області підканалів.

Одного такого біта підканалу достатньо, щоб надати вам різні контрольні суми, тоді як навіть тисячі "невизначених" бітів у області даних користувачів можуть бути мовчазно виправлені, коли це потрібно, якщо тільки вони достатньо розподілені, тому алгоритм виправлення помилок має справу з не надто- велика частина їх одночасно.

Відповідь розгорнута в результаті реакції на KProbe 2.

Наскільки я знаю, помилки C1 допускаються (до деякої кількості), оскільки вони мовчки виправляються ( докладніше тут ). Ця корекція працює через біти виправлення помилок. Як я вже говорив раніше, субканали взагалі не мають такої надмірності ( dirkt згадує виправлення помилок Q-підканалу CRC, але це не сильно змінюється в моєму висновку). Більше того, якщо помилка трапиться там, немає способу її знати, якщо ви заздалегідь не знаєте, які правильні дані підканалів.

Отже, у вас було 1855 помилок, про які ви знаєте. Повторіть тест (серйозно, зробіть це!), І у вас можуть виникнути, наприклад, 1790 помилок; або 1892. Проте виправлений вихід є однаковим щоразу, коли ви читаєте.

Якщо є один біт підканалу на кожні 32 біти даних, то я кажу, що ви, мабуть, маєте близько 1855/32 біт підканалу, які були прочитані з невиявленою помилкою. Це приблизно 58 біт. Ну, майже, тому що завдяки Q-підканалу CRC деякі з цих помилок можуть бути виявлені принаймні. Оскільки Q - один з восьми підканалів, я вважаю, що у вас залишилося близько 50 помилкових бітів в інших підканалах. Наступного разу, коли ви прочитаєте, ви можете отримати кілька цих бітів без помилки, а також кілька нових помилок підканалу в інших місцях. Так ви отримаєте інший .subфайл. І все одно ви точно не дізнаєтесь, який із цих бітів було прочитано правильно вперше чи вдруге.