Подканал 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
• Дата создания 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, иногда я получаю такое поведение, иногда субканал согласован для всех дампов.

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

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

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

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

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

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

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

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

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

Тем не менее, сегодня многие компьютерные приводы компакт-дисков не могут точно позиционировать объектив и синхронизировать схему декодирования, так что считывание аудиосэмплов начинается с точного положения. Вот почему многие программы копирования 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 битах.

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

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

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

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

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

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

Кадр содержит 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файл. И все же вы не будете точно знать, какие из этих битов были прочитаны правильно в первый раз или во второй.