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

### 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](https://github.com/halebop17/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!

No source file, test, or entry point is named. Start by confirming with the maintainer whether the scope is ECM only or also the listed preservation formats, then trace how Keka integrates supported archive and compression formats. Done should be agreed support for the selected conversion direction or directions, with the requested disc-image output validated.

由索引模型根據 Issue 內容生成。