diff --git a/docs/INSTALL b/docs/INSTALL deleted file mode 100644 index a195537..0000000 --- a/docs/INSTALL +++ /dev/null @@ -1 +0,0 @@ -See README. diff --git a/docs/NEWS b/docs/NEWS deleted file mode 100644 index 57c27ec..0000000 --- a/docs/NEWS +++ /dev/null @@ -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. diff --git a/docs/README.technical b/docs/README.technical index b599925..0a0b726 100644 --- a/docs/README.technical +++ b/docs/README.technical @@ -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. \ No newline at end of file diff --git a/docs/TODO b/docs/TODO deleted file mode 100644 index 2c83d17..0000000 --- a/docs/TODO +++ /dev/null @@ -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. diff --git a/docs/ChangeLog b/docs/changelog.md similarity index 82% rename from docs/ChangeLog rename to docs/changelog.md index 4d1fa6f..de19755 100644 --- a/docs/ChangeLog +++ b/docs/changelog.md @@ -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. \ No newline at end of file diff --git a/docs/install.md b/docs/install.md new file mode 100644 index 0000000..19d8120 --- /dev/null +++ b/docs/install.md @@ -0,0 +1,3 @@ +# Install + +See README. \ No newline at end of file diff --git a/docs/news.md b/docs/news.md new file mode 100644 index 0000000..9c199ca --- /dev/null +++ b/docs/news.md @@ -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. diff --git a/docs/options b/docs/options deleted file mode 100644 index feea5bb..0000000 --- a/docs/options +++ /dev/null @@ -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 Dump disc from device - -p, --stop Instruct device to stop disc rotation - -c, --command Force memory dump command: - 0 - vanilla 2064 - 1 - vanilla 2384 - 2 - Hitachi - 3 - Lite-On - 4 - Renesas - -x, --speed Set streaming speed (1, 24, 32, 64, etc., - where 1 = 150 KiB/s and so on) - -T, --type Force disc type: - 0 - GameCube - 1 - Wii - 2 - Wii_DL - 3 - DVD - -S, --size Force disc size - -r, --raw Output to file in raw format (2064-byte - sectors) - -i, --iso Output to file in ISO format (2048-byte - sectors) - -u, --unscramble Convert (unscramble) raw image contained in - to ISO format - -H, --nohash Do not compute CRC32/MD5/SHA-1 hashes - for generated files - -s, --resume Resume partial dump - - General ----------------------------------- - -0, --method0[=,] 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[=,] Use dumping method 1 (Default 16,16) - -2, --method2[=,] Use dumping method 2 (Default 16,16) - -3, --method3[=,] Use dumping method 3 (Default 16,16) - - Streaming --------------------------------- - -4, --method4[=,] Use dumping method 4 (Default 27,27) - -5, --method5[=,] Use dumping method 5 (Default 27,27) - -6, --method6[=,] 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) diff --git a/docs/options.md b/docs/options.md new file mode 100644 index 0000000..9c64e03 --- /dev/null +++ b/docs/options.md @@ -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 `Dump disc from device `` +`-p, --stop` Instruct device to stop disc rotation +`-c, --command ` Force memory dump command: + +- 0 - vanilla 2064 +- 1 - vanilla 2384 +- 2 - Hitachi +- 3 - Lite-On +- 4 - Renesas + +` -x, --speed `Set streaming speed (1, 24, 32, 64, etc., where 1 = 150 KiB/s and so on) +` -T, --type `Force disc type: + +- 0 - GameCube +- 1 - Wii +- 2 - Wii_DL +- 3 - DVD + +` -S, --size `Force disc size +` -r, --raw `Output to file `` in raw format (2064-byteectors) +` -i, --iso `Output to file `` in ISO format (2048-byte sectors) +` -u, --unscramble `Convert (unscramble) raw image contained in`` to ISO format +` -H, --nohash`Do not compute CRC32/MD5/SHA-1 hashes for generated files +` -s, --resume`Resume partial dump + +### General + +`--method0[=,]`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[=,]`Use dumping method 1 (Default 16,16) + +`--method2[=,]`Use dumping method 2 (Default 16,16) +`--method3[=,]`Use dumping method 3 (Default 16,16) + +### Streaming + + `--method4[=,]`Use dumping method 4 (Default 27,27) + `--method5[=,]`Use dumping method 5 (Default 27,27) +` --method6[=,]`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) \ No newline at end of file diff --git a/docs/todo.md b/docs/todo.md new file mode 100644 index 0000000..8f73b4d --- /dev/null +++ b/docs/todo.md @@ -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.