cnelson/friidump
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge 6419d609eb into d9461a9401

Browse source
This commit is contained in:
LjMario007 2018-08-26 23:43:48 +00:00 • committed by GitHub
commit 53835530c7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
12 changed files with 259 additions and 352 deletions
Download patch file Download diff file Expand all files Collapse all files

187
README
View file

@ -1,187 +0,0 @@
FriiDump - A program to dump Nintendo Wii and GameCube disc
===============================================================================
FriiDump is a program that lets you dump Nintendo Wii and GameCube disc from
your computer, without using original Nintendo hardware. It basically performs
the same functions as the famous "RawDump" program, but with a big difference,
which should be clear straight from its name: FriiDump is free software, where
"free" is to be intended both as in "free speech" and in "free beer". As such,
FriiDump is distributed with its sources.
This leads to a number of good consequences:
- Having the sources available, it can be easily ported to different operating
systems and hardware platforms. At the moment it is developed under a
GNU/Linux system, but it also runs natively on Windows. A MacOS X version can
be easily created, although I don't have a Mac, so I can't do it myself.
- Also, having the sources and these being well-organized (I know I'm a modest
guy) allows support for new DVD-ROM drives to be added relatively easily. At
the moment the same drives as RawDump are supported, but this might improve
in the future, if anyone takes the effort... See README.technical for
details.
- The sources might also be used as a reference for several things regarding
Nintendo Wii/GameCube discs and the hacks used to read them on an ordinary
drive.
Furthermore, FriiDump also features some functional improvements over RawDump:
- FriiDump can use 4 different methods to read the disc, with different
performance.
- FriiDump dumps a lot of useful information about the discs it dumps,
such as whether the disc contains an update or not, which can help avoid
bricking your Wii ;).
- FriiDump calculates the CRC32, MD4, MD5, SHA-1 and ED2K hashes of dumped
discs, so you can immediately know if your dump is good or not, by comparing
the hashes with the well-known ones available on several Internet sites.
- FriiDump comes in the form of a library and a command-line front-end, which
allows its functions to be easily reused in other programs.
Unfortunately, there is also a main downfall:
- Even the fastest dump method used by FriiDump is not as fast as RawDump (but
not that much slower, either, see the table below).
Anyway, I'm sure that people who cannot use RawDump (i.e.: GNU/Linux, *BSD and
MacOS X users) will be happy anyway. Besides, you get the sources, so you can
improve them yourself.
Note that FriiDump is only useful to dump *original* Nintendo discs. To dump
backup copies you can use any DVD-dumping program (i.e.: dd under UNIX ;)).
FriiDump came to existance thanks to the work by a lot of people, most of which
are probably not aware of this fact ;). Please see the AUTHORS file for the
credits.
===============================================================================
Supported drives
===============================================================================
At the moment the same drives as RawDump are supported. This is due to various
reasons, explained in the README.technical file, which also contains
information about what is needed to add support for more drives.
Currently supported drives are:
- LG GDR-8161B (untested, but should work)
- LG GDR-8162B (ditto)
- LG GDR-8163B (HL-DT-ST/DVD-ROM GDR8163B)
- LG GDR-8164B (HL-DT-ST/DVD-ROM GDR8164B)
Other drives might work, most likely those based on the Hitachi MN103
microcontroller. If you find any of them, please report so that they can be
added to the compatibility list.
===============================================================================
Installation
===============================================================================
If you are a Windows user, probably you will have downloaded the binaries,
either zipped or together with an installer, so the installation should be
straightforward.
If you downloaded the sources, you will need to compile them. FriiDump uses
CMake, for easy portability, so you will need to get it from cmake.org. On
Windows you will also need a compiler like Visual Studio (the only tested one,
so far) or CygWin/MinGW. On UNIX just do the following, from the directory
where you unpacked the sources into:
$ mkdir BUILD
$ cd BUILD
$ cmake ..
$ make
$ make install
Linux-specific note: You need root privileges to issue certain commands to the
DVD-ROM drive. Hence you have the following possibilities:
- Run FriiDump as root: discouraged.
- Run it through sudo: better but nevertheless discouraged.
- Set the setuid bit on the executable: this is the recommended way to run
FriiDump under Linux. This way, the code run with superuser privileges will
be reduced to a minimum, guaranteeing a certain level of security (note that
security-related bugs might exist anyway!!!). Also note that, even when the
setuid bit is set, the attempt to open the drive for reading will be done
after privileges have been dropped, so you will need explicit read access to
the DVD-ROM drive. Usually having the system administrator add you to the
"cdrom" group is enough. To set the setuid bit on the executable, run as
root:
$ chown root:root /usr/local/bin/friidump
$ chmod u+s /usr/local/bin/friidump
===============================================================================
Usage
===============================================================================
FriiDump is a command-line program, so you will need to run it from a terminal
or a command-prompt under Windows. The basic usage is as follows:
friidump -d <drive> -a
where <drive> will usually be something like "/dev/hda" on Unix-like systems,
and something like "e:" for Windows users. With this command, the disc will be
dumped to an ISO image file with an automatically-chosen name. Drop -a and use
the -i option if you prefer to specify the filename yourself. If you want to
resume an existing dump, use -s. If you want to dump the disc to a raw format
image file, use -r. Note that you can create a raw and an ISO image at the same
time.
Other options you might want to use are -1 through -4, to set the dump method,
although the default is method 4, which is the fastest one, so most likely you
will not need them.
Finally, use -h for a listing of all available options.
===============================================================================
Performance
===============================================================================
As stated above, FriiDump is not as fast as RawDump. On my PC (Athlon64 3200+),
performance is as follows:
-------------------------------------------------------------------------------
| Method | Dump speed | GameCube disc dump time | Wii disc dump time |
-------------------------------------------------------------------------------
| 1 | Too slow ;) | Eternity | More than eternity |
| 2 | ~570 MB/h | 2.5 hours | 8 hours |
| 3 | ~740 MB/h | 2 hours | 6 hours |
| 4 | ~1250 MB/h | 1.2 hours | 3.5 hours |
-------------------------------------------------------------------------------
===============================================================================
Support
===============================================================================
I'm releasing this program under the nickname of "Arep". This is because I am
not sure about the legal status of the program, and I do not want to encounter
any consequences. Actually, I'm pretty sure FriiDump goes against the DMCA,
being a program that circumvents copy-protection, but it might be objected that
the format used by Nintendo discs is not a copy-protection method, but just
their own, undocumented, disc format. Although, I think it can be freely used
in Europe and other coutries without laws similar to the DMCA.
For the same reason, I am not putting an e-mail address here (that @no.net you
find in the program is obviously a pun), but support will be provided through
the forums of the Italian ConsoleTribe forum, at http://wii.console-tribe.com.
If you need help, just open a thread in any section there, even in English: I
will *not* reply, but you might stand assured I will read everything you write.
FriiDump users are encouraged to help each other there ;).
Patches are welcome, too: just attach them to your post, and maybe put
something like "[PATCH]" in the topic subject, so that I can easily spot them.
New releases will be announced on that forum, and also on QJ.net, if I find a
good way to notify them.
If you want to donate to the project, do not do it, and donate to one of the
free Wii modchip projects out there, such as OpenWii, WiiFree or YAOSM.
===============================================================================
Disclaimer
===============================================================================
FriiDump is distributed under the GNU General Public License version 2. See the
COPYING file for details.
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Also, please note that this program is not meant to be used to spread game
piracy, but rather to be instrument to make backups of your own precious
legally-bought games.

103
README.md Normal file
View file

@ -0,0 +1,103 @@
# FriiDump - A program to dump Nintendo Wii and GameCube discs
FriiDump is a program that lets you dump Nintendo Wii and GameCube discs from your computer, without using original Nintendo hardware. It basically performs the same functions as the famous "RawDump" program, but with a big difference, which should be clear straight from its name: FriiDump is free software, where "free" is to be intended both as in "free speech" and in "free beer". As such, FriiDump is distributed with its sources.
This leads to a number of good consequences:
- Having the sources available, it can be easily ported to different operating systems and hardware platforms. At the moment it is developed under a GNU/Linux system, but it also runs natively on Windows. A MacOS X version can be easily created, although I don't have a Mac, so I can't do it myself.
- Also, having the sources and these being well-organized (I know I'm a modest guy) allows support for new DVD-ROM drives to be added relatively easily. At the moment the same drives as RawDump are supported, but this might improve in the future, if anyone takes the effort... See README.technical for details.
- The sources might also be used as a reference for several things regarding Nintendo Wii/GameCube discs and the hacks used to read them on an ordinary drive.
Furthermore, FriiDump also features some functional improvements over RawDump:
- FriiDump can use 4 different methods to read the disc, with different performance.
- FriiDump dumps a lot of useful information about the discs it dumps, such as whether the disc contains an update or not, which can help avoid bricking your Wii ;).
- FriiDump calculates the CRC32, MD4, MD5, SHA-1 and ED2K hashes of dumped discs, so you can immediately know if your dump is good or not, by comparing the hashes with the well-known ones available on several Internet sites.
- FriiDump comes in the form of a library and a command-line front-end, which allows its functions to be easily reused in other programs.
Unfortunately, there is also a main downfall:
- Even the fastest dump method used by FriiDump is not as fast as RawDump (but not that much slower, either, see the table below).
Anyway, I'm sure that people who cannot use RawDump (i.e.: GNU/Linux, *BSD and MacOS X users) will be happy anyway. Besides, you get the sources, so you can improve them yourself.
Note that FriiDump is only useful to dump *original* Nintendo discs. To dump backup copies you can use any DVD-dumping program (i.e.: `dd` under UNIX ;)).
FriiDump came to existance thanks to the work by a lot of people, most of which are probably not aware of this fact ;). Please see the AUTHORS file for the credits.
## Supported drives
At the moment the same drives as RawDump are supported. This is due to various reasons, explained in the README.technical file, which also contains information about what is needed to add support for more drives.
Currently supported drives are:
- LG GDR-8161B (untested, but should work)
- LG GDR-8162B (ditto)
- LG GDR-8163B (HL-DT-ST/DVD-ROM GDR8163B)
- LG GDR-8164B (HL-DT-ST/DVD-ROM GDR8164B)
Other drives might work, most likely those based on the Hitachi MN103 microcontroller. If you find any of them, please report so that they can be added to the compatibility list.
## Installation
If you are a Windows user, probably you will have downloaded the binaries, either zipped or together with an installer, so the installation should be straightforward.
If you downloaded the sources, you will need to compile them. FriiDump uses CMake, for easy portability, so you will need to get it from cmake.org. On Windows you will also need a compiler like Visual Studio (the only tested one, so far) or CygWin/MinGW. On UNIX just do the following, from the directory where you unpacked the sources into:
```bash
mkdir BUILD
cd BUILD
cmake ..
make
make install
```
Linux-specific note: You need root privileges to issue certain commands to the DVD-ROM drive. Hence you have the following possibilities:
- Run FriiDump as root: discouraged.
- Run it through sudo: better but nevertheless discouraged.
- Set the setuid bit on the executable: this is the recommended way to run FriiDump under Linux. This way, the code run with superuser privileges will be reduced to a minimum, guaranteeing a certain level of security (note that security-related bugs might exist anyway!!!). Also note that, even when the setuid bit is set, the attempt to open the drive for reading will be done after privileges have been dropped, so you will need explicit read access to the DVD-ROM drive. Usually having the system administrator add you to the "cdrom" group is enough. To set the setuid bit on the executable, run as root:
```bash
chown root:root /usr/local/bin/friidump
chmod u+s /usr/local/bin/friidump
```
## Usage
FriiDump is a command-line program, so you will need to run it from a terminal or a command-prompt under Windows. The basic usage is as follows:
```bash
friidump -d <drive> -a
```
where `<drive>` will usually be something like `/dev/hda` on Unix-like systems, and something like `e:` for Windows users. With this command, the disc will be dumped to an ISO image file with an automatically-chosen name. Drop `-a` and use the `-i` option if you prefer to specify the filename yourself. If you want to resume an existing dump, use `-s`. If you want to dump the disc to a raw format image file, use `-r`. Note that you can create a raw and an ISO image at the same time.
Other options you might want to use are `-1` through `-4`, to set the dump method, although the default is method 4, which is the fastest one, so most likely you will not need them.
Finally, use `-h` for a listing of all available options.
## Performance
As stated above, FriiDump is not as fast as RawDump. On my PC (Athlon64 3200+), performance is as follows:
| Method | Dump speed | Gamecube disc dump time | Wii disc dump time |
| ------ | ----------- | ----------------------- | ------------------ |
| 1 | Too slow ;) | Eternity | More than eternity |
| 2 | ~570 MB/h | 2.5 hours | 8 hours |
| 3 | ~740 MB /h | 2 hours | 6 hours |
| 4 | ~1250 MB/h | 1.2 hours | 3.5 hours |
## Support
I'm releasing this program under the nickname of "Arep". This is because I am not sure about the legal status of the program, and I do not want to encounter any consequences. Actually, I'm pretty sure FriiDump goes against the DMCA, being a program that circumvents copy-protection, but it might be objected that the format used by Nintendo discs is not a copy-protection method, but just their own, undocumented, disc format. Although, I think it can be freely used in Europe and other coutries without laws similar to the DMCA.
For the same reason, I am not putting an e-mail address here (that @no.net you find in the program is obviously a pun), but support will be provided through the forums of the Italian ConsoleTribe forum, at http://wii.console-tribe.com. If you need help, just open a thread in any section there, even in English: I will *not* reply, but you might stand assured I will read everything you write. FriiDump users are encouraged to help each other there ;).
Patches are welcome, too: just attach them to your post, and maybe put something like "[PATCH]" in the topic subject, so that I can easily spot them.
New releases will be announced on that forum, and also on QJ.net, if I find a good way to notify them.
If you want to donate to the project, do not do it, and donate to one of the free Wii modchip projects out there, such as OpenWii, WiiFree or YAOSM.
## Disclaimer
FriiDump is distributed under the GNU General Public License version 2. See the COPYING file for details.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Also, please note that this program is not meant to be used to spread game piracy, but rather to be an instrument to make backups of your own precious legally-bought games.

1
docs/INSTALL
View file

@ -1 +0,0 @@
See README.

53
docs/NEWS
View file

@ -1,53 +0,0 @@
Since last official version original method 1 have been renamed to method 0
and it undergone certain changes. Methods 2, 3, 4 have been renamed to 7, 8
and 9 respectively. Method 0 should work with all drives as long as they
are supported by one of memory dump commands, so if drive is unrecognized it
is preferable to keep method at 0, and try all commands. If one of such
combinations turns out to work, you can proceed then testing other methods
with this commad. In case none of commands work, you could try to determine
drive's Read Buffer command's parameters with supplied 'BruteForce3C.exe'.
Generally program's overall bahaviour regarding commandline haven't changed
and you should be able to use same options as with official versions, though
in case you were using unrecognized drive, which would nevertheless work with
Hitachi command, you'll need to set command to 2 now (e.g. --command 2) and
method to 7, 8 or 9.
Performance have increased since official release and should be now about the
same as with 'RawDump'.
Regarding supported drives:
1. Hitachi-LG GDR8161B, GDR8162B, GDR8163B, GDR8164B, GDR8082N
Those drives can read GC/Wii media without swapping. Expected performance is
1600..1900 MB/h for *4B, *3B and 2100..2600 MB/h for *2B, *1B. Custom memory
dump command is used, which returns 2064 bytes of data. It was reproted that
they can not read other (e.g. PC) discs this way though, this needs
confirmation.
2. Lite-On LH-18A1H, DVDRW LH-18A1P, DVDRW LH-20A1H, DVDRW LH-20A1P
Reading performance for PC DVDs can go up to 5000 MB/h, which means program's
core as well as new methods are capable to output data at least at this rate.
Reading performance for GC was about 1600..1700 MB/h so likely this slowdown is
caused by drive logic itself. Though I only had one GC game to test with, so
possibly better results can be achieved depending on media. Best results were
obtained, when using method 5 with parameter 16,27 (--method5=16,27). This
combination isn't set as default because it can cause noticable delays
depending on medium quality and to make methods more general for use with other
devices. Lite-On won't read GC/Wii DVDs at all without swapping. Lite-On
returns 2384 bytes of data (2064 + ECC) by means of vendor specific READ BUFFER
command. Tested with models LH-18A1H, LH-18A1P and LH-20A1H.
3. Plextor
Plextor would return 2064 bytes of already unscrambled data with READ BUFFER
command. It works good with ordinary DVDs but due the lack of streamed reading
support is practically useless for GC/Wii dumping because of very low
performance. Works nevertheless and could be used for some experiments and
testing. Results from PX-760A.
4. Toshiba Samsung SH-D162A, SH-D162B, SH-D162C, SH-D162D
Returns 2384 data bytes per sector like Lite-On does. Appears to support
streamed reading but performance with tested model (SH-D162D) was somewhat low
and unstable even with ordinary DVDs. Looks promising, if only good-working
method could be determined. Latest drives added, definitely need more testing
at this point.

33
docs/README.technical
View file

@ -1,29 +1,18 @@
FriiDump Techincal info
===============================================================================
This document is a reworking and unification of information found all over the
net, regarding the structure of Nintendo Gamecube/Wii Optical Discs and how to
read them on an ordinary DVD-ROM drive. All the due credits can be found in the
AUTHORS file.
This document is a reworking and unification of information found all over the net, regarding the structure of Nintendo Gamecube/Wii Optical Discs and how to read them on an ordinary DVD-ROM drive. All the due credits can be found in the AUTHORS file.
===============================================================================
Nintendo Gamecube/Wii Optical Disc (GOD/WOD) structure
===============================================================================
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.
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:
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 |
- - - - - - - - - - - - - - - - - - - - - - - - - -
| 4 bytes | 2 bytes | 6 bytes | 2048 bytes | 4 bytes |
| ------- | ------- | ------- | --------------- | ------- |
| 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.
@ -44,9 +33,9 @@ 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
@ -63,9 +52,9 @@ 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 |
- - - - - - - - - -
@ -231,4 +220,4 @@ autodetection for the new drive, in the "dvd_assign_functions" function.
Apart from this, the cache behaviour of the new drive might not be the same
as that of the currently supported models, so the program architecture might
need radical changes. In this case, please report.
need radical changes. In this case, please report.

13
docs/TODO
View file

@ -1,13 +0,0 @@
- Hashes are wrongly calculated on big-endian machines. This just needs fixing
of some #define's in the multihash library.
- Add MacOS X-specific code. All that is needed is a way to send MMC commands
to the DVD-ROM drive. Inspiration can be taken from the libcdio sources. If
only I had a Mac... Same goes for *BSD, anyway.
- Maybe write a graphical client. I will not do this as I am no GUI fanatic,
but I am sure many Windows users will still use RawDump as it has a GUI,
while we do not. This is actually quite easy, as the program is split into a
library (libfriidump) and a frontend. If anybody does it, please try to make
a portable GUI, maybe by using GTK+, qt, wxWidgets or whatever similar
toolkit you might find.
- Make FriiDump as fast as RawDump (i.e.: 2.5 hours for a Wii disc).
- Improve and better document the library API.

63
docs/ChangeLog → docs/changelog.md
View file

@ -1,31 +1,62 @@
0.5.3 (15/03/2010)
# Changelog
## 0.5.3 (15/03/2010)
### Jackal, gorelord4e, themabus
- Fixed failing after 1st DL media layer with non-Hitachi methods.
- Fixed still hashing with 'nohash' parameter when resuming.
- Fixed resuming larger files (~4 GB).
- Fixed unscrambling larger files.
- Faster file unscrambling.
- Slight modifications to methods;
possible performance increase with Hitachi based devices.
- Restructured methods and added some new ones.
- Added layer break information.
- Added current position output when error occurs.
- Added SH-D162A, SH-D162B, SH-D162C & SH-D162D as supported.
> Jackal, gorelord4e, themabus
0.5.2 (10/01/2010)
###
# 0.5.2 (10/01/2010)
### Jackal, themabus
- Corrected handling of standard DVDs
(type should be forced to 3, when dumping or unscrambling).
- Better response to 'speed' parameter.
- Uniform raw output for all devices: unscrambled data + headers.
- Slight performance increase (~1650 MB/h on LH-18A1H).
- Added LH-18A1P, LH-20A1H, LH-20A1P to list of supported devices.
> Jackal, themabus
0.5.1 (01/12/2009)
###
# 0.5.1 (01/12/2009)
### Jackal, themabus
- New command 'vanilla 2384'.
- Restructured methods, some now support optional parameters.
- Ability to select standard DVDs as source.
- Limited recognized Lite-On drives to LH-18A1H.
> Jackal, themabus
0.5.0 (27/11/2009)
###
# 0.5.0 (27/11/2009)
### Jackal, Truman, themabus
- Regions: Italy, France, Germany, Spain, Australia, PAL-X, PAL-Y.
- Updated publisher list from http://wiitdb.com/Company/HomePage
- Included GDR8082N & GDR8161B as supported Hitachi drives.
@ -37,9 +68,17 @@
- Additional commandline parameters:
stop, speed, command, type, size
- Some minor changes and fixes.
> Jackal, Truman, themabus
0.4 (08/03/2008)
###
# 0.4 (08/03/2008)
### mado3689
- Support for DL Wii DVDs.
> mado3689
0.3 (06/10/2007)
- First public release.
###
# 0.3 (06/10/2007)
- First public release.

3
docs/install.md Normal file
View file

@ -0,0 +1,3 @@
# Install
See README.

21
docs/news.md Normal file
View file

@ -0,0 +1,21 @@
# News
Since the last official version, method 1 has been renamed to method 0 and it has undergone certain changes. Methods 2, 3, and 4 have been renamed to 7, 8 and 9 respectively. Method 0 should work with all drives as long as they are supported by one of the memory dump commands, so if a drive is unrecognized it is preferable to keep the method at 0, and try all the commands. If one (or more) combination(s) turns out to work, you can proceed then testing other methods with this command. In case none of the commands work, you could try to determine the drive's Read Buffer command parameters with supplied `BruteForce3C.exe`.
Generally the program's overall behaviour regarding the command line hasn't changed and you should be able to use the same options as with official versions, though in case you were using an unrecognized drive, which would nevertheless work with the Hitachi command, you'll need to set command to `2` now (e.g. `--command 2`) and method to `7`, `8` or `9`.
Performance have increased since official release and should be now about the same as with RawDump.
## Regarding supported drives:
1. `Hitachi-LG GDR8161B`, `GDR8162B`, `GDR8163B`, `GDR8164B`, GDR8082N Those drives can read GC/Wii media without swapping. Expected performance is 1600-1900 MB/h for `4B`, `3B` and 2100-2600 MB/h for `2B`, `1B`. The custom memory dump command is used, which returns 2064 bytes of data. It was reported that they can't read other (e.g. PC) discs this way though; this needs confirmation.
2. `Lite-On LH-18A1H`, `DVDRW LH-18A1P`, `DVDRW LH-20A1H`, `DVDRW LH-20A1P`
Reading performance for PC DVDs can go up to 5000 MB/h, which means FriiDump's core as well as new methods are capable to output data at least at this rate. Reading performance for a GameCube disk was about 1600-1700 MB/h so likely this slowdown is caused by drive logic itself. Though I only had one GameCube game to test with, so possibly better results can be achieved depending on media. Best results were obtained, when using method 5 with parameter 16,27 (`--method5=16,27`). This combination isn't set as default because it can cause noticable delays depending on medium quality and to make methods more general for use with other devices. Lite-On won't read GC/Wii disks at all without swapping. Lite-On returns 2384 bytes of data (2064 + ECC) by means of vendor specific READ BUFFER command. Tested with models `LH-18A1H`, `LH-18A1P` and `LH-20A1H`.
3. `Plextor PX-760A`
The Plextor would return 2064 bytes of already unscrambled data with READ BUFFER command. It works well with ordinary DVDs but due to the lack of streamed reading support is practically useless for GC/Wii dumping because of very low performance. Works nevertheless and could be used for some experiments and testing. Results from PX-760A.
4. `Toshiba Samsung SH-D162A`, `SH-D162B`, `SH-D162C`, `SH-D162D`
Returns 2384 data bytes per sector like Lite-On does. Appears to support streamed reading but performance with tested model (`SH-D162D`) was somewhat low and unstable even with ordinary DVDs. Looks promising, if only a well-working method could be determined. Latest drives added, definitely need more testing at this point.

64
docs/options
View file

@ -1,64 +0,0 @@
FriiDump 0.5.3 - Copyright (C) 2007 Arep
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; see COPYING for details.
Official support forum: http://wii.console-tribe.com
Forum for this UNOFFICIAL VERSION: http://forum.redump.org
Available command line options:
-h, --help Show this help
-a, --autodump Dump the disc to an ISO file with an
automatically-generated name, resuming the dump
if possible
-g, --gui Use more verbose output that can be easily
parsed by a GUI frontend
-d, --device <device> Dump disc from device <device>
-p, --stop Instruct device to stop disc rotation
-c, --command <nr> Force memory dump command:
0 - vanilla 2064
1 - vanilla 2384
2 - Hitachi
3 - Lite-On
4 - Renesas
-x, --speed <x> Set streaming speed (1, 24, 32, 64, etc.,
where 1 = 150 KiB/s and so on)
-T, --type <nr> Force disc type:
0 - GameCube
1 - Wii
2 - Wii_DL
3 - DVD
-S, --size <sectors> Force disc size
-r, --raw <file> Output to file <file> in raw format (2064-byte
sectors)
-i, --iso <file> Output to file <file> in ISO format (2048-byte
sectors)
-u, --unscramble <file> Convert (unscramble) raw image contained in
<file> to ISO format
-H, --nohash Do not compute CRC32/MD5/SHA-1 hashes
for generated files
-s, --resume Resume partial dump
- General -----------------------------------
-0, --method0[=<req>,<exp>] Use dumping method 0 (Optional argument
specifies how many sectors to request from disc
and read from cache at a time. Values should be
separated with a comma. Default 16,16)
- Non-Streaming -----------------------------
-1, --method1[=<req>,<exp>] Use dumping method 1 (Default 16,16)
-2, --method2[=<req>,<exp>] Use dumping method 2 (Default 16,16)
-3, --method3[=<req>,<exp>] Use dumping method 3 (Default 16,16)
- Streaming ---------------------------------
-4, --method4[=<req>,<exp>] Use dumping method 4 (Default 27,27)
-5, --method5[=<req>,<exp>] Use dumping method 5 (Default 27,27)
-6, --method6[=<req>,<exp>] Use dumping method 6 (Default 27,27)
- Hitachi -----------------------------------
-7, --method7 Use dumping method 7 (Read and dump 5 blocks
at a time, using streaming read)
-8, --method8 Use dumping method 8 (Read and dump 5 blocks
at a time, using streaming read, using DMA)
-9, --method9 Use dumping method 9 (Read and dump 5 blocks
at a time, using streaming read, using DMA and
some speed tricks)

63
docs/options.md Normal file
View file

@ -0,0 +1,63 @@
# Help
FriiDump 0.5.3 - Copyright (C) 2007 Arep
This software comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions; see COPYING for details.
Official support forum: http://wii.console-tribe.com
Forum for this UNOFFICIAL VERSION: http://forum.redump.org
Available command line options:
`-h, --help` Show help
`-a, --autodump`Dump the disc to an ISO file with an automatically-generated name, resuming the dump if possible
`-g, --gui`Use more verbose output that can be easily parsed by a GUI frontend
`-d, --device <device>`Dump disc from device `<device>`
`-p, --stop` Instruct device to stop disc rotation
`-c, --command <nr>` Force memory dump command:
- 0 - vanilla 2064
- 1 - vanilla 2384
- 2 - Hitachi
- 3 - Lite-On
- 4 - Renesas
` -x, --speed <x>`Set streaming speed (1, 24, 32, 64, etc., where 1 = 150 KiB/s and so on)
` -T, --type <nr>`Force disc type:
- 0 - GameCube
- 1 - Wii
- 2 - Wii_DL
- 3 - DVD
` -S, --size <sectors>`Force disc size
` -r, --raw <file>`Output to file `<file>` in raw format (2064-byteectors)
` -i, --iso <file>`Output to file `<file>` in ISO format (2048-byte sectors)
` -u, --unscramble <file>`Convert (unscramble) raw image contained in`<file>` to ISO format
` -H, --nohash`Do not compute CRC32/MD5/SHA-1 hashes for generated files
` -s, --resume`Resume partial dump
### General
`--method0[=<req>,<exp>]`Use dumping method 0 (Optional argument specifies how many sectors to request from disc and read from cache at a time. Values should be separated with a comma. Default 16,16)
### Non-Streaming
` --method1[=<req>,<exp>]`Use dumping method 1 (Default 16,16)
`--method2[=<req>,<exp>]`Use dumping method 2 (Default 16,16)
`--method3[=<req>,<exp>]`Use dumping method 3 (Default 16,16)
### Streaming
`--method4[=<req>,<exp>]`Use dumping method 4 (Default 27,27)
`--method5[=<req>,<exp>]`Use dumping method 5 (Default 27,27)
` --method6[=<req>,<exp>]`Use dumping method 6 (Default 27,27)
### Hitachi
`--method7`Use dumping method 7 (Read and dump 5 blocks at a time, using streaming read)
`--method8`Use dumping method 8 (Read and dump 5 blocks at a time, using streaming read, using DMA)
`--method9`Use dumping method 9 (Read and dump 5 blocks at a time, using streaming read, using DMA and some speed tricks)

7
docs/todo.md Normal file
View file

@ -0,0 +1,7 @@
# Todo
- Hashes are wrongly calculated on big-endian machines. This just needs fixing of some #define's in the multihash library.
- Add MacOS X-specific code. All that is needed is a way to send MMC commands to the DVD-ROM drive. Inspiration can be taken from the libcdio sources. If only I had a Mac... Same goes for *BSD, anyway.
- Maybe write a graphical client. I will not do this as I am no GUI fanatic, but I am sure many Windows users will still use RawDump as it has a GUI, while we do not. This is actually quite easy, as the program is split into a library (libfriidump) and a frontend. If anybody does it, please try to make a portable GUI, maybe by using GTK+, qt, wxWidgets or whatever similar toolkit you might find.
- Make FriiDump as fast as RawDump (i.e.: 2.5 hours for a Wii disc).
- Improve and better document the library API.