[REQ] Add support for ECM compression/decompression and similar formats commonly used for disc images in game preservation

[plasmidone]

Problem

Keka users can unarchive and decompress .rar or .7z files containing .ecm files. Keka cannot then decompress these .ecm files to reconstruct the retained original disc image files with extensions such as .bin, .cdi, .nrg and .ccd.

Please consider adding support for decompressing / losslessly decoding ECM-encoded disc images back to their original BIN format.

ECM is a lossless compression/encoding scheme used to reduce the file size of disc images such as BIN files. In macOS, restoring an .ecm file back to its original .bin format is surprisingly difficult and not user-friendly. It took me a while to find a solution when an ECM-compatible version of Keka could have made it happen in seconds! ☆‿☆

From a user's point of view, what usually matters in this case is:

decompress/decode the smaller .ecm file and restore the original, larger .bin disc image.

This seems like a natural fit for Keka's purpose: users have an encoded/compressed file and want to recover the original data in its original usable form.

My first instinct was in fact to try Keka, but I quickly realised .ecm files were not supported, and I then struggled to find a solution. :'(

Solution

Please consider implementing Neill Corlett's ECM (Error Code Modeler) encoding/decoding compression functionality to support disc-image conversions such as .ecm → .bin and .bin → .ecm. This would allow Keka users to work easily and seamlessly with .rar files created using Neill's two-stage file-size reduction/compression process, allowing them to go from .rar → .ecm → .bin and back from .bin → .ecm → .rar, rather than being left with an .ecm file they cannot decode or use.

I recognise that some may not consider ECM to be "compression" in the conventional sense. However, despite ECM and general-purpose compression (Zip, RAR etc.) exploiting different kinds of data redundancy, the underlying principle of lossless compression is the same for both: reducing file size by removing derivable information that can later be reconstructed from what is retained to recover the original data.

Keka already makes handling compressed archives and many types of disc images simple and easy. ♡
Supporting this encoded, compressed disc-image format would make Keka even more useful, and I think it would be greatly appreciated by macOS users who come across or work with .ecm files!

ECM's compression reduces the size of raw CD-ROM image files such as .bin, .cdi, .nrg and .ccd, allowing these files to compress even further with formats such as RAR and 7-Zip, which Keka already supports.

My understanding is that Neill designed ECM as a special-purpose compression preprocessing step (using known, format-specific redundancy) before general-purpose compression (such as pattern matching and entropy coding) is applied. ECM first reduces the size of raw-sector BIN, CDI, NRG and CCD disc images by removing redundant data that can be reconstructed from the retained data, allowing formats such as RAR and 7-Zip to then compress the resulting .ecm file further and produce even smaller final .rar or .7z files than with general-purpose compression alone.

Although ECM provided a practical way to reduce disc-image sizes when storage space was more limited, users may today inadvertently come across .rar or .7z archive files that they decompress with Keka, only to find themselves stuck with a specialised, encoded .ecm disc-image file they cannot decompress/decode to get the original uncompressed .bin disc image file it contains.

Supporting both .ecm → .bin and the reverse .bin → .ecm operation would therefore be a fitting extension of Keka's existing archive and compression capabilities. It would allow Keka to handle the complete process in a two-stage file size reduction: decompressing the outer .rar or .7z archive and then decoding the .ecm file within it, while also allowing users to create ECM files from BIN disc images when smaller storage or easier distribution is desirable.

Alternatives considered

I tried to find a way to decode/decompress the .ecm file separately, but the available solutions are not accessible to the average macOS user.

UNECM is a command-line tool rather than a simple macOS application. Getting it working can involve installing the Homebrew package manager and additional development/build tools such as Meson and Ninja, downloading the source code, and compiling the software. This is far beyond the reach of many users who simply want to restore a compressed .ecm file.

Homebrew also does not currently provide the ecm cask and returns:

Error: No casks found for ecm.

There is a standalone utility called MacMan which looks promising and worked well for me. However, it is relatively new (April 2026), not yet very well known, and it took me a while to come across it.
Unfortunately, most macOS users are unlikely to know that this tool exists or where to find it.

And even if one finds it, macOS shows the dreaded (but somewhat understandable) Gatekeeper warning, as the MacMan app is not notarised and Apple cannot verify the developer. macOS instead suggests moving the application to the Bin, ironically putting the very app that can restore your .bin in the bin. :D

To get around this, macOS requires the user to go into Privacy & Security, manually allow the app to run, and enter their administrator password. Even if they are lucky enough to find MacMan, many less-technical users won't feel comfortable bypassing Gatekeeper for a recently created app just to decode/decompress an .ecm file, particularly if they don't know how to verify its source code on GitHub.

For most people, including existing Keka users, these are not the most intuitive and practical alternatives. A built-in Keka solution would be a real game changer, making the process far more user-friendly than requiring people to navigate unfamiliar command-line tools, package managers, development environments, or separate applications just to decode/decompress an .ecm file.

Additional context

I understand ECM isn't a common compression format like more popular archive/container formats such as RAR and ZIP. From a user's perspective, however, an .ecm file is a smaller, losslessly encoded version of the original .bin CD-ROM image, containing all the information needed to completely reconstruct the original .bin file. In other words, like .rar or .zip files, .ecm files it can be decoded and decompressed back into a larger .bin image without losing any data.

This feels very similar to the way Keka handles other compressed formats: you start with a smaller file and extract/decompress it back into the original, larger file by double-clicking on it.

For many users, a process that converts a smaller file back into a larger original file feels much like working with the .zip or .rar files they are already familiar with. From a user's perspective, the main difference is simply that the file ends in .ecm instead of .zip.

This is why I think support for ECM → BIN in Keka would be amazing!

ECM is not the only format I have increasingly had trouble with. It is one of several formats more and more commonly encountered by users involved in game preservation, emulation, homebrew, and personal dumps of CD-ROM and other optical media.

With recent announcements highlighting the increasingly real end of physical media, as well as the violation and narrowing of consumer rights by multinational corporations around digital purchases, it would also be great to see Keka consider support for other gaming disc-image and game-preservation formats that involve processes like compression/decompression, encoding/decoding, archiving/extracting and encryption/decryption such as ECM, CHD, CSO/CISO, ZSO, DAX, JISO, ISZ, RVZ, GCZ, WIA, WUX, NSZ and XCZ.

I can imagine that these formats are technically different and that supporting all of them may not be practical, particularly given the potential development and maintenance involved. I am not a developer myself and don’t have the technical skills to implement these things or judge how difficult some of these formats would be to support. I simply wanted to give the perspective of an everyday Keka user (with, I'm sure, plenty of inaccurate ways of expressing it) and mention these formats as possibilities for Keka to consider in the future. I really appreciate Keka as an app and how useful it is to so many macOS users like myself, and I'd love to see it continue to grow and support more use cases if appropriate.

I also noticed while researching this request that CSO support was already mentioned in a previous Keka GitHub issue. I included it above as well, since it fits naturally into the broader category of disc-image and game-preservation formats I guess others would like to see Keka support.

I hope you will consider my request, even if not in full with all of the formats mentioned, but at least for ECM and perhaps a few of the other more widely used formats that you feel would make sense for Keka.

Thanks for taking the time to read all the way through this and for making Keka such a great macOS app!