13

Я делаю резервные копии старых видеоигр с 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
  • Дата создания ISO 9660 PVD: 1997-11-18 16:30:00.00

Я использую рекомендацию профиля CloneCD redump.org :

[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 здесь.
Я должен упомянуть, что у меня есть две копии этого диска, и поведение идентично с обоими дисками.

Я также записал несколько других носителей CD-ROM, иногда я получаю такое поведение, иногда субканал согласован для всех дампов.

Чем объясняется такое поведение?


Редактировать:

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

KProbe 2 BLER скан


Редактировать:

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

Я должен упомянуть, что я также получил привод Plextor PX-712A и смог получить согласованные файлы .sub в дампах с помощью Disc Image Creator. Это программное обеспечение использует инструкции 0xD8 вместо команд 0xBE для чтения диска, что приводит к более точным изображениям. Только несколько дисков (в основном Plextor) поддерживают эту инструкцию.

Также у меня есть две физические копии этого CD-ROM, который я сбрасываю (тот же серийный номер, те же коды IFPI и та же информация с лазерной гравировкой). Если я записываю один и тот же диск несколько раз с помощью Disc Image Creator, я получаю согласованные файлы .sub но нет, если я записываю первый, а затем второй диск.
Я предполагаю, что это связано с условиями среды, так как один из них имеет несколько царапин и больше ошибок C1/C2.

2 ответа2

13

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

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

Тем не менее, сегодня многие компьютерные CD-дисководы не могут точно позиционировать объектив и синхронизировать схему декодирования, так что считывание аудиосэмплов начинается с точного положения. Вот почему многие программы копирования CD имеют режим "паранойя", где они выполняют перекрывающиеся чтения и сравнивают результаты, чтобы приспособиться к этому "джиттеру". Как часть аудиопотока, субканал также подвержен джиттеру, и поэтому вы получаете разные файлы субканалов, когда вы копируете на дисковод компакт-дисков, который не может точно позиционироваться.

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

Изменить с более подробной информацией:

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

Идея заключается в том, чтобы распределять данные по поверхности диска таким образом, чтобы царапины, грязь и т.д. Не влияли на большое количество непрерывных битов, поэтому исправление ошибок может восстановить потерянные данные, если царапины не слишком большой.

Как следствие, аппаратное обеспечение привода компакт-дисков должно прочитать весь раздел после изменения положения объектива, чтобы выяснить, где он находится в потоке данных. Дескремблирование различных этапов выполняется аппаратным обеспечением, которое должно синхронизироваться с двумя байтами синхронизации в потоке управляющих байтов. Все модели дисководов компакт-дисков требуют различного количества времени для синхронизации по сравнению с другими моделями (это можно проверить, прочитав данные с двух разных дисков, если они у вас есть), в зависимости от того, как реализовано оборудование. Кроме того, многим моделям не всегда требуется одинаковое время для синхронизации, поэтому они могут начать немного раньше или позже и выводить дескремблированные данные не всегда в одном и том же байте.

Поэтому, когда программа копирования выполняет команду READ CD (0xBE), она предоставляет длину передачи и начальный адрес (или, скорее, время Q-канала). Привод позиционирует объектив, расшифровывает кадры, извлекает Q-канал, сравнивает время и, когда он находит правильное время, начинает передавать. Эта передача не всегда начинается с одного и того же байта, как объяснено выше, поэтому результат нескольких команд READ CD может быть смещен относительно друг друга. Вот почему вы видите разные файлы субканалов от вашего рипера.

В зависимости от аппаратного обеспечения и обстоятельств, когда объектив отрегулирован, более или менее случайно, если передача начинается на несколько сэмплов раньше или на несколько с опозданием. Таким образом, единственная закономерность, которую вы увидите в результатах, состоит в том, что сдвиги кратны длине передачи.

Некоторые модели приводов на самом деле имеют точное оборудование, которое всегда начинает передачу одновременно. Стандарт определяет бит на странице режима 0x2a («Возможности CD/DVD и страница механического состояния»), которая указывает, так ли это, но реальный опыт показывает, что некоторые приводы, претендующие на точность, на самом деле не соответствуют действительности. (В Linux вы можете использовать sg_modes из sg3-utiles для чтения страниц режима, я не знаю, какой инструмент использовать в Windows).

8

Согласно этой статье в Википедии

Кадр содержит 33 байта, из которых 24 байта являются звуковыми или пользовательскими данными, восемь байтов являются исправлением ошибок (сгенерированным CIRC), и один байт предназначен для субкода.

Это говорит о том, что нет исправления ошибок для подканала.

Я также нашел другой вопрос в другом месте. Речь идет об аудио CD, но я думаю, что это решает правильную проблему:

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

Ответ там:

Только аудиоданные подвергаются кодированию Рида-Соломона (C1 и C2). Подкод данных канала (каналы P ...W) не подвергаются чередованию или защите от ошибок.

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

Чем объясняется такое поведение?

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


Ответ расширен до адреса комментария:

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

Я подозреваю (к сожалению, без веских доказательств), что разные компакт-диски могли быть изготовлены с разным качеством. В случае, когда подканалы не имеют значения, диск более низкого качества все еще может проходить качественные тесты, предназначенные только для обнаружения несоответствия данных. Или это может быть просто вероятностный вопрос: один диск имеет свои слабые места (бит, который дает непоследовательные показания), где исправление ошибок может исправить это; другой, случается, имеет это в области подканала.

Одного такого бита подканала достаточно, чтобы получить разные контрольные суммы, в то время как даже тысячи "нерешенных" битов в области пользовательских данных могут быть незаметно скорректированы, когда это необходимо, если только они распределены достаточно, поэтому алгоритм исправления ошибок работает с не слишком большая часть их за один раз.


Ответ расширен в ответ на результаты KProbe 2.

Насколько я знаю, ошибки С1 допускаются (в некотором количестве), потому что они незаметно исправляются (подробнее здесь). Это исправление работает из-за битов исправления ошибок. Как я уже говорил, субканалы в общем случае не имеют такой избыточности (dirkt упоминает исправление ошибок CRC Q-подканала, но это не сильно меняет мое заключение). Более того, если ошибка возникает там, узнать ее невозможно, если только вы заранее не знаете, что такое правильные данные подканала.

Итак, у вас было 1855 ошибок, о которых вы знаете. Повторите тест (серьезно, сделайте это!) и у вас может быть, например, 1790 ошибок; или 1892. Тем не менее, исправленный вывод один и тот же каждый раз, когда вы читаете.

Если для каждых 32 битов данных имеется один бит подканала, то я говорю, что у вас, вероятно, около 1855/32 битов подканала, которые были прочитаны с необнаруженной ошибкой. Это около 58 бит. Ну, почти, потому что благодаря QC-субканалу CRC некоторые из этих ошибок могут быть обнаружены по крайней мере. Поскольку Q является одним из восьми подканалов, я считаю, что у вас осталось около 50 ошибочных битов в других подканалах. В следующий раз, когда вы прочитаете, вы можете получить несколько из этих битов без ошибок и несколько новых ошибок субканала в другом месте. Таким образом, вы получите другой файл .sub . И все же вы не будете точно знать, какие из этих битов были прочитаны правильно в первый раз или во второй.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .