#20 Support for compressed images

[Asking_questions]

There are several feature requests, involving disk image compression formats.

CSO/CFS: http://sourceforge.net/tracker/?func=detail&aid=2991956&group_id=93175&atid=603426
*.ECM: http://sourceforge.net/tracker/?func=detail&aid=3554644&group_id=93175&atid=603426
C2D: https://sourceforge.net/tracker/?func=detail&aid=2139178&group_id=93175&atid=603426

All probably can be implemented as separate binary fragments, but having generic recursive decompressing support for both compressed and archived images would IMO be more beneficial.

[Rok Mandeljc]

You are mentioning two different things, which require handling at two different levels.

Support for compressed data chunks within image (i.e. CSO/CFS, C2D) should be handled by fragments; either separate ones, or an unified fragment for compressed data.

Support for compressed/archived images (e.g. ECM) should be handled at the file level access. The whole file access throughout libMirage should be abstracted away by a chain of "file filters", at the bottom of which there would be raw file access. E.g. "raw file access filter" -> "ecm file filter" -> "zip file filter" -> "libmirage image parser" / "libmirage data fragment".

[Rok Mandeljc]

The last line should read: ... -> "zip file filter" -> "ecm file filter" -> ...

[Henrik Stokseth]

I do concur with OP.

Handling of compression etc. should be done at the fragment layer. With caching etc.

As for ECM... the only simple way to handle it would be before the parser... if possible by a GIO input filter. Though I do not beleive this important. ECM is a utility for compression, and not a native format. Sorry.