1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
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)
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" but actually they are in MODE 2 FORM 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.
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.
|
