Daily commit.

1 files changed, 0 insertions, 203 deletions

diff --git a/FAQ.cd b/FAQ.cd
deleted file mode 100644
index 4a3a92b..0000000
--- a/FAQ.cd
+++ /dev/null
@@ -1,203 +0,0 @@
-
-
-
-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:
-   
-unsigned char from_BCD(unsigned char x) {return ((x & 15) + (x & 240) * 10));}
-unsigned char to_BCD(unsigned char x) {return ((x / 10) << 4) | (x % 10));}
-int is_valid_BCD(unsigned char 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 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)
-
-   Very last things to know: 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 and I've never seen any file stored in MODE 2 FORM 2. And 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.