Я делаю резервные копии старых видеоигр с помощью CloneCD 5.3.3.0 на своем компьютере с Windows 10 x64 и приводом Samsung SH-S223L.
Одна из них — Hellfire для ПК (дополнение к Diablo 1):
- На диске есть
COMPACT disc DATA STORAGEлоготип - Серийный номер:
S0011770 - Заводской SID-код:
IFPI 1218 - Код 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
Насколько я знаю, в игре нет защиты, но когда я дважды сбрасываю диск, то получаю разные файлы подканалов ( .sub). Файлы .ccdи .imgидентичны, .subотличаются только , я использовал контрольные суммы SHA1 и шестнадцатеричный редактор, чтобы это проверить.
Я загрузил два .subфайла дампаздесь.
Я должен упомянуть, что у меня есть две копии этого диска, и поведение обоих дисков одинаково.
Я также сделал дамп нескольких других носителей CD-ROM, иногда я сталкиваюсь с таким поведением, иногда подканал остается неизменным во всех дампах.
Чем объясняется такое поведение?
Редактировать:
Я снова загрузил тот же CD-ROM с помощью привода Lite-On iH124-14 и увидел то же самое поведение (другие .subфайлы).
Я также проверил носитель на наличие ошибок с помощью KProbe 2 и получил следующий результат:
Редактировать:
Похоже, что состояние диска и/или недостаточная точность привода в сочетании с тем фактом, что подканал не имеет механизма контроля ошибок (за исключением канала Q), объясняет, почему я получаю разные .subфайлы при многократном копировании одного и того же носителя.
Должен упомянуть, что я также приобрел привод Plextor PX-712A и мне удалось получить одинаковые .subфайлы из разных дампов с помощьюСоздатель образа диска. Это программное обеспечение использует 0xD8инструкции вместо 0xBEинструкций для чтения диска, что приводит к более точным изображениям. Только несколько приводов (в основном Plextor) поддерживают эту инструкцию.
Также у меня на самом деле есть две физические копии этого CD-ROM, который я сбрасываю (один и тот же серийный номер, те же коды IFPI и та же лазерная гравировка информации). Если я сбрасываю один и тот же диск несколько раз с помощью Disc Image Creator, я получаю согласованные .subфайлы, но не если я сбрасываю первый диск, а затем второй.
Я думаю, это связано с состоянием носителя, так как на одном из них есть несколько царапин и больше ошибок C1/C2.
решение1
Различные форматы CD немного запутаны, а официальные спецификации («красная книга» для аудио CD, «желтая книга» для CD с данными) не находятся в свободном доступе. Но вы можете найти некоторые подробности в доступных стандартах, таких как Ecma-130.
Оригинальный аудио-CD (также называемый CD-DA) был смоделирован по образцу виниловой пластинки, что означает, что он также использует спиральную дорожку непрерывных аудиоданных (DVD позже использовал кольцевые дорожки). Внутри этих аудиоданных очень сложным образом чередуются 8 подканалов (от P до W), из которых подканал Q содержит информацию о времени (буквально в минутах/секундах/долях секунд) и текущий номер дорожки. Для первоначальной цели этого было достаточно: для непрерывного воспроизведения линза была просто слегка отрегулирована, чтобы следовать за дорожкой. Для поиска линза перемещалась при декодировании подканала Q, пока не была найдена нужная дорожка. Такое позиционирование немного грубовато, но полностью подходит для прослушивания музыки.
До сих пор многие компьютерные CD-приводы не могут абсолютно точно позиционировать линзу и синхронизировать схему декодирования, чтобы считывание аудиосэмплов начиналось с точной позиции. Вот почему многие программы копирования CD имеют режим «паранойи», в котором они выполняют перекрывающиеся считывания и сравнивают результаты, чтобы скорректировать этот «джиттер». Как часть аудиопотока, подканал также подвержен джиттеру, и вот почему вы получаете разные файлы подканалов, когда вы копируете на CD-привод, который не может позиционировать точно.
Когда спецификация CD с данными (CD-ROM) была разработана для расширения спецификации CD-DA, важность точной адресации и чтения данных была признана, поэтому аудиокадр из 2352 байт был разделен на 12 синхробайтов и 4 байта заголовка (для адреса сектора), оставив оставшиеся 2336 байт для данных и дополнительного уровня исправления ошибок. Используя эту схему, секторы могут быть адресованы точно, без необходимости полагаться только на информацию канала Q. Поэтому эффект джиттера не применяется, вы всегда получаете одни и те же данные при дампе CD-ROM, и никаких дополнительных ухищрений при дампе не требуется.
Редактироватьс более подробной информацией:
В соответствии сЭКМА-130, данные шифруются поэтапно: 24 байта составляютF1-Кадр, байты 106 этих кадров распределяются по 106F2-кадры, которые получают 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).
решение2
В соответствии сэта статья в Википедии
Кадр состоит из 33 байтов, из которых 24 байта — это аудиоданные или пользовательские данные, восемь байтов — данные для исправления ошибок (генерируемые CIRC) и один байт — для подкода.
Это говорит о том, что для подканала нет исправления ошибок.
Я также нашелеще один вопрос в другом месте. Речь идет об аудио-CD, но я думаю, что это затрагивает правильную тему:
Все, что я могу сказать, это то, что мне никогда не удавалось получить два идентичных чтения подканала (файл *.SUB) при чтении с одного и того же CD-DA/CD-TEXT. Это нормально при чтении в режиме RAW, поскольку данные не корректируются, поскольку формат CD-DA/CD-TEXT не несет EDC/ECC во всех подканалах?
Ответ там:
Кодированию Рида-Соломона (C1 и C2) подвергаются только аудиоданные. Данные субкодовых каналов (каналы P...W) не подвергаются перемежению или защите от ошибок.
Покадирктможет быть прямо веще один ответ на ваш вопросчто вам, возможно, не нужны .subфайлы, ответ не дает прямого ответа на ваш вопрос:
Чем объясняется такое поведение?
Мой ответ: вы получаете разные .subфайлы, потому что подканалы не имеют исправления ошибок. Ошибки чтения исправляются (или, по крайней мере, обнаруживаются) при чтении аудио или пользовательских данных, но ошибка чтения может пройти как есть, когда она происходит на бите подканала. Конкретные ошибки из-за царапин или пыли могут появляться во время одного сеанса чтения, не появляться во время другого и т. д. – отсюда и .subфайлы, которые отличаются.
Ответ расширен с учетом комментария:
У меня есть две копии этого диска, одна из которых в отличном состоянии (без видимых царапин), и поведение все то же самое. У меня также есть другие старые игровые CD-ROM в худшем состоянии, которые имеют согласованный
.subфайл в нескольких дампах.
Я подозреваю (к сожалению, без веских доказательств), что разные CD могли быть изготовлены с разным качеством. В случае, когда подканалы не имеют значения, диск более низкого качества может все равно пройти тесты качества, предназначенные только для обнаружения несоответствия данных. Или это может быть просто вероятностным вопросом: у одного диска есть слабое место (места) (бит, который дает несоответствующие показания), где исправление ошибок может это исправить; у другого оно находится в области подканала.
Одного такого бита подканала достаточно, чтобы дать вам различные контрольные суммы, в то время как даже тысячи «неопределенных» бит в области пользовательских данных могут быть тихо исправлены, когда это необходимо, если только они достаточно распределены, чтобы алгоритм исправления ошибок имел дело не с слишком большим их количеством за раз.
Ответ расширен в ответ на результаты KProbe 2.
Насколько мне известно, ошибки C1 допускаются (в некотором количестве), поскольку они исправляются молча (больше здесь). Эта коррекция работает благодаря битам коррекции ошибок. Как я уже говорил, подканалы в общем случае не имеют такой избыточности (дирктупоминает коррекцию ошибок CRC Q-подканала, но это не сильно меняет мой вывод). Более того, если ошибка возникает там, нет способа узнать об этом, если вы заранее не знаете, каковы правильные данные подканала.
Итак, у вас было всего 1855 ошибок, о которых вы знаете. Повторите тест (серьезно, сделайте это!), и у вас может быть, например, 1790 ошибок; или 1892. Тем не менее, исправленный вывод будет одинаковым каждый раз, когда вы читаете.
Если на каждые 32 бита данных приходится один бит подканала, то я говорю, что у вас, вероятно, около 1855/32 бит подканала, которые были прочитаны с необнаруженной ошибкой. Это около 58 бит. Ну, почти, потому что благодаря CRC Q-подканала некоторые из этих ошибок могут быть обнаружены по крайней мере. Поскольку Q является одним из восьми подканалов, я оцениваю, что у вас осталось около 50 ошибочных бит в других подканалах. В следующий раз, когда вы будете читать, вы можете получить несколько из этих бит без ошибки и несколько новых ошибок подканала в другом месте. Таким образом, вы получите другой .subфайл. И все равно вы не будете знать наверняка, какие из этих бит были прочитаны правильно в первый раз или во второй.