La Place des Développeurs CHECKSUM ERROR quésaco ?
le checksum est un calcul qui permet de vérifier si un fichier est le bon
exemple : on additionne tous les octets d'une rom pour en extraire le chechsum
maintenant il faut savoir avec quel logiciel et a quel moment tu obtiens ce message
exemple : on additionne tous les octets d'une rom pour en extraire le chechsum
maintenant il faut savoir avec quel logiciel et a quel moment tu obtiens ce message
Visiteur
Vagabond
Message : 0
Merci, vos réponses confirment ce que je pensais 
Bien que ne sachant pas exactement ce qu'étais le checksum, je me doutais qu'il s'agissait d'un problème lié à la longueur d'un fichier et donc d'octet(s)...
En fait, depuis quelques temps je convertis des fichiers .CAS en .WAV avec plus ou moins de réussite (près de 70% sont Ok).
Pour les 30% qui ne fonctionnent pas, dans la plupart des cas j'ai le message "Checksum Error" qui s'affiche à un moment ou à un autre du chargement. Je ne suis pas sûr de pouvoir corriger ce bug car c'est probablement lors de la conversion qu'une imperfection audio se glisse dans le fichier .WAV
Cette imperfection doit, à la lecture des données, être interprétée comme une erreur dans la longueur du fichier 
Bien que ne sachant pas exactement ce qu'étais le checksum, je me doutais qu'il s'agissait d'un problème lié à la longueur d'un fichier et donc d'octet(s)...
En fait, depuis quelques temps je convertis des fichiers .CAS en .WAV avec plus ou moins de réussite (près de 70% sont Ok).
Pour les 30% qui ne fonctionnent pas, dans la plupart des cas j'ai le message "Checksum Error" qui s'affiche à un moment ou à un autre du chargement. Je ne suis pas sûr de pouvoir corriger ce bug car c'est probablement lors de la conversion qu'une imperfection audio se glisse dans le fichier .WAV
Cette imperfection doit, à la lecture des données, être interprétée comme une erreur dans la longueur du fichier
as-tu véfifier les fichiers .WAV en défaut avec openMSX?
Edité par
Visiteur
Le 16/12/2012 à 22h34
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
Visiteur
Vagabond
Message : 0
Sector28 :
as-tu véfifier les fichiers .WAV en défaut avec openMSX?
Au risque de surprendre un récent démissionnaire qui, en son temps, avait très mal pris mon humour... je suis comme lui, je n'utilise pas d'émulateur, que du MSX.
Je concède quand même quelques tests avec BlueMSX, mais je ne suis pas très à l'aise avec ces bêtes là.
J'ai réussi une bonne quarantaine de conversions
Toutefois, selon le matériel de lecture utilisé, un jeu pourra fonctionner dans un cas mais pas dans l'autre
J'ai testé tous mes fichiers sur un VG8020 (MSX1) et un NMS8280 (MSX2) avec des lecteurs portables (2 CD et 1 DVD) : tantôt un fichier fonctionnera sur les trois, tantôt sur deux, sur un, sur aucun...
Bref, c'est toujours un surprise et en 1200 bauds, ça se mérite
La quarantaine de fichiers que je considère réussis, sont ceux qui ont passé le test sur mes trois lecteurs avec ces deux MSX. Pour un Batman par exemple, ça représente 6 fois 14min08s de chargement
Pour éviter de tout charger et de s’apercevoir que le programme n'est pas bon, je suppose que des checksums (une valeur) sont stocké à intervalle régulier dans le fichier ; on lit le checksum depuis le média, puis on calcule manuellement le checksum avec la section de datas déjà chargé. Si les valeurs sont identiques, on considère que le chargement se déroule bien et on continue (sinon on affiche l'erreur que tu as).
Je ne sais pas comment sont calculé les checksum pour le lecteur de cassette MSX, mais une méthode courante est d'additionner des octets à intervalle régulier sur la portion de data chargé et de l'accumuler dans une variable (le check sum).
Donc, a priori, quand tu as cette erreur, c'est qu'une partie du fichier a été corrompue.
Je ne sais pas comment sont calculé les checksum pour le lecteur de cassette MSX, mais une méthode courante est d'additionner des octets à intervalle régulier sur la portion de data chargé et de l'accumuler dans une variable (le check sum).
Donc, a priori, quand tu as cette erreur, c'est qu'une partie du fichier a été corrompue.
On est toujours ignorant avant de savoir.
Le "checksum" n'est pas lié à la longueur du fichier mais bien à son intégrité.
Il s'agit d'une valeur, stockée quelque part (début ou fin de fichier, ça dépend) et qui est, à la fin du chargement, comparée avec une somme réalisée sur l'ensemble des octets du fichier. Les règles peuvent varier, mais c'est le principe général. En conséquence, lorsque le checksum n'est pas correct, c'est que le fichier est corrompu.
EDIT : Oups ... Je viens de voir que aoineko vient d'expliquer exactement la même chose. Désolé
Edité par
Metalion
Le 18/12/2012 à 09h36
Il s'agit d'une valeur, stockée quelque part (début ou fin de fichier, ça dépend) et qui est, à la fin du chargement, comparée avec une somme réalisée sur l'ensemble des octets du fichier. Les règles peuvent varier, mais c'est le principe général. En conséquence, lorsque le checksum n'est pas correct, c'est que le fichier est corrompu.
EDIT : Oups ... Je viens de voir que aoineko vient d'expliquer exactement la même chose. Désolé
Edité par
Metalion
Le 18/12/2012 à 09h36
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Visiteur
Vagabond
Message : 0
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie