Bleh

3 files changed, 282 insertions, 7 deletions

diff --git a/FAQ-cd-fr.txt b/FAQ-cd-fr.txt
new file mode 100644
index 0000000..a4844f1
--- /dev/null
+++ b/FAQ-cd-fr.txt
@@ -0,0 +1,258 @@
+
+
+
+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.
diff --git a/FAQ-cd.txt b/FAQ-cd.txt
index f0d81ad..4995a3a 100644
--- a/FAQ-cd.txt
+++ b/FAQ-cd.txt
@@ -1,7 +1,7 @@
 
 
 
-Q: What is this tools aimed at anyway?
+Q: What is this tool aimed at anyway?
 A: It is designed to handle ISO images you make from CDs.
 
 
@@ -169,7 +169,7 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));}
    Well, I *really* don't know how to distinguish the different "FORMS" from
    each others for the MODE 1. Have to look further for this.
    
-   The ECC and EDC controls blocks. The yazedc code can compute them, so
+   The ECC and EDC are controls blocks. The yazedc code can compute them, so
    don't worry about them.
    
    The 'SH' (SubHeader) field is the most "complicated" one. Those eight little
diff --git a/str-player.cpp b/str-player.cpp
index 7d9f47b..b20b795 100644
--- a/str-player.cpp
+++ b/str-player.cpp
@@ -2,6 +2,7 @@
 #include <string.h>
 #include <SDL/SDL.h>
 #include <SDL/SDL_audio.h>
+#include <getopt.h>
 #include "Input.h"
 #include "psxdev/bs.h"
 #include "generic.h"
@@ -44,6 +45,8 @@ struct STR_Header {
 
 Byte * video = 0, * audio = 0, * audio2 = 0;
 
+int channel = -1;
+
 int width, height;
 
 SDL_Surface * screen = 0;
@@ -77,6 +80,9 @@ void process_one_sector(Handle * f) {
     printm(M_BARE, "SubHeader SM : %x\n", sector[2]);
     printm(M_BARE, "SubHeader CI : %x\n", sector[3]);
 */
+    if ((channel != -1) && (channel != sector[1]))
+	return;
+    
     if ((sector[2] == 0x48) || (sector[2] == 0x42)) {
 //	printm(M_BARE, "Video sector\n");
 /*	printm(M_BARE, "Status       : %04x\n", h->StSTATUS);
@@ -185,6 +191,7 @@ void process_one_sector(Handle * f) {
 
 int main(int argc, char ** argv) {
     Handle * file = 0;
+    int c;
 
     if (SDL_Init(SDL_INIT_VIDEO | SDL_INIT_AUDIO | SDL_INIT_TIMER) < 0) {
 	printm(M_ERROR, "Couldn't initialise SDL: %s\n", SDL_GetError());
@@ -193,13 +200,23 @@ int main(int argc, char ** argv) {
     atexit(SDL_Quit);
     SDL_ShowCursor(SDL_DISABLE);
 
-
-    switch (argc) {
-    case 1:
+    while ((c = getopt(argc, argv, "c:")) != EOF) {
+	switch (c) {
+	case 'c':
+	    channel = atoi(optarg);
+	    break;
+	default:
+	    printm(M_ERROR, "Unknow argument.\n");
+	    break;
+	}
+    }
+    
+    switch (argc - optind) {
+    case 0:
 	file = &Stdin;
 	break;
-    case 2:
-	file = new Input(argv[1]);
+    case 1:
+	file = new Input(argv[optind]);
 	break;
     default:
 	printm(M_ERROR, "Too much arguments.\n");