The large uncompressed chunk may be a result of being encrypted, I'm not sure. For hdd, i suspect they may have copy-on-write at the byte level in the future, which is super great for granularity and keeping the 'rom' safe. A few specializations for each console, such as getting rid of ecd on ps1 for a function, or getting rid of the noise on wii isos, and i can see it as quite a great lossy-but-not-really format for all consoles, or nearly. It uses FLAC by standard on wav data, gets rid of zero fills quite nicely and compresses well on the dreamcast set. chd format for hdd and cdroms and i wish a dumping project like redump took it up as a standard. If i actually had to chose a file compression format i'm quite taken with the. I myself am using external filesystem compression because it's oriented to be more 'random access' than archive compression, and this way i don't depend on emulator support, though i pay the price in retroarch slowing down scanning immensely because of fallback to using crc32/sha1/md5 on the files themselves. There are other reasons to compress, ofc (such as projects like retroarch wanting checksums and taking them direct from precalculated size headers), or consoles like the dreamcast that zero filled immense parts of the cd etc. Encryption ruins compression too (and binary patching unfortunately for romhacking). I'd expect that to be true on the 3ds because i'd expect cartriges manufacturing to be expensive and squeezed as much as possible in a few standard sizes (not sure), and they use crypto, so they already pay that preprocessing price. The thing i most disagree with compressing rom formats, especially some of the modern ones is that as a matter of course, some of them are already performing 'big archive' compression inside the rom as part of the game, so you're paying latency twice for fewer gains.

Citra emulator roms format