¿El subcanal de CD-ROM es diferente al descargar el mismo disco?

¿El subcanal de CD-ROM es diferente al descargar el mismo disco?

Estoy haciendo copias de seguridad de videojuegos antiguos 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 de Diablo 1):

  • El disco tiene un COMPACT disc DATA STORAGElogo.
  • Número de serie:S0011770
  • Código SID de fábrica:IFPI 1218
  • Código SID de CD-Master:IFPI L032
  • Fecha de creación del PVD ISO 9660:1997-11-18 16:30:00.00

Yo uso elredump.orgRecomendación de perfil de 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 yo 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 .subdiferentes, utilicé sumas de verificación SHA1 y un editor hexadecimal para verificar esto.
Subí dos.sub volcados de archivosaquí.
Debo mencionar que tengo dos copias de este disco y el comportamiento es idéntico en ambos discos.

También descarté varios otros medios CD-ROM, a veces obtengo este comportamiento, a veces el subcanal es consistente en todos 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:

Escaneo KProbe 2 BLER


Editar:

Parece que la condición del disco y/o la falta de precisión de la unidad, sumada al hecho de que el subcanal no tiene mecanismo de control de errores (excepto el canal Q), explica por qué obtengo .subarchivos diferentes al descargar el mismo medio varias veces.

Debo mencionar que también obtuve una unidad Plextor PX-712A y logré obtener .subarchivos consistentes en todos los volcados usandoCreador de imágenes de disco. Este software aprovecha 0xD8instrucciones en lugar de 0xBEinstrucciones para leer el disco, lo que genera imágenes más precisas. Sólo unas pocas unidades (principalmente Plextor) admiten esta instrucción.

Además, tengo dos copias físicas de este CD-ROM que estoy desechando (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 rayones y más errores C1/C2.

Respuesta1

Los distintos formatos de CD son un poco complicados y las especificaciones oficiales ("libro rojo" para CD de audio, "libro amarillo" para CD de datos) no están disponibles gratuitamente. Pero puedes encontrar algunos detalles en estándares disponibles como Ecma-130.

El CD de audio original (también llamado CD-DA) se inspiró en el disco de vinilo, lo que significa que también utiliza una pista en espiral de datos de audio continuos (el DVD luego usó 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 tiempo (literalmente en minutos/segundos/fracciones de segundos) y el número de pista actual. Para el propósito original esto era suficiente: para el juego continuo, la lente simplemente se ajustaba ligeramente para seguir la pista. Para buscar, la lente se movería mientras decodificaba el subcanal Q hasta encontrar la pista correcta. Esta posición es un poco tosca, pero completamente adecuada para escuchar música.

Aún hoy, muchas unidades de CD de computadora no pueden colocar la lente con total precisión y sincronizar el circuito de decodificación para que la lectura de muestras de audio comience en una posición exacta. Esta es la razón por la que muchos programas de extracción de CD tienen un modo de "paranoia", en el que realizan lecturas superpuestas y comparan los resultados para ajustarse a esta "nerviosidad". Como parte de la transmisión de audio, el subcanal también está sujeto a fluctuaciones y es por eso que obtienes diferentes archivos de subcanal cuando copia en una unidad de CD que no puede posicionarse con precisión.

Cuando se desarrolló la especificación de CD de datos (CD-ROM) para ampliar la especificación CD-DA, se reconoció la importancia de direccionar y leer 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. Usando este esquema, los sectores pueden abordarse exactamente sin tener que depender únicamente de la información del canal Q. Por lo tanto, el efecto de fluctuación no se aplica, siempre se obtienen los mismos datos cuando se volca un CD-ROM y no se necesita ninguna habilidad adicional para volcar.

Editarcon más detalles:

De acuerdo aECMA-130, los datos se codifican en etapas: 24 bytes forman unFotograma F1, los bytes de 106 de estas tramas se distribuyen en 106Marcos F2, que obtienen 8 bytes adicionales de corrección de errores. A su vez, esas tramas obtienen cada una un byte adicional ("byte de control") para convertirlas enF3-Marcos. El byte adicional contiene la información del subcanal (un subcanal para cada posición de bit). Un grupo de 98 fotogramas F3 se denominasecció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 errores CRC en esos 96 bits.

La idea detrás de esto es distribuir los datos en la superficie del disco de tal manera que los rayones, la suciedad, etc. no afecten a muchos bits continuos, por lo que la corrección de errores puede recuperar los datos perdidos siempre que los rayones 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 saber dónde se encuentra en el flujo de datos. La descodificación de las distintas etapas se realiza mediante hardware, que necesita 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 esté implementado el hardware. Además, muchos modelos no siempre tardan exactamente el mismo tiempo en sincronizarse, por lo que pueden comenzar un poco antes o un poco 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, la hora del canal Q). La unidad posiciona la lente, descodifica los marcos, extrae el canal Q, compara la hora y, cuando encuentra la hora correcta, comienza a transferir. Esta transferencia no siempre comienza en el mismo byte como se explicó anteriormente, por lo que el resultado de múltiples READ CDcomandos puede cambiarse entre sí. Es por eso que ves diferentes archivos de subcanal desde tu destripador.

Dependiendo del hardware y de las circunstancias en las 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 turnos son un múltiplo de la duración de la transferencia.

Algunos modelos de unidades tienen hardware preciso que siempre iniciará la transferencia al mismo tiempo. El estándar define un bit en la página de modo 0x2a ("Página de estado mecánico y capacidades de CD/DVD") que indica si ese es el caso, pero la experiencia del mundo real muestra que algunas unidades que dicen ser exactas en realidad no lo son. (En Linux, puede usar sg_modesel sg3-utilespaquete para leer las páginas de modo, no sé qué herramienta usar en Windows).

Respuesta2

De acuerdo aeste artículo de Wikipedia

Una trama consta de 33 bytes, de los cuales 24 bytes son datos de audio o de usuario, ocho bytes son corrección de errores (generados por CIRC) y un byte es para subcódigo.

Esto sugiere que no hay corrección de errores para el subcanal.

yo también he encontradootra pregunta en otro lado. Se trata de CD de audio, pero creo que aborda el tema correcto:

Todo lo que puedo decir es que nunca logré obtener dos lecturas de subcanal idénticas (archivo *.SUB) al leer del mismo CD-DA/CD-TEXT. ¿Es eso normal cuando se lee en modo RAW porque los datos no se corrigen porque el formato CD-DA/CD-TEXT no lleva EDC/ECC en todos los subcanales?

La respuesta ahí:

Sólo los datos de audio están sujetos a la codificación Reed-Solomon (C1 y C2). Los datos de los canales de subcódigo (canales P...W) no están sujetos a entrelazado ni a protección contra errores.

Mientrassuciopuede estar justo enotra respuesta a tu preguntaque es posible que no necesite .subarchivos, la respuesta no aborda explícitamente su pregunta:

¿Cuál es la explicación de este comportamiento?

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) durante la lectura de audio o datos del usuario, pero un error de lectura puede pasar tal cual cuando ocurre en el bit del subcanal. Algunos errores debidos a rayones o polvo pueden aparecer durante una sesión de lectura, no aparecer durante otra, etc., por lo que .sublos archivos difieren.


Respuesta ampliada para abordar el comentario:

Tengo dos copias de este disco, una de ellas en excelentes condiciones (sin rayones visibles) y el comportamiento sigue siendo el mismo. También tengo otros CD-ROM de juegos antiguos en peores condiciones que tienen .subarchivos consistentes en múltiples volcados.

Sospecho (desafortunadamente sin pruebas contundentes) que se pueden haber 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 inconsistencia de datos únicamente. O puede ser simplemente una cuestión probabilística: un disco tiene su(s) punto(s) débil(s) (un bit que da lecturas inconsistentes) donde la corrección de errores puede solucionarlo; otro lo tiene en el área del subcanal.

Un bit de subcanal de este tipo es suficiente para proporcionar diferentes sumas de comprobación, mientras que incluso miles de bits "indecisos" en el área de datos del usuario pueden corregirse silenciosamente cuando sea necesario, si se distribuyen lo suficiente, por lo que el algoritmo de corrección de errores se ocupa de problemas no demasiado muchos de ellos a la vez.


Respuesta ampliada en reacción a los resultados de KProbe 2.

Hasta donde yo sé, los errores 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 tal redundancia en general (suciomenciona 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 tenías un total de 1855 errores que conoces. Repita la prueba (¡en serio, hágalo!) y es posible que tenga, por ejemplo, errores 1790; o 1892. Sin embargo, el resultado corregido es el mismo cada vez que lees.

Si hay un bit de subcanal por cada 32 bits de datos, entonces digo que probablemente tenga alrededor de 1855/32 bits de subcanal que se leyeron con un error no detectado. Eso es alrededor de 58 bits. Bueno, casi, porque gracias al CRC del subcanal Q al menos algunos de estos errores pueden detectarse. Dado que 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, es posible que obtenga algunos de estos bits sin errores y algunos errores de subcanal nuevos en otros lugares. Entonces obtendrás .subun archivo diferente. Y aún así no sabrás con seguridad cuáles de esos bits se leyeron correctamente la primera o la segunda vez.

información relacionada