ps3-disc-dumper and the two gates that stand between a disc and a usable dump

A dumper that only copies files once decryption is possible

ps3-disc-dumper exists to do one narrow thing: make decrypted copies of PS3 game discs that an emulator can read. The project describes itself as a handy utility for that purpose, and there is no image manager, no library browser and no library-wide feature set around it. The output is a directory of files, not a single container image.

The interesting part is where the work actually is. The software never touches the key itself and never emulates the optical drive. It reads the disc through hardware you supply, decides whether it can decrypt the content, and then copies what comes out. That makes the application a thin, well-behaved front end for a process that is mostly defined by your drive and by whether the title is listed in a key source.

For an engineer picking a tool, that framing matters. A utility that needed a full disc emulator would be a research project. A utility that needs a supported drive and a known key is a tool you can run in an evening. The cost of this project is hardware and data, not development effort.

The compatible drive and the key database are hard prerequisites

The README lists two requirements and they are not optional extras. The first is a compatible blu-ray drive, and the drive reference in the documentation points at the RPCS3 quickstart page under a dumping drives anchor, which is where the project expects you to confirm that your hardware is in the supported set. The second requirement is that the disc must have a decryption key, and the key can arrive in two forms.

The first form is the redump database. The second is the IRD Library, referenced as a separate resource that the project also consults. The repository carries an IrdLibraryClient directory, so at least the IRD lookup happens inside the application rather than through a manual copy-and-paste step.

If neither source knows about the disc in your drive, the dump cannot proceed. That is the hard boundary of this project, and it is worth being blunt about it: ps3-disc-dumper does not brute force, guess or extract keys. Unlisted discs are out of scope, and the README does not document any fallback path for them.

Where the output lands and where the custom keys live

By default every file is copied into the folder where the dumper executable sits, which is the simplest possible behaviour and also the one most likely to surprise you. If you downloaded a binary into your downloads folder, your dump appears there too, mixed in with everything else. The output location is editable in Settings, and that screen also holds the path of a local cache.

That cache matters more than it first appears. If you have your own key or your own IRD file, you can drop it into the local cache directory, and the application will use it instead of relying solely on the remote lookups. The exact path is not written down in the README; it is shown in Settings, so the first run is effectively the discovery step for that setting. It is the kind of detail that costs a user a few minutes and a screen.

Logging is handled in the same place. Logs can be found at the bottom of the Settings window, which is a sensible place for them because a failed dump almost always ends with the user opening that same screen to check the cache path and then scrolling to the log. The design assumes a person is watching the run, and it gives that person the two things they need in one panel.

An Avalonia shell that behaves the same on Windows and Linux

The interface is built on Avalonia, and the repository separates it into a UI.Avalonia project alongside the core Ps3DiscDumper project and a Tests directory. The topic list carries avalonia-ui and fluent-design-system, so the visual layer follows Fluent conventions rather than a platform native look, which is what makes the same window render on both operating systems.

Cross-platform support is a first-class claim rather than an afterthought. The screenshots are labelled Windows 11 and Fedora 39, with dark and light variants for each, and the presence of publish-mac.ps1 next to publish.ps1 shows a macOS publishing path as well even though the documented usage steps mention only Windows and Linux. The build guidance makes the same point from the other direction: on Linux you select the Linux configuration to prevent issues caused by Windows specific dependencies, and you can build for both targets from Windows, testing the Linux build under WSL2 or in a Linux virtual machine.

For someone who owns one PC, a shared tool across two is worth having. For someone with a single machine and no cross platform requirement, the Avalonia layer is the part you pay for without getting anything back, since the actual work happens in the drive and the key lookup.

Running it on Linux takes two console commands

The documented flow is deliberately short. Unpack the binary into any folder, make it executable on Linux, start it, and follow the on screen instructions. The permission change is the only console step required to launch the tool, and it is the one thing a Linux user has to do that a Windows user does not.

$ chmod +x ./ps3-disc-dumper

After the executable starts, the drive should be mounted and the disc visible. The instructions note that on Linux you may need to confirm an automatic mount or mount the disc by hand, either through the file manager or through the mount command in a console.

$ mount

The mount command is given as a way to inspect what is mounted rather than as a recipe with a specific device path, and the README does not document a target device for the PS3 drive, so you are expected to work that out from your own hardware. A binary release may also need .NET prerequisites installed, which the README points to the Microsoft documentation for supported OS versions and dependencies. The build route sidesteps that question entirely because it produces a self contained executable.

Building from source needs the .NET 10.0 SDK

Compiling the solution requires the .NET 10.0 SDK on the machine. The recommendation is JetBrains Rider, Visual Studio or VS Code, and the repository ships a Ps3DiscDumper.sln together with a DotSettings file for the solution. The most important build instruction is a negative one: on Linux you switch to the Linux configuration, because the default configuration pulls in Windows specific dependencies and breaks in ways that are tedious to diagnose.

The .github directory and the two publish scripts show that continuous integration and scripted publishing are part of the workflow rather than a one off manual step. publish.ps1 handles the standard targets and publish-mac.ps1 exists as a separate path, which matches the README statement that a build can be produced for Windows and Linux from a single Windows machine.

Because the SDK version is pinned in the documentation rather than left vague, adopting the project means accepting that dependency too. A developer already on .NET 10 can build in minutes. Anyone on an older toolchain has to install the SDK first, and the README does not describe a way to build against a different major version.

File-level copying is a different job from disc-level imaging

There is a meaningful difference between what this project does and what a generic disc imaging tool does, and it is worth naming it before anyone reaches for the wrong one. A disc-level imager captures the raw stream from the drive and produces a single image file, regardless of whether the content can be decrypted, using the drive's own hardware to read sectors. ps3-disc-dumper works above that layer. It copies files, and it can only copy files it is able to decrypt, which is why the disc key is a hard requirement rather than an optional enhancement.

The practical consequence is that a generic imager is the right choice when you want preservation of a disc as it physically exists, including a title nobody has a key for. ps3-disc-dumper is the right choice when you want files that an emulator will open directly, and you accept that the title must be one the key sources know about. The two approaches also differ in output shape: a folder of files versus one image with a sidecar of metadata, and the folder shape is exactly what a mounted Blu-ray style library expects.

For a technician who needs both, they are complementary rather than competing, and the project's own link to a drive dumping guide is a sensible starting point for the hardware half of the problem.

The gaps: no automation, no verification, no alternative key source

The limits of this project are not subtle. First, everything runs through a graphical interface that a person drives step by step, and there is no command line mode described anywhere in the documentation, so a library of a hundred discs means a hundred attended runs. Second, verification is not addressed: the README does not document a hash check, a post-dump comparison, or a way to confirm that the copied files match the disc. Third, the key sources are the redump database and the IRD Library, and a disc in neither is a dead end.

Other absences are worth listing. The documentation does not describe a rollback path if a dump fails partway through. It does not explain how a partial dump is distinguished from a complete one beyond the log file. It does not mention resuming a failed dump, and it does not mention drive firmware revisions, which are a common source of read errors on hardware of this kind but are not part of the requirement list.

None of this makes the tool bad. It makes it small, and for the one thing it does well the omissions cost little. For a workflow that needs unattended batch operation or integrity guarantees, the gap is total.

Release cadence in 2026 and the MIT licence

The project is not archived, and the last push to the repository was on 2026-07-03. That is a recent enough date to say work is happening, though the recent release tags are clustered rather than spread: v4.5.1 and v4.5.0 both carry 2026-04-27 timestamps, and the pre-release v4.5.0-pre1 sits earlier the same day. The v4.5.0 and v4.5.1 notes describe two small user-visible changes, updated drive enumeration on Windows and showing the drive model.

Those two changes point at where the effort goes. Drive enumeration and drive identity are exactly the problems a user hits when a machine has several optical drives, and it suggests the project is refining the hardware handshake rather than expanding the feature set. Nothing in the release notes mentions the key lookup, the cache, or the copy engine changing.

The licence is MIT, which is a permissive grant with minimal obligations for reuse and redistribution of the code. Anyone embedding the copying logic or the Avalonia interface in a larger tool can do so without asking, subject to retaining the notice. That is worth checking against your own distribution requirements, and this is not legal advice.

Editorial conclusion

Adopt ps3-disc-dumper if you already own a compatible blu-ray drive, can source the disc key from a redump database or the IRD Library, and want a cross-platform GUI that writes plain files to a folder you choose. Skip it if you are hunting for disc-level imaging, batch automation, or a tool that works without the original disc and its key. Before committing, verify that your drive is on the project's list of compatible hardware, that the exact title appears in a redump database, and that the IRD file you supply matches the disc you are about to read.

Frequently asked questions

Official sources

1. 13xforever/ps3-disc-dumper on GitHub
2. Issues
3. License: MIT
4. README
5. Releases