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 suppored. 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 preffered operating system, Linux. If somebody can make it working for windows (and I think this is easy to do) I will 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 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 thing: 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) -) I've *never* seen any SubHeader for a sector containing data with a FN, CN or CI different from 0, please inform me if you do. -) 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/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 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. I hope this will help you as it helped me writing this software.