**pas à jour** Q: Mais c'est quoi le but de cet outil? R: Il est fait pour manipuler des images ISO que vous faites depuis des CDs. Q: Mais c'est quoi une image ISO? R: Vous pouvez faire une ISO avec des outils gratuits comme cdrdao en mode raw, ou d'autres, comme cdrwin, CloneCD, etc... Q: Est-ce que tous les formats de fichiers ISO sont supportés? R: Non. Seuls les images en mode raw-2352. C'est à dire le format de fichier produit par CloneCD et cdrwin, et par cdrdao avec l'option --read-raw. Q: Est-ce que le format de fichier de Nero est supporté? R: Non. Q: Pourquoi? Nero est un logiciel répendu! R: C'est un outil commercial. Je n'utilise pas d'outils commerciaux, et vu qu'aucun outil libre ne génère d'image ISO, il ne sera pas supporté. Q: Que peut faire cet outil/librairie? R: D'abord, vous pouvez lire et écrire des secteurs depuis et vers un fichier iso. Vous pouvez extraire et insérer des fichiers depuis et vers une image iso. Suivant le mode que vous utiliserez, il calculera le code CRC/ECC correct pour le secteur donné. Le tout dans les modes (éventuellement mélangés) MODE_1, MODE_2, MODE_2_FORM_1, MODE_2_FORM_2. De plus, il est capable de générer un fichier de patch (un fichier .ppf) au lieu de modifier l'image iso, ce qui vous économise du temps. Dans l'état actuel, il est très orienté vers les formats MODE_2*, vu que c'est ceux utilisés par la playstation. Q: J'ai entendu que CDmage ou ECCRegen peuvent me corriger les secteurs. R: Sans doute. Vu qu'ils tournent sous windows, je ne les ai pas essayé. Q: Mais, quel est le but de ce soft? R: De modifier (patcher) des images ISO. Rien de plus. Et bien sûr, je le veux libre, opensource, et marchant sur mon OS préféré, Linux. Si quelqu'un peut le faire marcher sous windows (je pense que c'est facile à faire) cela ne pourra que me faire plaisir. Je ne peux rien faire de mon coté, car je n'ai pas l'opportunité de créer des binaires Windows (sauf avec cygwin) Q: D'où vient le code source pour le CRC/ECC? R: Au départ, il vient de cdrdao. Yazoo y a fait quelques modifications. Ensuite, je n'ai nettoyé et fait quelques modifications de mon coté. Ce code source est appelé 'yazedc'. Q: T'avais le droit de le faire? R: Le software est sous license GPL. J'ai le droit d'en donner des versions modifiées, tant que je ne dis pas qu'il s'agit du logiciel original, ni que j'oublie de préciser les auteurs de départ à l'intérieur. Q: Quel nom étrange, 'yazedc' ? R: J'ai mes propres idées sur l'origine du nom. La plus simple: "YAZoo EDC" où EDC est le nom de l'un des champs qu'il recalcule. Mais il y a une solution un peu plus... compliquée que je ne donnerais pas. Q: Donc je peux modifier ton code aussi, faire un nouvel outil et le diffuser? R: Oui, tant que vous diffusez le code source aussi, que le nouveau soft est aussi sous license GPL, et que vous dites que je suis l'auteur de départ, vous pouvez. Lisez la GPL attentivement, c'est très intéressant. Q: Quel est le format exact d'un CD-Rom? R: D'abord quand vous avez un secteur, il faut comprendre sa forme primaire. Ensuite, le CD entier a un format interne, appelé iso9660. Le format iso9660 est facile à trouver sur le net. Voici un premier lien facile: http://www.ccs.neu.edu/home/bchafy/cdb/info/iso9660.txt Puis deux liens plus difficiles: http://www.ecma.ch/ecma1/stand/ecma-119.htm et http://www.ecma.ch/ecma1/stand/ecma-130.htm Tous ces liens viennent de la page http://www.ccs.neu.edu/home/bchafy/cdb/info/info.html Le format d'un secteur est un peu plus compliqué à trouver sur le net. Voici les information que j'ai pu réunir. D'abord, il faut savoir qu'il y a plein de formats différents qui décrivent l'organisation des secteurs. On appelle ça des books (livres). Il y a le Red Book, le Yellow Book, le Blue Book, le Green Book, l'Orange Book et le White Book. Le Red Book décrit les CD audio. Le Yellow est pour les CD-Rom normaux. Le Blue pour les VideoCD de Philips. Le Green pour les CD-i et CD-XA. L'Orange pour les CD-R. Et le White semble être un remplacement du Green. C'est relativement pas clair, et vous devez acheter les livres puisqu'ils ne font pas partie du domaine public. Ainsi, les informations que je vais donner proviennent de diverses sources de logiciels libres. Les deux principales sources sont cdrdao http://cdrdao.sf.net et ECCRegen http://web.tiscali.it/eccregen. Voici la forme général d'un secteur de CD-Rom: <-------------------------- secteur: 2352 bytes ------------------------------> <- Entête: 16 bytes -><-------------- Données: 2336 bytes --------------------> Passons à la description de l'entête: <--------------------------- entête: 16 bytes ------------------------------> <-- sync bytes: 12 bytes --><-- localisation: 3 bytes --><-- mode: 1 byte --> Les octets de synchro sont simples: c'est 00 FF FF FF FF FF FF FF FF FF FF 00 Ils sont supposés aider le lecteur CD à se synchroniser pour lire le secteur correctement. La localisation est la "positition" du secteur décrit en unités de temps. Par exemple, le secteur 200000 d'un CD est au "temps" 44:28:50. Le premier nombre correspond au nombre de minutes, le second au nombre de secondes, dans l'intervalle 0-59, et le dernier est le numéro de frame, dans l'intervalle 0-74. Cela signifie qu'il y a 75 frames dans une seconde pour un lecteur CD. Veuillez noter que le CD "commence" à 00:02:00. Ok, maintenant que l'on sait tout ça, on peut entrevoir comment la localisation est stockée. Mais c'est pas si facile... <-------------------- localisation: 3 bytes --------------------> <-- minute: 1 byte --><-- second: 1 byte --><-- frame: 1 byte --> On pourrait croire que c'est bon, *MAIS* en fait les octets sont stockés au format BCD. Peut-être que vous savez ce que c'est que le format BCD si vous êtes assez "vieux" pour ça. Je ne vais pas rentrer dans les détails donc cherchez sur le net pour une description plus précise du format BCD. Il vous suffit de savoir ça: typedef unsigned char uchar; uchar from_BCD(uchar x) {return ((x & 15) + ((x & 240) >> 4) * 10));} uchar to_BCD(uchar x) {return ((x / 10) << 4) | (x % 10));} int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} Dernière chose: quand vous regardez un nombre au format BCD, il faut le lire en hexa, et vous verrez un nombre "décimal". Donc quand vous allez compter en BCD, vous aurez ceci: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x10, 0x11, 0x12, etc... Vous voyez? Il y a un trou. Pas de 0x0a, 0x0b, 0x0c, etc... Ainsi, le BCD n'est qu'un truc pour une lecture facile de dumps hexa d'informations variées. Très bien. C'était pour la localisation. La dernière partie est l'octet de mode. Il est très simple en fait. C'est 0 pour un secteur vide, 1 pour un secteur en MODE1, et 2 pour un secteur en MODE2. Facile... Très bien: on connait la forme simple d'un secteur de CD, et même le MODE du secteur. Maintenant, les données dépendent du mode du secteur. Voici les différents types: <-------------- Secteur en MODE 1 FORM 1 : 2336 bytes -----------------------> <- datas: 2048 bytes -><- EDC: 4 bytes -><- 0s: 8 bytes -><- ECC: 276 bytes -> <-------- Secteurs en MODE 1 FORM 2 et aussi en MODE 2: 2336 bytes ----------> <----------------------------- datas: 2336 bytes ----------------------------> <-------------- Secteurs en MODE 2 FORM 1: 2336 bytes -----------------------> <- SH: 8 bytes -><- datas: 2048 bytes -><- EDC: 4 bytes -><- ECC: 276 bytes -> <-------------- Secteurs en MODE 2 FORM 2: 2336 bytes -----------------------> <- SH: 8 bytes -><---------- datas: 2324 bytes ----------><- vide: 4 bytes -> Bien, je ne sais *vraiment* pas comment distinguer les différentes "FORMS" les unes des autres pour le MODE 1. Il va falloir que je fouille un peu. L'ECC et l'EDC sont des blocs de contrôle. Le code yazedc peut les recalculer, donc vous n'avez pas besoin de vous en soucier. Le champ 'SH' (SubHeader) est le plus compliqué. Ces huits petits octets sont les seuls dont je ne suis pas vraiment sûr. Tout ça parce qu'il faut acheter les books pour avoir l'information. Ce SubHeader est seulement présent dans les secteurs en MODE_2_FORM_1 et MODE_2_FORM_2. Voici les infos que j'ai pu réunir: -) Le SubHeader a 8 octets, mais c'est deux fois les mêmes 4 octets. -) Les 4 octets sont décrits suivant les champs suivants: -) The SubHeader has 8 bytes, but it's twice the same 4 bytes. -) The 4 bytes are described using the following fields: o) 1er octet: File Number (FN) o) 2ème octet: Channel Number (CN) o) 3ème octet: Sub Mode (SM) o) 4ème octet: Coding Info (CI) -) Le SubHeader semble très important pour les fichiers STR, vu que c'est le seul moyen de distinguer un secteur vidéo d'un secteur audio. Mais il semblerait qu'il n'ont pas trop d'importance pour le format iso9660. Mais mieux vaut les patcher si nécessaire... -) L'octet Sub Mode est un champ de bits qui semble être décrit comme suit: 0: End of Record (EOR) 1: Video 2: Audio 3: Data 4: Trigger 5: Form 2 6: Real Time (RT) 7: End of File (EOF) Bien sûr, la PSX a les CDs en MODE2... donc les fichiers normaux sont stockés en MODE 2 FORM 1, et les fichiers STR/XA en "MODE 2", mais en fait il sont en MODE 2 FORM 1 et 2. L'outil MOVCONV va en fait produire des fichiers qui contiennent des subheaders. Ces subheaders varient souvent, et semblent être important pour le traitement de flux. Veuillez noter que les secteurs vidéo des "str" sont considérés comme des secteurs de données et non comme des secteurs vidéo. L'octet CN indique le numéro du channel du secteur en cours. Le format XA peut contenir des channels entrelacés. Par exemple, si vous avez un fichier qui contient 8 channels, vous aurez d'abord le premier secteur du channel 0, puis le premier secteur du channel 1, etc... Cela devient un peu compliqué lorsque l'on sait que la vidéo est aussi entrelacée et considérée comme un channel elle-même. L'entrelacement le plus courant est 7 secteurs vidéos pour 1 secteur audio, mais cela peut varier. Et tous les channels peuvent être indépendants. Par exemple vous pouvez avoir une vidéo sans son qui contient en fait un channel audio, et ce channel audio pourra être utilisé pour une autre partie du jeu. C'est pour optimiser le processus de lecture. Vu que le lecteur CD est un x2, il *DOIT* lire les données à 300Ko/s. Donc si vous avez une vidéo sans son, le processur de lecture sera plus rapide que le processus de décodage, et tout devrait foirer. C'est la même chose pour les secteurs audios. L'option "leap sector" de MOVCONV ajoute des secteurs vides afin de compléter les channels qui se seraient arrêtés avant les autres. Une "vitesse" du lecteur CD correspond à 4 fois la vitesse de lecture d'un channel audio stéréo à 37800Hz. Donc à vitesse x2 vous pouvez avoir huit channels stéréo à 37800Hz. Ou 32 channels audio mono à 18900Hz. La majorité des vidéos str nécessitent 7/8 de la vitesse maximum du lecteur CD. "Majorité" signifie des vidéos en 320x224 à 15 fps. Donc vous pouvez avoir une vidéo en 320x224x15fps avec un track audio stéréo à 37800Hz. Donc peut-être que maintenant vous comprenez pourquoi l'entrelacement normal peut varier. L'octet CI contient des drapeaux à propos du secteur en cours, mais je suis incapable d'en donner une description complète. Je sais juste celà: pour les secteurs audio XA, le bit 0 est mis si vous avez du son stéréo, et le bit 2 est mis si vous avez une "moitié de fréquence", c'est à dire 18900Hz au lieu de 37800Hz. Les secteurs Video sont en Form 1, et les secteurs Audio en Form 2. Mais il _semblerait_ que les secteurs Video n'ont pas de partie ECC/EDC, et sont remplis avec des zéros à la place. Dernière chose: les MODE 2 FORM 1 et MODE 2 FORM 2 sont aussi appelés XA-Mode1 et XA-Mode2, ou plus simple: XA-1 et XA-2. J'espère que cela vous a aidé autant que moi pour écrire ce software.