# MPF puts a settings-driven front end on three disc dumping tools

> Media Preservation Frontend is a C# suite that wraps Redumper, Aaru and DiscImageCreator so that drive dumps can be configured through a single JSON file instead of per-tool command lines. It ships three applications, a Windows-only GUI, a cross-platform CLI and a checker that builds submission info, and it handles the Linux raw I/O capability that the dumping tools need.

**SabreTools/MPF** — Redumper/Aaru/DiscImageCreator GUI in C#

- Repository: https://github.com/SabreTools/MPF
- Stars: 754 · Forks: 50
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/sabretools-mpf

## Three programs around three dumping backends

Media Preservation Frontend, or MPF, is a C# suite that sits in front of Redumper, Aaru and DiscImageCreator. The repository description is blunt about it: a Redumper, Aaru and DiscImageCreator UI in C#.

The reason for the front end is stated in the README for each application. MPF.UI allows users to use Redumper, Aaru or DiscImageCreator in a more user-friendly way, and each backend dumping program is supported as fully as possible to ensure that all information is captured on output. The design goal is not to reimplement dumping. It is to make the same operation reachable without memorising the options of three separate tools.

The suite has three applications.

MPF.UI is the main, UI-centric application, and it exposes the customization options and quality of life settings that are reachable through the Options menu. MPF.CLI is a command line only program offering the same backends in a more user-friendly way, with all options manually configured through the configuration file. MPF.Check is a command line only program for generating submission information from personal rips.

That last one is the piece with a different job. MPF.Check supports the outputs from Redumper, Aaru, DiscImageCreator, Cleanrip, PS3 custom firmware, UmdImageCreator and Xbox Backup Creator, and running it without any parameters displays the help text including all supported parameters. So it is a reader for dump output rather than a dumper, and it covers formats that none of the three backends produce.

The solution file shows how the pieces are separated in the code. The top level has MPF.UI, MPF.CLI, MPF.Check, MPF.Avalonia, plus MPF.ExecutionContexts, MPF.Frontend and MPF.Processors, each with a matching .Test project. The split between Frontend, ExecutionContexts and Processors is the shape of the design: the frontend knows about backends, the execution contexts run them, and the processors handle the results. MPF.Avalonia sits alongside MPF.UI as the cross-platform GUI option in progress.

## One config.json, four possible locations, and it holds credentials

Every application in the suite reads the same configuration file, and the README documents the same location rules for all three.

Configuration files are stored by default next to the application as config.json, and that file contains all settings for the UI including credentials. In addition, the configuration can also be located at ~/Library/Application Support/mpf/config.json on MacOS, %localappdata%\mpf\config.json on Windows, or ~/.config/mpf/config.json on Unix-like systems. The second path will be used by default if running from a read-only device or folder. And if neither directory is readable, no options will be loaded or saved.

Four rules in one paragraph, and each one answers a question someone will have.

The portable form is the one next to the application, which is what you get when you unpack a release into a folder. The per-user forms follow the platform conventions, so a settings file lives where the rest of the user's configuration lives. The read-only fallback exists because the common case for these tools is running from a USB stick or an optical disc, where you cannot write next to the executable. And the last rule is the honest failure case: an unwritable location means no configuration at all, silently, which is a trap when you expected your settings to persist.

The credentials line deserves emphasis. The configuration file holds credentials for the backends, so the file next to the application on a shared or removable drive is a file with secrets in it, and that is worth checking the permissions on.

There is also a migration note. On Windows, older versions may have stored configuration files in %userprofile%\.config\mpf\config.json, and the README says these should be moved or deleted to avoid any confusion.

For MPF.CLI the same file is the only configuration mechanism, since the README says all options are manually configured through the configuration file. For MPF.Check, the generated configuration files may be used for common settings when it is used alongside MPF.UI or MPF.CLI.

## The GUI is Windows-only, and the README says why

The UI support limitations are documented in the code and in prior support tickets, and the README lists them plainly.

The first limitation is Windows-only due to reliance on WPF and Winforms. Two explanatory notes follow. MAUI is not a viable alternative due to lack of out-of-box support for Linux, and Avalonia is being heavily considered as an alternative.

That is a candid account of a real constraint rather than a vague note. A cross-platform rewrite in MAUI was considered and rejected because Linux is not supported out of the box, and Avalonia is the option still under evaluation. The MPF.Avalonia directory in the repository is consistent with that being work in progress rather than a shipped replacement.

The second limitation covers users who need the older runtime. For those who need .NET Framework 4.8, there is an official fork, MPF Legacy at the Deterous organisation.

The third is about scanning rather than about the platform. Some archive types may not be supported for protection scanning, and the README points at the Compatibility Notes in the BinaryObjectScanner repository for details. That is a specific, checkable document rather than a vague warning.

The CLI has a narrower set of limitations, and the list has one item: the same archive types may not be supported for protection scanning. The CLI is therefore the cross-platform option, since the README states that MPF.UI, MPF.CLI and MPF.Check have the same system requirements for running, with the exception that MPF.UI is Windows-only.

The practical shape is that a Mac or Linux user runs MPF.CLI or MPF.Check, a Windows user can use whichever they prefer, and nobody outside Windows can use the GUI yet.

## Linux raw I/O: the capability that does not survive an unzip

The Linux drive access section documents a failure mode that looks like a broken tool but is a permission problem.

Redumper and DiscImageCreator send some drive commands, such as the Plextor reads, that Linux only allows for programs with the CAP_SYS_RAWIO capability. Without it, they stop with Operation not permitted, and DiscImageCreator also reports that the drive does not support the command.

The README then gives the catch that will bite anyone following the instructions exactly once. Unpacking MPF does not keep this capability, so it has to be set again after every download, from the MPF folder:

```bash
sudo setcap cap_sys_rawio=ep Programs/Redumper/bin/redumper
sudo setcap cap_sys_rawio=ep Programs/Creator/DiscImageCreator.out
```

There is a helper for it. The scripts/setcaps.sh script runs the same commands for a given MPF folder:

```bash
sudo sh setcaps.sh /path/to/MPF
```

After that, both programs work as a normal user, without sudo.

That last sentence is the whole design intent. The capability is attached to the file, not to the user, so the correct fix is a narrow file capability rather than running the whole stack as root. The README's advice to run setcaps.sh after every unpack is the price of that model, since extracting an archive resets the extended attributes.

The consequence for an evaluator is that on Linux, a first run of Redumper or DiscImageCreator from an unpacked release will fail with Operation not permitted unless those two commands are run first, and the error message from DiscImageCreator about the drive not supporting the command is misleading in that situation.

## Building from source and the release channels

To build for .NET 10.0, the README says to ensure that the .NET 10.0 SDK, or later, is installed and included in your PATH, then run the following commands from command prompt, Powershell, Terminal, or shell. The section is per application, and the visible part of the README cuts off at that point.

The repository layout suggests the shape of the build. There is a single solution, MPF.sln, covering all the projects and their test projects. The publish scripts at the top level are publish-nix.sh and publish-win.ps1, which is how the two platform builds are produced. The .github directory carries the build and test workflow that the badge points at.

Runtime requirements are spelled out in the system requirements section. MPF.UI, MPF.CLI and MPF.Check have the same system requirements for running, with the exception that MPF.UI is Windows-only. The requirement is the .NET 10.0 Runtime if the build was made without a bundled runtime, and the README links the supported OS versions for .NET 10 rather than restating them, which is the right call for a list that changes with every .NET patch.

The README also asks you to ensure that your operating system and runtimes are as up-to-date as possible, since some features may rely on those updates. That is a soft warning with a hard consequence: the runtime floor is recent enough that an older distribution image may not be a supported target.

Two channels are published. For the most recent stable build, the Releases Page. And for the latest work in progress, the rolling release tag.

The release record matches that. The recent tags are v3.11.0 on 2026-10-12, v3.11.1 on 2026-10-17 and a rolling release on 2026-10-20, and the last push was on 2026-10-20. The project is a community project and the README asks for suggestions, issues, bug reports and crash reports, with the advice to check the issues page first and to try the latest WIP build to see whether a problem has already been addressed.

## Where MPF is the wrong tool, and what it costs to keep

The limits are worth stating plainly for anyone evaluating it.

It is not a dumper. If you have no drive, no disc and no intention to archive physical media, none of the three applications does anything for you. The value is entirely in the configuration layer and in the checking workflow.

The GUI is not available outside Windows, so a Linux or macOS user is limited to the CLI, which means all configuration happens by editing JSON by hand. The README is explicit that all CLI options are manually configured through the configuration file, and there is no menu to discover them. That is a real difference in usability between the two front ends, not a cosmetic one.

Archive formats have gaps. The README repeats the warning in both the UI and CLI sections, that some archive types may not be supported for protection scanning, and points at the Compatibility Notes in BinaryObjectScanner. So the protection scanning path has known coverage limits, and the documentation for them lives in a different repository.

On the operational side, the Linux capability has to be reapplied after every unpack, and the credentials in config.json are stored in plain text next to the application by default. Both are consequences of the design and both are things to plan for rather than discover.

The licence is MIT, which is permissive and worth noting for an archiving tool, since a preservation workflow is often shared between people who are not colleagues. The upgrade cost is low in code terms, with the .NET 10 dependency and the release cadence being the real constraints. The CHANGELIST.md at the top level is the record of what changed between builds, and it is the file to read before moving from one stable version to the next.

## Conclusion

People archiving optical media from personal discs should use MPF, because it removes the need to remember three different command line interfaces and it solves the Linux raw I/O permission problem that stops those tools outright, while the checker turns existing dumps into submission data. It is the wrong tool if you need a GUI on macOS or Linux, since MPF.UI relies on WPF and WinForms and is Windows-only, and it is the wrong tool if your dumps use an archive format that the protection scanner does not handle. Before adopting, check the Compatibility Notes in BinaryObjectScanner for your archive types, run setcaps.sh after every unpack on Linux because the capability does not survive extraction, and decide whether you want the stable release or the rolling build that the README points at for the latest fixes.

## FAQ

### What is MPF used for?

MPF is a C# front end for the Redumper, Aaru and DiscImageCreator dumping tools. MPF.UI and MPF.CLI drive those backends with options from a configuration file, and MPF.Check generates submission information from existing rips.

### Where does MPF store its configuration file?

By default next to the application as config.json, or at ~/Library/Application Support/mpf/config.json on MacOS, %localappdata%\mpf\config.json on Windows, or ~/.config/mpf/config.json on Unix-like systems. The per-user path is used by default when running from a read-only device or folder, and if neither directory is readable no options are loaded or saved.

### Can I run MPF on Linux or macOS?

MPF.CLI and MPF.Check can, but MPF.UI is Windows-only because of its reliance on WPF and Winforms, and the README notes Avalonia is being considered as an alternative. On Linux you also need the CAP_SYS_RAWIO capability for Redumper and DiscImageCreator, which the setcaps.sh script applies.

### Why does Redumper fail with Operation not permitted on Linux?

Redumper and DiscImageCreator send drive commands such as Plextor reads that Linux only allows for programs with the CAP_SYS_RAWIO capability. Unpacking MPF does not keep that capability, so setcap has to be reapplied after every download, after which both programs work as a normal user.

## Sources

- [Issues](https://github.com/SabreTools/MPF/issues)
- [License: MIT](https://github.com/SabreTools/MPF/blob/master/LICENSE)
- [README](https://github.com/SabreTools/MPF/blob/master/README.md)
- [Releases](https://github.com/SabreTools/MPF/releases)
- [SabreTools/MPF on GitHub](https://github.com/SabreTools/MPF)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sabretools-mpf