| Voir le sujet précédent :: Voir le sujet suivant |
| Auteur |
Message |
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
 Posté le: 02 Oct 2003 21:41 Sujet du message: Informations parasites sur l'image de CD PSX |
 |
|
Bien, aprés quelques menus recherches, j'ai pu créditer la théorie de la parité
Sur mon (seul et unique) CD PSX chez moi, la gravure est effectivement en mode 2.
Or d'aprés les sites consulté le mode 2 permet de gagner de la capacité sur les CD en éliminant des informations de correction d'erreur ( parité )
| Citation: | | Variante du mode 1 décrite elle aussi dans le Yellow Book, il ne contient pas de code de correction d'erreur. La taille de 2048 octets passe ainsi à 2336 octets. Les octets de ``sync'' et ``d'en-tête'' s'y trouvent toujours. Le mode 2 permet donc de stocker plus de données sur le disque tout en étant moins fiable puisqu'on ne peut pas détecter les erreurs. Toutefois, la fiabilité des lecteurs et des graveurs a augmenté au cours du temps, autorisant l'exploitation d'un tel mode. |
De ce fait, je conserve ma théorie selon laquelle ces octets parasites permettent au jeu de reconstituer des fragments de données illisibles dans scene.bin
Si vous pouviez me fournir un bout du fichier en m'indiquant les données I et X ( si possible au moins 2 blocs de chaque consécutif ) je pourrai éventuellement faire une recherche par rapport aux algorythmes de correction d'erreur connus.
Voili voilou
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
 |
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 863
Localisation: Versailles
|
| Posté le: 02 Oct 2003 23:55 Sujet du message: |
|
|
Je te l'ai déjà dit mais jolie découverte en tout cas ^^
J'ai modifié l'un de mes programmes pour qu'il fasse la chose suivante : il compare le fichier scene.bin non corrompu avec le fichier sceneiso.bin qui provient de la copie directe d'un morceau de l'image du CD, correspondant à scene.bin avec les "IIII" dedans.
Il compare donc ces deux fichiers et crée un fichier XXXXn.BIN (où n est incrémenté à chaque fois) lorsque les données sont identiques. Dès qu'une différence apparaît, il va créer un fichier IIIIn.BIN contenant les différences.
Bref on se retrouve avec de nombreux fichiers XXXX d'exactement 2Ko et d'aussi nombreux fichiers IIII d'exactement 304 octets.
Sont disponibles :
Les fichiers XXXX et IIII [TAR.BZ2]
Le programme avec le source et les deux fichiers SCENE.BIN et SCENEISO.BIN [TAR.BZ2]
Bon courage 
_________________
 |
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
| Posté le: 03 Oct 2003 12:46 Sujet du message: |
|
|
Merci Fremen, grace à ta précision des 304 octets je suis maintenant sûr qu'il s'agit des en-têtes et code de détection/correction d'erreur d'un bloc de données sur un CD Mode 1 ou Mode 2 Form 1
Pour une explication détaillé là dessus => ce site
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 863
Localisation: Versailles
|
| Posté le: 03 Oct 2003 13:05 Sujet du message: |
|
|
Et merci à toi
Effectivement ça correspond exactement. La question que je me pose maintenant, c'est est-ce que la PlayStation fait appel à ces données lorsque la lecture se déroule correctement ? Et quel est le taux de risque pour que la PlayStation y fasse appel ?
En tout cas le mieux serait encore de mettre à jour ces données, mais ça me paraît relativement complexe.  Tu comptes avancer là-dessus ou est-ce qu'on se contente pour le moment de faire des tests ? Car après tout, en abimant un peu un CD gravé, un émulateur aussi devrait prendre ça en compte.
(Note que jusqu'à maintenant, je chargeais l'ISO de PSX avec l'émulateur, pas un CD gravé).
_________________
|
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
| Posté le: 03 Oct 2003 13:09 Sujet du message: |
|
|
Je me doutais bien que tu chargeais l'iso psx
Pour le moment je vais concentrer mes recherches sur l'algorythme qui régit ces fameux codes d'erreur.
Je vous tiendrai au courant ^^
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 863
Localisation: Versailles
|
| Posté le: 03 Oct 2003 15:18 Sujet du message: |
|
|
Comme convenu, voici une version plus découpée de tes fichiers, suivant le format de la doc que tu as montrée.
Les fichiers sont organisés de cette façon, pour chaque bloc "n" :
n_SYNC.bin : bloc Sync précédant les données n_USERDATA
n_HEADER.bin : bloc Header précédant les données n_USERDATA
n_SUBHEADER.bin : bloc SubHeader précédent les données n_USERDATA
n_USERDATA.bin : le bloc n_USERDATA correspondant aux anciens XXXX
n_EDC.bin : bloc EDC qui suit n_USERDATA
n_ECC.bin : bloc ECC qui suit n_USERDATA
Sont disponibles :
Les fichiers "n_*" [TAR.BZ2]
Le programme avec le source et les deux fichiers SCENE.BIN et SCENEISO.BIN [TAR.BZ2]
_________________
|
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
| Posté le: 03 Oct 2003 16:08 Sujet du message: |
|
|
Wahouuuuuu !!!!
Merciiiiii fremen  ))))))
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
Fly^SF
Buttonizer des Shit Fliez
Inscrit le: 23 Mar 2003
Messages: 360
Localisation: Paris
|
| Posté le: 05 Oct 2003 12:15 Sujet du message: |
|
|
| Merci pour ton lien Speedy, je trouve ça très intéressant et je vais y jeter un oeil. |
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
| Posté le: 05 Oct 2003 16:04 Sujet du message: |
|
|
Voilà ce que j'ai expliqué à fremen :
Le mode 2 Form 1 est quasiment le même que le mode 1
La différence entre ces deux modes c'est qu'en mode 2 nous pouvons utiliser l'edc et l'ecc pour stocker nos propres données, c'est la technique utilisée pour créer des CDs XA
Donc lorsque fremen a fait une image du CD PSX, qui était en mode 2 ( apparement obligatoire pour PSX ) son logiciel a automatiquement récupéré toutes les données ne sachant pas faire la différence entre mode 2 Form 1 / mode 2 form 2 / mode 2 XA
Donc pour résoudre le probléme, il faudrait savoir comment les logiciels de gravure font pour graver un cd mode 1 ( EDC/ECC identique au mode 2 form 1 )
Donc si quelqu'un arrive à retrouver des sources d'un programme de gravure ( sous linux par exemple ) qui donneraient éventuellement les fonctions de calcul de l'EDC et de l'ECC qu'il n'hésite pas un seul instant ^^
Voili voilou
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
Crashsound
Inscrit le: 14 Mai 2003
Messages: 418
Localisation: Malintrat, à proximité de Clermont Ferrand
|
|
| Revenir en haut de page |
|
|
Fremen^SF
GDB des Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 863
Localisation: Versailles
|
| Posté le: 07 Oct 2003 5:01 Sujet du message: |
|
|
| Speedy^SF a écrit: | | La différence entre ces deux modes c'est qu'en mode 2 nous pouvons utiliser l'edc et l'ecc pour stocker nos propres données, c'est la technique utilisée pour créer des CDs XA |
Au fait, le temps que je me réveille, où veux-tu en venir précisemment ?
On sait que la version PlayStation de FF7 n'utilise pas l'EDC ni l'ECC pour stocker des données du jeu, et que les CD sont en Mode 2 Form 1. Donc pourquoi parles tu d'utiliser l'edc et l'ecc pour stocker nos propres données ?
C'est une question bête mais c'est pour être sûr d'avoir bien tout suivi
Sinon j'ai regardé un peu les sources de CDRecord et j'ai trouvé quelque chose qui devrait régler ton problème. Je t'explique déjà ce que j'ai compris, ensuite il te restera à te taper un readme (ma foi assez complexe, mais détaillé) et la relecture de quelques sources. Mais en tout cas il y a tout.
En fait, CDRecord a besoin de CDRTools pour fonctionner. Et ne trouvant rien dans les sources de CDRecord, je suis allé voir les sources de CDRTools. Et là, oh surprise ! Le fichier sector.c (situé dans le répertoire ./cdrecord/ des sources de CDRTools) sert à écrire un secteur de CD. Ou plutôt à générer le buffer correspondant. Et pour le calcul de l'EDC/ECC, il fait appel à libedc situé dans le répertoire ./libedc/. Libedc est documentée (le fameux readme s'y trouve), et évidemment tu y trouveras aussi les sources. Donc reste à relire sector.c et les sources de libedc, et tu pourras appliquer l'algo dont tu as besoin.
_________________
|
|
| Revenir en haut de page |
|
|
Speedy^SF
Shit Fliez
Inscrit le: 21 Mar 2003
Messages: 762
Localisation: Troyes
|
| Posté le: 07 Oct 2003 10:18 Sujet du message: |
|
|
| Fremen^SF a écrit: |
Au fait, le temps que je me réveille, où veux-tu en venir précisemment ?
On sait que la version PlayStation de FF7 n'utilise pas l'EDC ni l'ECC pour stocker des données du jeu, et que les CD sont en Mode 2 Form 1. Donc pourquoi parles tu d'utiliser l'edc et l'ecc pour stocker nos propres données ?
C'est une question bête mais c'est pour être sûr d'avoir bien tout suivi
|
Bah c'était juste pour vous dire à quoi ça peut servir
J'ai pas dit que ça nous servirai 
Et je parlais de l'utilité en général, par exemple sur un CD XA on peut stocker un fichier vidéo intégrant ses propres algorythmes EDC/ECC et donc profiter d'un support de prés de 900 Mo
Voili voilou
_________________
Speeeeeeddyyyyyyyyyyy !!!!!!
Personnal Website
Team Website |
|
| Revenir en haut de page |
|
|
|
Accueil
FAQ
Rechercher
Liste des Membres
Groupes d'utilisateurs
S'enregistrer
Profil
Se connecter pour vérifier ses messages privés
Connexion
