path: root/FAQ-cd.txt

Q: What is this tools aimed at anyway?
A: It is designed to handle ISO images you make from CDs.


Q: What is an ISO image anyway?
A: You can create an ISO with free tools like cdrdao in raw mode, or others,
   like cdrwin, CloneCD, etc...


Q: Are all the ISO formats handled?
A: No. Only raw-2532 images files. Always the file format outputted by CloneCD
   and cdrwin, and the format outputted by cdrdao with the --read-raw option.


Q: Is Nero's file format supported?
A: No.


Q: Why? Nero's a spreaded software!
A: It's a commercial tool. Since I don't use any commercial tool, and that no
   free-software generates Nero ISO, it won't be supported.


Q: What is this tool/library able to?
A: First, you can read/write sectors from/to an iso file. You can also read
   informations about an iso file. You can extract/insert files from/to
   an iso file. Depending upon the mode you'll be using, it will compute
   the right CRC/ECC code for the given sector. The whole in the following
   (eventually mixed) modes: MODE_1, MODE_2, MODE_2_FORM_1, MODE_2_FORM_2.
   Additionnaly, it is able to produce patches (.ppf files) instead modifying
   the iso file, saving you time when you use the right softwares.
   Actually, it is quite "oriented" on the MODE_2* formats, since it's
   the PSX's formats.


Q: I've heard CDmage or ECCRegen can also correct the sectors for me.
A: Maybe. Since it only runs on Win32 platforms, I've never tried it.


Q: So, what is the goal of this software?
A: To modify (patch) ISO images. Nothing else. And of course I want it free,
   opensource, and working on my prefered operating system, Linux. If somebody
   can make it working for windows (and I think this is easy to do) it would
   please me. I can't do it right now since I don't really have the opportunity
   to build Win32 binaries (apart of cygwin's ones)


Q: Where does the source code for the CRC/ECC comes from?
A: Originally, it has been taken from cdrdao. Yazoo has given some
   modifications to it. Then I've cleaned it up and made some minor
   modifications on my self. The source code was called 'yazedc'.


Q: Do you have the right to do so?
A: The software is GPL'ed. I've got the right to give modified versions
   of it, as long as I don't claim the modificated thing it the original,
   and as long as I mantion the original authors in it.


Q: What a strange name, 'yazedc' ?
A: I've got my own ideas about the name's origin... The easy solution:
   "YAZoo EDC", where EDC is the field name of one of the things it will
   recompute. But there is a more... complicated solution I won't give.


Q: So, I can modify your code too, create a new tool, and diffuse it?
A: Yes, as long as you give the full source code, that the new software
   is also GPL'ed, and that you mantion me as the original writer of the
   software, you can. Read the GPL carefully, it's very interesting.


Q: What is exactly the format of a CD-Rom?
A: Firstly, when you have a raw sector, you have to understand its primary form.
   Secondly, the whole CD has an internal format, called the iso9660. The format
   of the iso9660 is easy to find on the internet. Here is one first easy link:
       http://www.ccs.neu.edu/home/bchafy/cdb/info/iso9660.txt
   Then you have two more difficult documents:
       http://www.ecma.ch/ecma1/stand/ecma-119.htm
   and
       http://www.ecma.ch/ecma1/stand/ecma-130.htm
   
   All those links were taken from the page
       http://www.ccs.neu.edu/home/bchafy/cdb/info/info.html

   The sector format is a bit complicated to find on the internet. Here is what
   I've found.
   
   First you have to know that there is many formats that describe the sector's
   organisation. Those are called "Books". There is the Red Book, the Yellow
   Book, the Blue Book, the Green Book, the Orange Book, and the White Book.

   The Red Book is for Audio CD. The Yellow for common CD-Roms. The Blue book
   for Philips's VideoCD. The Green Book for CD-i and CD-XA. The Orange Book
   for CD-R cds. And the White Book seems to be a replacement of the Green one.
   
   This is quite unclear and you have to actually buy the books since they
   aren't in public domain.
   
   So the informations I'll give comes from various source of various free
   softwares. Should I mention two: cdrdao http://cdrdao.sourceforge.net
   and ECCRegen http://web.tiscali.it/eccregen as the most useful sources.

   Here is the general form of a CD-Rom sector:
   
 <--------------------------- sector: 2352 bytes ------------------------------>
 <- Header: 16 bytes -><---------------- Datas: 2336 bytes -------------------->

   Let's move to the header description:
   
 <--------------------------- header: 16 bytes ------------------------------>
 <-- sync bytes: 12 bytes --><-- localisation: 3 bytes --><-- mode: 1 byte -->

   The sync bytes are easy: it is always 00 FF FF FF FF FF FF FF FF FF FF 00
   They are supposed to help the CD reader to synchronize enough to be able to
   read the sector correctly.

   The localisation is the sector "position" described in time. For example,
   the sector 200000 of a CD is at the "time" 44:28:50. The first is the number
   of minutes, the second is the number of seconds, in the range 0-59 and the
   last is the frame number, in the range 0-74. It means there is 75 frames
   into a second for a CD player. Please note that the CD "begins" at 00:02:00.
   
   Ok now that we know all this, you can feel the way the localisation is
   stored. But it is not that easy...
   
 <-------------------- localisation: 3 bytes -------------------->
 <-- minute: 1 byte --><-- second: 1 byte --><-- frame: 1 byte -->

   That's seems to be all right *BUT* the fact is that the bytes are stored
   in packed BCD format. You may know what the BCD format is if you are "old"
   enough for that. I won't enter into the details so if you want a more
   description of the BCD format, look into the net. You only have to know that:

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));}

   Last hint: when you look at a BCD packed number, you have to read it in
   hexadecimal, and then you will see a "decimal" number. So when you count
   in BCD, you'll have this: 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
   0x08, 0x09, 0x10, 0x11, 0x12, etc... You see? You've got a "gap": no 0x0a,
   0x0b, 0x0c, etc... So the BCD is only a trick for an easy reading of hexa
   dumps of various informations.

   All right. This was for the localisation part. The last part is the mode
   byte. It is really simple actually. It is 0 for an empty sector, 1 for a
   sector in MODE1, and 2 for a sector in MODE2. Easy as hell.
   
   Ok here we are: we know the basic form of a CD's sector, and even know the
   MODE of the sector. Now the datas depends upon the sector mode. Here you have
   the various kinds:
   
 <-------------- MODE 1 FORM 1 Sector datas: 2336 bytes ---------------------->
 <- datas: 2048 bytes -><- EDC: 4 bytes -><- 0s: 8 bytes -><- ECC: 276 bytes ->
 
 <---------- MODE 1 FORM 2 and also MODE 2 Sector datas: 2336 bytes ---------->
 <----------------------------- datas: 2336 bytes ---------------------------->

 <-------------- MODE 2 FORM 1 Sector datas: 2336 bytes ---------------------->
 <- SH: 8 bytes -><- datas: 2048 bytes -><- EDC: 4 bytes -><- ECC: 276 bytes ->

 <-------------- MODE 2 FORM 2 Sector datas: 2336 bytes ---------------------->
 <- SH: 8 bytes -><---------- datas: 2324 bytes ----------><- spare: 4 bytes ->

   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
   don't worry about them.
   
   The 'SH' (SubHeader) field is the most "complicated" one. Those eight little
   bits are the only one I'm really not sure of. All of that because you have to
   buy the Books to find the information. This SubHeader is only found into
   MODE_2_FORM_1 and MODE_2_FORM_2 sectors.
   
   Here you have the informations I've been able to gather:
   
   -) The SubHeader has 8 bytes, but it's twice the same 4 bytes.
   -) The 4 bytes are described using the following fields:
     o) 1st byte: File Number (FN)
     o) 2nd byte: Channel Number (CN)
     o) 3rd byte: Sub Mode (SM)
     o) 4st byte: Coding Info (CI)
   -) The SubHeaders seems to be very important when dealing with STR files,
      since it's the only way to distinguish a video sector from an audio
      sector. But it seems that it doesn't matter when dealing with normal
      files. It might be obvious since the iso9660 format doesn't care about
      those bits. But better try to patch them if necessary...
   -) The Sub Mode byte is a bit field which seems to be described like this:
       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)

   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 and 2. The MOVCONV tool will in fact
   produce 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 should 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
   XA audio sectors, 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.

   I hope this will help you as it helped me writing this software.