diff options
Diffstat (limited to 'FAQ-cd.txt')
| -rw-r--r-- | FAQ-cd.txt | 51 |
1 files changed, 43 insertions, 8 deletions
@@ -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. |