ZONA DE PRUEBAS

Gracias a ti, yo aun sigo peleandome con el plugin de Romcenter, que va en Delphi, y no es que tenga mucha idea, mas bien voy aprendiendo.

Me parece que le estáis dando al "data crc" una utilidad que no tiene, porque ...

imulilla escribió:Si crearamos 2 TSX de una misma cinta usando 2 grabadoras distintas (que fueran una un poco mas lenta que otra, por ejemplo), el File CRC seria diferente pero el data CRC seria el mismo.

eso es cierto, pero también es cierto que puede haber cintas distintas, cargando juegos distintos, y que tengan todas el mismo "data crc".

Realmente con el fin de "identificar una cinta" es mas útil usar el "file crc", que al menos identifica inequívocamente algo: "Esa cinta en concreto" (aunque no necesariamente el resto de cintas con el mismo juego)

eso es cierto, pero también es cierto que puede haber cintas distintas, cargando juegos distintos, y que tengan todas el mismo "data crc".

Cómo es posible que el data crc sea el mismo pero los juegos sean distintos? El data crc son los latos que lee el ordenador, no? Si a lo que te refieres es que puede haber dos conjuntos de datos que produzcan el mismo crc32 (una colisión), para eso están el MD5 y el SHA1.

Un saludo.

zerobyzero escribió:El data crc son los latos que lee el ordenador, no?

No, no, no es así.
A lo mejor estás pensando en formatos con el .tap, en el que no hay "datos analógicos".
En el tsx se representa "la cinta" con el conjunto de los datos + los metadatos.
Por eso, al cambiar "los metadatos", "la cinta" resultante varía aunque "los datos" sean los mismos.

A ver si me aclaro. Los meta-datos del bloque 4b, por ejemplo son:



Y luego van los datos reales, una serie de bytes. Qué significan exactamente los valores de los meta-datos? Lo que yo entiendo es que describen cómo se han almacenado los datos reales en la cinta: duración de los pulsos, el formato de los ceros y unos, etc... (si hay algún enlace donde se hable en más detalle de estos aspectos, estaría muy interesado). Por eso entiendo que podría cambiar el formato de pulsos, la pausa, etc... pero al final si la secuencia de bytes es la misma, el juego sería el mismo (que no la versión ya que los meta-datos son diferentes y por lo tanto la cinta en sí sería diferente; luego estaría el asunto de cómo de diferentes tienen que ser los meta-datos para que sean realmente dos versiones diferentes o sólo que una de las grabadoras no iban tan perfectamente "afinada" como la otra y como resultado los pulsos eran un poco más largos).

Saludos.

EDITO:

1. Se conoce algún juego (de MSX, Spectrum u otro sistema) en el que los datos reales sean iguals y los meta-datos diferentes?

2. Entiendo la importancia entonces de preservar los meta-datos, pero sigo pensando que ciertos bloques como los de información tosec y demás deben ser omitidos del cálculo del hash puesto que no se encuentran físicamente en la cinta sino que son añadidos posteriores y totalmente ajenos.

zerobyzero escribió:Por eso entiendo que podría cambiar el formato de pulsos, la pausa, etc... pero al final si la secuencia de bytes es la misma, el juego sería el mismo

No, no sería el mismo. Como te decía, la cinta tsx es el conjunto de los datos mas los metadatos. Si los separas malo...

El que los datos sean (por ejemplo) "1111" no quiere decir que el msx vaya a cargar "1111" si le cambias los metadatos.
Esos mismos datos "1111" se podía cargarán en el msx como "0000" si le das el cambiazo a las frecuencias.


(en el mensaje anterior hice referencia a los ficheros tap. Perdón, en msx son ficheros cas. Yo es que soy de spectrum...

zerobyzero escribió:EDITO:

1. Se conoce algún juego (de MSX, Spectrum u otro sistema) en el que los datos reales sean iguals y los meta-datos diferentes?

Nop, de los juegos publicados en formato tsx / tzx de momento no conozco ninguno que se haya molestado en hacer ese "truqui".

zerobyzero escribió:2. Entiendo la importancia entonces de preservar los meta-datos, pero sigo pensando que ciertos bloques como los de información tosec y demás deben ser omitidos del cálculo del hash puesto que no se encuentran físicamente en la cinta sino que son añadidos posteriores y totalmente ajenos.

uhmm, me sigue pareciendo que en estos mensajes estás pensando en ficheros cas o similares. Porque los metadatos no son para nada algo ajeno a las cintas, en absoluto. Como va a ser algo ajeno a una cinta las frecuencias y temporizaciones usadas en la misma !

Sí, si, lo entendí al leer de nuevo tu mensaje anterior mientras escribía la respuesta

Así que sólo habría que ignorar los datos "supérfluos" (la cabecera del tsx y los bloques de información) para tener un crc "puro".

PabloMarmol escribió:El que los datos sean (por ejemplo) "1111" no quiere decir que el msx vaya a cargar "1111" si le cambias los metadatos.
Esos mismos datos "1111" se podía cargarán en el msx como "0000" si le das el cambiazo a las frecuencias.

Entiendo lo que dices y es cierto en parte:
- Por un lado sería importante usar los bytes 0x0E (BitConf) y 0x0F (ByteConf) de la cabecera 4B para generar el Hash, ya que definen como se codifican los datos a nivel de bit y de byte.
- Por otro lado los word 0x04, 0x06, 0x08, 0x0A, 0x0C de la cabecera 4B son dependientes de la calidad del dumpeado de la cinta, de la velocidad del motor de cada reproductor de cassette, de si hay problemas en el arrastre de la cinta... y eso no debería ser contemplado en el Hash.

Pero como en la práctica va a ser tremendamente improbable (más bien imposible) que en dos cintas distintas tengas el mismo Data Hash, teniendo una un bloque en formato MSX y la otra los mismos bytes pero en formato Spectrum por ejemplo... podrán variar ligeramente en velocidad (baudios, por variabilidad en la duración de los pulsos) pero eso no se puede definir 100% ya que no sabemos a qué velocidad real se grabó en su día esa cinta.

Para no andar complicando la generación del Hash por eso mismo decidí prescindir de las cabeceras y usar solo los datos.

Os paso link de la definición del bloque 4B por si necesitais ver los offsets que nombro más arriba.

nataliapc escribió:Entiendo lo que dices y es cierto en parte:

- Por un lado sería importante usar los bytes 0x0E (BitConf) y 0x0F (ByteConf) de la cabecera 4B para generar el Hash, ya que definen como se codifican los datos a nivel de bit y de byte.

No es cierto en parte; es totalmente cierto (posible) encontrar cintas tsx con los mismos datos y distintos metadatos, aunque poco probable, si.

Para no andar complicando la generación del Hash por eso mismo decidí prescindir de las cabeceras y usar solo los datos.

Claro, es lógico que lo hagas así.
Pero lo de añadir al cálculo "parte de los metadatos" (0x0E y 0x0F) sería un parche para algo que no tiene remedio. El "data hash" vale para lo que vale, y está bien tal como está, el problema estaría en intentar usarlo para lo que no es (como forma de indentificar/catalogar cintas) ("Me parece a mi")

Si las cintas tsx no fueran "analógicas" sino datos binarios como las cintas cas (o las imágenes de cartuchos) si que tendría sentido usar un crc o hash de "solo los datos sin metadatos" para identificar las cintas.