Yes, ok, 90% of computer CDs are unprotected, data only CDs with nothing special in sub-channels; but the 10% most (but not all) people will try to run in mess are game cds, which often do. Particularly classic games which have music as audio tracks and other such stuff.
Well that's why we list the best known images in the softlists ;-)
But for things like OS install discs, and service packs ISO is fine, half the time they're offered as ISO downloads anyway.
The ECC compression CHD optimization code I gave Aaron can double up to provide the data if the emulated system requests it and it isn't present in the format anyway (plus it's needed to check the data is valid because some controllers will generate an interrupt on invalid data). Adding ECD code wouldn't be too hard either. Of course we also need code to *correct* data based on ECC, because many drives will use it for error correction too. Basically we can rebuild anything extra the system wants from ISO, at runtime, as long as there is nothing important copy protection related in there.
Of course, in cases where it's used for protection we DO want to be storing it :-)
Copy protection cases will need some thought anyway, for example, sync/seek based protections are more annoying, we may need to add support for more complete sync metadata, because the actual drives sync / seek based on the first few bytes in each sector which contains the SYNC and sector #. That's how the protections where if you're seeking from behind a sector you get a different sector than if you're seeking from ahead of it. You need that data more quickly than a block can decompress (even with standard zip) but we could have a command to build such a table and append it to the metadata. Alternatively as discussed with OG in the shoutbox, assuming that seeking only ever uses those bytes we could simply store those bytes outside of the main compressed stream in a codec subtype (like we have CD-FLAC right now) and have a command to simply get THAT data rather than decompress the whole hunk.