Estoy haciendo copias de seguridad de viejos videojuegos con CloneCD 5.3.3.0 en mi computadora Windows 10 x64 con una unidad Samsung SH-S223L.
Uno de ellos es Hellfire para PC (expansión Diablo 1):
- El disco tiene un
COMPACT disc DATA STORAGElogo - Número de serie:
S0011770 - Código SID de fábrica:
IFPI 1218 - CD-Master Código SID:
IFPI L032 - Fecha de creación de PVD ISO 9660:
1997-11-18 16:30:00.00
Yo uso la recomendación de perfil 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
Hasta donde sé, el juego no tiene protección, pero cuando vuelco el disco dos veces, termino con diferentes archivos de subcanal ( .sub). Los archivos .ccdy .imgson idénticos, solo los diferentes .sub, utilicé sumas de verificación SHA1 y un editor hexadecimal para verificar esto.
He subido dos .subvertederos de archivos aquí .
Tengo que mencionar que tengo dos copias de este disco y el comportamiento es idéntico con ambos discos.
También volqué varios otros medios de CD-ROM, a veces obtengo este comportamiento, a veces el subcanal es consistente en los volcados.
¿Cuál es la explicación de este comportamiento?
Editar:
Volví a descargar el mismo CD-ROM con una unidad Lite-On iH124-14 y veo el mismo comportamiento ( .subarchivos diferentes ).
También revisé el medio en busca de errores con KProbe 2 y obtengo el siguiente resultado:
Editar:
Parece que la condición del disco y / o la falta de precisión de la unidad agregada al hecho de que el subcanal no tiene un mecanismo de control de errores (excepto el canal Q) explica por qué obtengo diferentes .subarchivos cuando descargo el mismo medio varias veces.
Debo mencionar que también obtuve una unidad Plextor PX-712A y logré obtener .subarchivos consistentes en los volcados utilizando Disc Image Creator . Este software aprovecha las 0xD8instrucciones en lugar de las 0xBEinstrucciones para leer el disco, lo que resulta en imágenes más precisas. Solo unas pocas unidades (en su mayoría, Plextor) admiten esta instrucción.
También tengo dos copias físicas de este CD-ROM que estoy descargando (el mismo número de serie, los mismos códigos IFPI y la misma información grabada con láser). Si vuelco el mismo disco varias veces con Disc Image Creator, obtengo .subarchivos consistentes , pero no si vuelco el primer disco y luego el segundo.
Supongo que está relacionado con las condiciones de los medios, ya que uno de ellos tiene algunos rasguños y más errores C1 / C2.
Respuestas:
Los diversos formatos de CD están un poco involucrados, y las especificaciones oficiales ("libro rojo" para CD de audio, "libro amarillo" para CD de datos) no están disponibles de forma gratuita. Pero puede encontrar algunos detalles en los estándares disponibles como Ecma-130.
El CD de audio original (también llamado CD-DA) fue modelado en el disco de vinilo, lo que significa que también utiliza una pista en espiral de datos de audio continuos (el DVD luego utilizó pistas circulares). Intercalados dentro de estos datos de audio de una manera muy compleja hay 8 subcanales (P a W), de los cuales el subcanal Q contiene información de temporización (literalmente en minutos / segundos / fracciones de segundos) y el número de pista actual. Para el propósito original, esto fue suficiente: para la reproducción continua, la lente se ajustó ligeramente para seguir la pista. Para buscar, la lente se movería mientras decodificaba el subcanal Q hasta encontrar la pista correcta. Este posicionamiento es un poco tosco, pero completamente adecuado para escuchar música.
Todavía hoy, muchas unidades de CD de computadora no pueden posicionar con precisión la lente y sincronizar los circuitos de decodificación para que la lectura de muestras de audio comience en una posición exacta. Esta es la razón por la cual muchos programas de extracción de CD tienen un modo de "paranoia", donde hacen lecturas superpuestas y comparan los resultados para ajustarse a esta "fluctuación". Como parte de la transmisión de audio, el subcanal también está sujeto a fluctuaciones, y es por eso que obtiene diferentes archivos de subcanal cuando extrae en una unidad de CD que no puede posicionarse con precisión.
Cuando se desarrolló la especificación del CD de datos (CD-ROM) para ampliar la especificación del CD-DA, se reconoció la importancia de direccionar y leer los datos con precisión, por lo que la trama de audio de 2352 bytes se subdividió en 12 bytes de sincronización y 4 bytes de encabezado (para la dirección del sector), dejando los 2336 bytes restantes para datos y un nivel adicional de corrección de errores. Con este esquema, los sectores se pueden abordar exactamente sin tener que depender únicamente de la información del canal Q. Por lo tanto, el efecto de jitter no se aplica, siempre obtienes los mismos datos cuando vuelcas un CD-ROM y no se necesita ninguna inteligencia adicional en el volcado.
Editar con más detalles:
De acuerdo con Ecma-130 , los datos se codifican en etapas: 24 bytes forman un cuadro F1 , los bytes de 106 de estos cuadros se distribuyen en 106 cuadros F2 , que obtienen 8 bytes adicionales de corrección de errores. Esos cuadros a su vez obtienen un byte adicional ("byte de control") para convertirlos en F3-Frames . El byte adicional contiene la información del subcanal (un subcanal para cada posición de bit). Un grupo de 98 F3-Frames se denomina sección , y los 98 bytes de control asociados contienen dos bytes de sincronización y 96 bytes de datos de subcanal reales. El subcanal Q además tiene 16 bits de corrección de error CRC en esos 96 bits.
La idea detrás de esto es distribuir datos en la superficie del disco de tal manera que los rasguños, la suciedad, etc. no afecten muchos bits continuos, por lo que la corrección de errores puede recuperar los datos perdidos siempre que los rasguños no sean demasiado grande.
Como consecuencia, el hardware de la unidad de CD necesita leer una sección completa después de reposicionar la lente para averiguar dónde está en el flujo de datos. El descifrado de las distintas etapas se realiza mediante hardware, que debe sincronizarse con los 2 bytes de sincronización en el flujo de bytes de control. Todos los modelos de unidades de CD necesitan una cantidad de tiempo diferente para sincronizarse en comparación con otros modelos (puede probarlo leyendo desde dos unidades diferentes, si las tiene), dependiendo de cómo se implemente el hardware. Además, muchos modelos no siempre tardan exactamente el mismo tiempo en sincronizarse, por lo que pueden comenzar un poco más temprano o más tarde y generar los datos descifrados no siempre en el mismo byte.
Entonces, cuando el programa de extracción emite un
READ CDcomando (0xBE), proporciona una longitud de transferencia y una dirección de inicio (o más bien, tiempo de canal Q). La unidad posiciona la lente, descifra los marcos, extrae el canal Q, compara el tiempo y, cuando encuentra el tiempo correcto, comienza a transferir. Esta transferencia no siempre comienza en el mismo byte que se explicó anteriormente, por lo que el resultado de múltiplesREAD CDcomandos puede cambiarse entre sí. Es por eso que ve diferentes archivos de subcanal de su destripador.Dependiendo del hardware y las circunstancias en que se ajusta la lente, es más o menos aleatorio si la transferencia comienza algunas muestras antes o algunas muestras tarde. Entonces, el único patrón que verá en los resultados es que los cambios son un múltiplo de la longitud de transferencia.
Algunos modelos de unidades tienen un hardware preciso que siempre comenzará la transferencia al mismo tiempo. El estándar define un bit en la página de modo 0x2a ("Capacidades de CD / DVD y página de estado mecánico") que indica si ese es el caso, pero la experiencia del mundo real muestra que algunas unidades que afirman ser exactas no lo son. (En Linux, puede usar
sg_modeselsg3-utilespaquete para leer las páginas de modo, no sé qué herramienta usar en Windows).fuente
.subarchivos en mi pregunta. Lo comparé con un editor hexadecimal y tienes razón, los datos se han cambiado, aunque no puedo encontrar ningún patrón obvio.sg_modes. Tengo0x2aen la sección "Capacidades MM y estado mecánico (obsoleto)". Mañana recibiré una nueva unidad Liteon y volveré a probar para ver si obtengo un subcanal constante en los volcados.De acuerdo con este artículo de Wikipedia
Esto sugiere que no hay corrección de errores para el subcanal.
También he encontrado otra pregunta en otro lugar . Se trata de CD de audio, pero creo que aborda el problema correcto:
La respuesta allí:
Si bien dirkt puede tener razón en otra respuesta a su pregunta de que es posible que no necesite
.subarchivos, la respuesta no aborda explícitamente su pregunta:Mi respuesta: obtienes
.subarchivos diferentes porque los subcanales no tienen corrección de errores. Los errores de lectura se corrigen (o al menos se detectan) al leer el audio o los datos del usuario, pero un error de lectura puede pasar tal cual cuando ocurre en el bit de subcanal. Pueden aparecer errores particulares debido a arañazos o polvo durante una sesión de lectura, no aparecer en otra, etc., por lo tanto, los.subarchivos son diferentes.Respuesta ampliada para abordar el comentario:
Sospecho (aunque desafortunadamente sin pruebas contundentes) que pueden haberse fabricado diferentes CD con diferente calidad. En el caso de que los subcanales no importen, el disco de menor calidad aún puede pasar pruebas de calidad diseñadas para detectar solo inconsistencias de datos. O puede ser simplemente una cuestión probabilística: un disco tiene sus puntos débiles (un bit que da lecturas inconsistentes) donde la corrección de errores puede solucionarlo; otro pasa a tenerlo en el área del subcanal.
Uno de esos bits de subcanal es suficiente para proporcionarle diferentes sumas de verificación, mientras que incluso miles de bits "indecisos" en el área de datos del usuario pueden corregirse silenciosamente cuando sea necesario, si solo se distribuyen lo suficiente, por lo que el algoritmo de corrección de errores no se ocupa demasiado. muchos de ellos a la vez.
La respuesta se expandió en reacción a los resultados de KProbe 2.
Hasta donde sé, los errores de C1 están permitidos (en cierta cantidad) porque se corrigen silenciosamente ( más aquí ). Esta corrección funciona debido a los bits de corrección de errores. Como dije antes, los subcanales no tienen tanta redundancia en general ( dirkt menciona la corrección de errores CRC del subcanal Q pero eso no cambia mucho en mi conclusión). Además, si el error ocurre allí, no hay forma de saberlo, a menos que sepa de antemano cuáles son los datos correctos del subcanal.
Entonces tuvo un total de 1855 errores que conoce. Repita la prueba (¡en serio, hágalo!) Y puede tener, por ejemplo, 1790 errores; o 1892. Sin embargo, la salida corregida es la misma cada vez que lee.
Si hay un bit de subcanal por cada 32 bits de datos, entonces digo que probablemente tenga unos 1855/32 bits de subcanal que se leyeron con un error no detectado. Eso es alrededor de 58 bits. Bueno, casi, porque gracias a Q-subchannel CRC, algunos de estos errores pueden detectarse al menos. Como Q es uno de los ocho subcanales, calculo que le quedan unos 50 bits erróneos en otros subcanales. La próxima vez que lea, puede obtener algunos de estos bits sin un error, y algunos nuevos errores de subcanal en otros lugares. Entonces obtendrá un
.subarchivo diferente . Y aún así, no sabrá con seguridad cuáles de esos bits se leyeron correctamente la primera o la segunda vez.fuente
.subarchivos consistentes en varios volcados. Soy consciente de que no necesito el subcanal dado que el juego no está protegido, estoy haciendo esta pregunta por curiosidad técnica :).