Pfiou, huge work...

1 files changed, 43 insertions, 8 deletions

diff --git a/FAQ-cd.txt b/FAQ-cd.txt
index 8259372..e3b630e 100644
--- a/FAQ-cd.txt
+++ b/FAQ-cd.txt
@@ -194,18 +194,53 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));}
        5: Form 2
        6: Real Time (RT)
        7: End of File (EOF)
-   but it seems it's not very accurate, as you will se below.
 
    Of course, the PSX has the CDs in MODE 2... So the common files are
    stored in MODE 2 FORM 1, the STR/XA files are stored in "MODE 2" but
    actually they are in MODE 2 FORM 1/2. The MOVCONV tool will in fact produce
-   files that does contain the subheaders. And those subheaders seems to
-   contain a CN equals to 1, and the flags RT and Data are activated for the
-   video frames, and FN, CN, and CI equal to 1, and the flags are placed
-   as it: RT, Form 2, Audio for Audio streams. So the Video frames are in
-   plain Form 1, and the Audio frames are in plain Form 2. But it _seems_ the
-   Video frames are not checked against ECC/EDC, but filled with zeros
-   instead.
+   files that does contain the subheaders.
+   
+   Those subheaders are very likely to vary, and seems to be very important for
+   stream processing. Please note that "str" video sectors are considered as
+   data sectors, and not as video sectors.
+   
+   The CN byte indicates the channel number of the current sector. The XA
+   format may contain interlaced channels. So for example, if you have a
+   file that does contain 8 channels, you will have first the first sector
+   of the channel 0, then the first sector of the channel 1, etc...
+   
+   This is also a bit more difficult when you know that video is also
+   interlaced and considered as a channel itself. The common interlacement
+   is 7 video sectors for 1 audio sector, but this may vary. And all the
+   channels may be completely independants. For example, you may have a
+   sound-free video that does contain an audio channel, this audio channel
+   may be used for another part in the game.
+   
+   This is to optimize the reading process. Since the cd reader is a 2x cd
+   reader, it *HAS* to read data in full 300KBps. So, if you have a sound
+   free video, the reading process will be faster than the decoding process,
+   and everything will crash. This is about the same for the audio sectors. 
+   The 'leap' sector function of MOVCONV does add blank sectors in order to
+   pad the channels that may have stopped before the others. 
+   
+   One "speed" of the CD reader corresponds to four time the playback speed
+   of a stereo audio channel at 37800Hz. So at full speed you can have eight
+   stereo audio channels at 37800Hz. Or you can have 32 mono audio channels
+   at 18900Hz.
+   
+   Common video str files needs 7/8 of the full speed of the CD reader.
+   "Common" means 320x224 videos at 15fps. So you can have a full movie
+   in 320x224x15fps with a stereo sound track at 37800hz. So, now, you
+   may understand why the common interlacement may vary.
+   
+   The CI byte does contains some flags about the current sector, but I'm
+   yet unable to give a full description of them. I've only got this: for
+   audio frames, the bit 0 is set when you have stereo sound, and the bit 2
+   is set when you have "half frequency", ie 18900Hz instead of 37800Hz.
+   
+   The Video frames are in plain Form 1, and the Audio frames are in plain
+   Form 2. But it _seems_ the Video frames are not checked against ECC/EDC,
+   and filled with zeros instead.
    
    The last but not the least: the MODE 2 FORM 1 and MODE 2 FORM 2 are also
    called XA-Mode1 and XA-Mode2 or simplier: XA-1 and XA-2.