Updating default PS3 dumping method

Thanks for the detailed information. It is very helpful and educational. It's good when there is an opportunity to use additional utilities.

Rough Draft of a Step-by-Step Guide:

Dumping ISO using ManaGunZ

Note: You need to have up-to-date ManaGunZ installed on your PS3 (version 1.39 or higher strictly required).

• Connect an NTFS-formatted external device to your PS3, with a PS3ISO folder on the root of the device (a preexisting PS3ISO folder won't be needed in version 1.41 of ManaGunZ; it'll be created automatically and won't fail)

• Launch ManaGunZ with the your game disc already inserted into the console (as of version 1.40 of ManaGunZ, inserting disc while the program is open works, but is a bit buggy and requires extra steps).

• Hover over you game's icon on the PS3 section of the user interface. Make sure that there is a Blu-Ray tag on the lower right side of your screen while hovering over your game, to make sure it is an disc game and not a game dump.

• Press triangle while hovering over your game. On the menu that pops up, click on "Build Encrypted Blu-Ray Disc" and choose a destination for your dump (in this case, it should be /ntfs0:/PS3ISO if you already connected your NTFS device and it was detected correctly). Wait for it to finish dumping.

• After the dump is finished, an encrypted ISO (a .iso.enc file) should be present in the PS3ISO folder of your NTFS partition.

Dumping metadata using Getkey (updated for ManaGunZ)

Note: You need to have installed the GetKeys v2 package, and up-to-date ManaGunZ (version 1.39 or higher strictly required).

• Connect a FAT-32 formatted usb into your PS3

• Open ManaGunZ, press start to enter settings, and navigate to System Tools.

• Click on "Dump 3Dump.bin." (a 'Done' notification should appear once the process is finished).

• Exit ManaGunZ settings by pressing the back button (circle).

• Press select to enter ManaGunZ file manager.

• Navigate to /dev_hdd0/tmp/; a file named 3Dump.bin should be present in the directory. Select it by pressing square over it, press triangle to open options, and click on copy.

• Navigate to the root of your inserted usb device (should be named /dev_usbXXX/), open options and click on paste.

• Exit ManaGunZ, insert your game disc, and run GetKeys (with your USB still attached to the console).

• (The rest of the instructions should be the same).

Feel free to edit this post as you see fit in order to include it in the wiki (It may be overly descriptive).

Note: The developer of ManaGunZ may integrate the GetKeys package into ManaGunZ, so 3Dump.bin generation may not be necessary in the future: https://github.com/Zarh/ManaGunZ/issues/57

Edit: Inserting a disc into the PS3 while ManaGunZ is open only causes a bug when there are no other items/games to be scanned in your console/drive/etc. The bug in question is that the icon+UI won't be automatically refreshed when the disc is inserted, which can be fixed by changing UI styles to Coverflow and back to XMB. (or opening the program again). The issue has already been reported: https://github.com/Zarh/ManaGunZ/issues/59

Sorry for that, what I meant was that the instructions should be the same as the ones in the metadata section about GetKey, Here they are (a bit modified):

• GetKeys should create two files on the root of the USB drive: disc.pic & getkey.log

• The getkey.log file will contain the disc_key, disc_id and PIC. If anything went wrong creating the 3Dump.bin or extracting the data, the "getkey.log" will contain a WARNING message saying the process failed.

• Make sure that you provide the complete and correct metadata for each dump.

Hopefully, with this added to the wiki, more people will try out dumping with MGZ and comment on it.

I've tested 1.40 version of this program by dumping two discs:

1. After Hours Athletes BCES-01335 (perfect condition, dumps fine via multiMAN and matches existing redump entry);
2. LittleBigPlanet 3 BCES-01663/RSC (data side is heavily scratched, cannot be dumped via multiMAN due to read errors).

1. Dumping.

ManaGunZ 1.40 dumped After Hours Athletes game correctly. The hashes match redump entry.

Dumping LittleBigPlanet raised some questions. When multiMAN dumps a disc with read errors it does 30 retries on each error. If data cannot be read in 30 retries, then dumping process is terminated. This happens with my damaged LittleBigPlanet disc too. ManaGunZ on the other hand, continues to dump the disc without terminating dumping process. The read rate dips to 0 MiB/s in problematic areas as expected but dumping is not terminated. I transferred the output dump to my PC, calculated the hashes and they didn't match the redump entry. Now I'm not sure what ManaGunZ does exactly (forcefully fills error segments with zeros or something else) but it clearly is an issue when it comes to accurate dumping. I've had multiple PS3 discs which visually had perfect data surface but rendered read errors upon trying to dump them via multiMAN. With ManaGunZ there is simply no way to tell if such discs were dumped correctly. Moreover, as an additional indicator of dumping process status multiMAN features an active log which shows errors and retry attempts; ManaGunZ has no log and therefore no way to see if any errors were ever encountered during dumping.

Another thing I've noticed is that when multiMAN encounters read errors, discs would slow down and speed up again. In other words, one can hear how optical drive does something with the discs. In ManaGunZ nothing like this happens, just a steady humming of a dumping process despite the errors.

Dumping process of damaged LBP disc via ManaGunZ 1.40:

https://www.youtube.com/watch?v=E2Qr5mHiBwo

Dumping process of damaged LBP disc via multiMAN 04.85.01:

https://www.youtube.com/watch?v=Df6uDcv8uqk

2. Transferring the dumps.

My Slim PS3 has only two USB ports. One is occupied with the controller since its battery is dead. Dumping keys via GetKey requires FAT32 formatted storage. Dumping discs via ManaGunZ requires NTSC formatted storage (as a proposed method in the guide posted above). You can see how this becomes an absolute circus of constantly inserting/removing devices to keep the dumping process going.

ManaGunZ can dump discs to internal HDD just like multiMAN does but at the same time there is no FTP connection support. Therefore even if I dump a disc to internal HDD via ManaGunZ, I would still need to use multiMAN to transfer the dump to my PC since I use cable connection which is the fastest method.

3. Images' filenames.

One interesting detail of ManaGunZ is how it forces its own filename format on the dumps.
For example, multiMAN would name the above-mentioned After Hours Athletes like this:

After Hours Athletes.ISO

While ManaGunZ would render this filename:

BCES01335_20210710_063641.iso

This could actually be a solution for those users who encounter an outright termination of dumping process in multiMAN when certain Japanese discs are attempted to be dumped. They have either Japanese characters or nothing at all in their file/volume names and that, I guess, confuses multiMAN. ManaGunZ might be able to bypass this.

My resume would be that using ManaGunZ for dumping in its current state is not warranted. The way it handles read errors alone is reason enough. At the same time it might help dumpers who have issues with Japanese discs but imagine that those Japanese discs would have read errors as well, then it's a guessing game of was such disc dumped correctly or not all over again.

1. Huh, I didn't know MGZ had trouble handling read errors. All my discs are in very good condition, so that's probably why I never experienced anything like it. Unfortunately I haven't had the time to contribute any dumps to Redump, so I don't have dumper status and thus can't access the PS3 section to compare hashes with my own dumps (I have seen some PS3 Redump hashes posted elsewhere online, and my dumps hashes do match those, but since they are not exactly official I can't use them for testing). I'll report the problems to the developer on GitHub (or perhaps it would be better if Bigmanjapan did so since he was the one who initially encountered the problem). Thankfully, MGZ is open source and the developer is fairly active (unlike MultiMAN), so any problems we encounter can be fixed.

2. Technically speaking, MGZ already dumps the disc keys to NTFS. BUT, they are embedded in an IRD file or a .disc.key file: https://github.com/Zarh/ManaGunZ/issues/57. Though, since you need the logs from GetKeys to submit your dump to Redump, you can't really stop using GetKeys until it is integrated into MGZ. For FTP, it might be better to use webMAN-MOD since it is being actively developed and can be used even while on XMB (it might be worth adding a section about that for those with damaged USB ports).

3. Pretty cool that MGZ may be able to bypass certain problems with Japanese titles. Let's see if someone is willing to test one of those problematic discs.

4. Tools:

• ManaGunZ Latest: https://github.com/Zarh/ManaGunZ/releases

• GetKeys V2: https://archive.org/download/GetKeyR2Ga … -GameOS.7z

I've tried using the 1.41 test build with the same scratched LittleBigPlanet disc.

https://youtu.be/Pc-yYqFAI7w

1. At 05:30 you can see that the log stating read errors appears which is nice.

2. At 06:33 you can see that 30/30 re-tries are reached on the first bad sector, no termination of dumping process or any prompt appearing happens. The log itself is already a pretty nice development but I would like to see a setting (that could be switched on and off in the global settings of the program, for example) that would make dumping process actually be terminated upon any bad sector reaching 30/30 re-tries. My reasoning is that, with multiMAN after I start dumping process, I go and do something else. I don't need to constantly monitor the screen since multiMAN will outright terminate the dumping process by itself. With ManaGunZ in its current state I need to monitor screen in order to know if read errors happened or not.

Also, I'm not sure why multiMAN and ManaGunZ make optical drive behave differently when read errors are encountered. Again, as I've described in my previous post multiMAN would stop and spin the disc again which is very audible while ManaGunZ doesn't do this, even in the 1.41 test version. It wouldn't matter much if the output dumps are correct, I guess. Just a thought.

3. At 07:43 you can see that Cancelled notification pops-up at the upper right corner. That's me trying to terminate the dumping process by pressing Circle button. For some reason, termination doesn't happen if the log is actively shown on screen. When I pressed Hide logs button at 08:14, the dumping process was allowed to be terminated.

I also tried using the newly implemented "Get files for redump.org" function seen at 0:23 in the above video. Works perfectly. And more than that, it outputs files with the custom filenames which include timestamps like this:

BCES01663_20210722_071038.getkey.log
BCES01663_20210722_071038.disc.pic

This is a nice improvement in comparison to GetKey since when keys are dumped via GetKey the output files' filenames would remain the same, meaning that GetKey would overwrite them. This forces dumpers to transfer the files to PC after each dump which wastes time. ManaGunZ improves on this, especially since it uses timestamps a dumper can dump multiple copies of the same game in one session and the files won't be overwritten.

So, ManaGunZ is approaching to be the dumping tool for me. Allow for automatic dumping process termination upon encountering read errors and I'll switch to it. And if FTP connection is added at some point, then I'll drop multiMAN entirely (haven't tried webMAN-MOD yet).

ManaGunZ is compatible with all 4.8X firmware. So both latest Rebug (lite or DEX) and Evilnat should generate proper dumps for redump. Even Ferrox firmware should be compatible. Though, if dumps need to use a specfic FW (for reproducibility or to reduce variables), perhaps only Rebug REX 4.84.2 and Evilnat 4.88 should be "allowed".