diff options
Diffstat (limited to 'FAQ-cd.txt')
| -rw-r--r-- | FAQ-cd.txt | 27 |
1 files changed, 16 insertions, 11 deletions
@@ -21,7 +21,7 @@ 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. + free-software generates Nero ISO, it won't be supported. Q: What is this tool/library able to? @@ -42,8 +42,8 @@ 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 + 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) @@ -114,6 +114,8 @@ A: Firstly, when you have a raw sector, you have to understand its primary form. <-- 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 @@ -137,7 +139,7 @@ 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 + 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, @@ -183,8 +185,11 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} 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 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 @@ -197,8 +202,8 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} 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. + 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 @@ -219,7 +224,7 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} 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. + 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. @@ -235,8 +240,8 @@ int is_valid_BCD(uchar x) {return (((x & 15) < 10) && ((x >> 4) < 10));} 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. + 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, |