(12-27-2011, 06:37 PM)piccolo113 Wrote: I just got the game for christmas, played it for a little bit yesterday on my Wii. Today, I figured I'd give it a go on the emulator to see how amazing it looks.....and my DVD drive can't read the disc....or the emulator won't run it from the disc....or something.
Am I don't something wrong? Do I have to rip the files into an .iso to get the emulator to run it?
Quick Edit: For sure it's my DVD drive not seeing the disc. Lame.
The default driver can't read a Wii disc from your DVD drive. Here's an excerpt from the friidump readme which explains why:
Code:
In order to understand how a Gamecube or WII Optical Disk is made, let us
first take a look at a standard DVD-ROM. The complete standard is explained in
the ECMA-267 Standard.
The user data stored on the DVD is divided in blocks, each 2048 bytes long.
Each 2048-byte block is then encapsulated in a 2064-byte structure, adding some
other data needed for error-correction and head positioning. A 2064-byte block
is called a "Data frame", and its logical layout is as follows:
4bytes 2bytes 6bytes 2048bytes 4bytes
- - - - - - - - - - - - - - - - - - - - - - - - - -
| ID | IED | CPR_MAI | User Data Frame | EDC |
- - - - - - - - - - - - - - - - - - - - - - - - - -
- Identification Data (ID): Contains the PSN (Physical Sector Number), info
about the sector itself, like the layer, reflectivity, zone, etc.
- ID Error Detection Code (IED)
- Copyright Management Information (CPR_MAI): Its use is application-specific,
for instance it can be used to store a sector key in videos that use CSS, or
a scrambling key in the XBox and XBox360 Security Sectors.
- User Data: This is the data available for the end user.
- Error Detection Code (EDC): It is the checksum data for all the fields above,
its polinomial is x^32 + x^31 + x^4 + 1.
For various reasons (not related to copy protection), the User Data Frame is
XOR'ed with a stream cipher generated by an 15bits LFSR (Linear Feedback Shift
Register), with bits 10 and 14 used as taps. The seeds are obtained from a
table of the ECMA-267 standard, the index of the seed is the 4 MSB of the last
byte of the "ID" field of the Data Frame. The same stream cipher is then used
by 16 consecutive Data Frames: for this and other reasons (again related to
error correction), data from the DVD are always read in 16-data frame blocks.
4bytes 2bytes 6bytes 2048bytes 4bytes
- - - - - - - - - - - - - - - - - - - - - - - - - -
| ID | IED | CPR_MAI | User Data Frame | EDC |
- - - - - - - - - - - - - - - - - - - - - - - - - -
^ | 2048bytes cipher stream |
^ - - - - - - - - - -
Scrambling
seed index
Now, the first problem when dealing with Gamecube/Wii Optical Discs is that
they use a different (and yet unknown) set of seeds. This means that when an
ordinary DVD-ROM drive tries to read a GOD/WOD disc, it will unscramble the
User Data Frame with the wrong seed, causing the EDC check to fail and a read
error to be reported to the operating system, which means the inability to read
the disc.
Furthermore, Gamecube/Wii Optical Disks use a slightly different structure for
the Data Frame, as shown in the following figure:
4bytes 2bytes 2048bytes 6bytes 4bytes
- - - - - - - - - - - - - - - - - - - - - - - - - -
| ID | IED | User Data Frame | CPR_MAI | EDC |
- - - - - - - - - - - - - - - - - - - - - - - - - -
| 2048bytes cipher stream |
- - - - - - - - - -
Basically, the User Data Frame and the CPR_MAI fields are swapped, while the
scrambled bytes remain the same.
There's threads in this forum which explain how you can still read the disk; if you own a Wii it seems to be rather easy. Otherwise, you need a device supported by friidump / rawdump, which is about 6 euros at ebay.
Greetings