summaryrefslogtreecommitdiff
path: root/FAQ-cd-fr.txt
blob: 3a5327e9ab1ce0b6b20c1503dd53953e30ff6aa7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
**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.