PS3 Question: PS2 Encrypted File Compression Methods...?

CrashRS

Member
Hello all,

I have finally gotten around to encrypting my PS2 Backups to use on PS3Hen, all done via PS3Classics GUI on PC. Ideally, I would like to store a backup copy of those files on my PC in a compressed format to minimise storage. As an example, a trial standard ISO compresses via 7z to e.g. 80%. But, the .bin.enc files have virtually no compression via 7z. I assume that's because the algorithm can't recognise patterns in the encrypted files, but could be quite wrong.

Does anyone know of any methods for getting at least some amount of compression on the .bin.enc PS2 files for storage on PC?
 
You cannot compress encrypted data efficiently, that's because it doesn't have much patterns which could be simplified. That's normal and your conclusion was accurate.

You should keep backups but as compressed, dedicated formats. I.e in case of PS2 disc images best be *.chd or eventually *.cso. Because You can always decompress them but also plays on emulators on PC with decompressing on the fly. *.7z is still fine (on clean *.iso) but cannot be used for playing without decompression.

This applies to other consoles to. Eg. *.rvz (losseless settings) for GC/Wii/WiiU, *.chd for DC/SAT/PSX/PS2, *.cso for PSP, *.cci for XC (lossless settings).
 
You cannot compress encrypted data efficiently, that's because it doesn't have much patterns which could be simplified. That's normal and your conclusion was accurate.

You should keep backups but as compressed, dedicated formats. I.e in case of PS2 disc images best be *.chd or eventually *.cso. Because You can always decompress them but also plays on emulators on PC with decompressing on the fly. *.7z is still fine (on clean *.iso) but cannot be used for playing without decompression.

This applies to other consoles to. Eg. *.rvz (losseless settings) for GC/Wii/WiiU, *.chd for DC/SAT/PSX/PS2, *.cso for PSP, *.cci for XC (lossless settings).

Excellent, that's great info thank you.

In my case I have the following PS2 Files:
  • Full size clean ISOs that I use for 1) PC emulation & 2) creating encrypted versions for PS3Hen
    • As you've suggested there looks like opportunity to shrink the full size ISOs, maybe to CHD etc., and still run PC Emulation, now that I've created encrypted versions of all that I have. No other need to keep the full size as is.
  • Clean ISOs backed up in .zip on PC/Cold Storage
    • I will likely keep these as a clean 'source' backup set in case something goes wrong
  • Full size .BIN.ENC ISOs that I will use for PS3Hen, for which I've now encrypted all that I have.
    • Is it fair to say then, it's expected there's no (known feasible) way to get these files smaller?
 
Currently - no.

There are requests for CHD support in webMAN via ps3netsrv (https://github.com/aldostools/webMAN-MOD/issues/1183), but as aldostools mentions, no one has worked on it.

Technically, I'd assume something similar could've been implemented in ps3netsrv (for it to automatically encrypt decrypted PS2 ISO/BIN before launching - so you could just store decrypted images).
 
Do not use *.zip. Deflate is good algo but 30 years ago. Today we using LZMA and LZ derivatives (i.e used in *.7z, *.rar, *.xz). ;]

No way to today to get those smaller and no tomorrow. Because of math. ;] There are algos for stronger compression but still you will gain at max ~20MiB by cost of few hours of unpacking on current home machines. Is it worth it?
 
Currently - no.

There are requests for CHD support in webMAN via ps3netsrv (https://github.com/aldostools/webMAN-MOD/issues/1183), but as aldostools mentions, no one has worked on it.

Technically, I'd assume something similar could've been implemented in ps3netsrv (for it to automatically encrypt decrypted PS2 ISO/BIN before launching - so you could just store decrypted images).

Interesting, thanks. It'd be one way, but if I've understood correctly the PS3 would have to be tethered to the PC, so couldn't run those files standlone, which is my main use case. For sure PS3netserv could work well with some other use cases.

Do not use *.zip. Deflate is good algo but 30 years ago. Today we using LZMA and LZ derivatives (i.e used in *.7z, *.rar, *.xz). ;]

No way to today to get those smaller and no tomorrow. Because of math. ;] There are algos for stronger compression but still you will gain at max ~20MiB by cost of few hours of unpacking on current home machines. Is it worth it?

Yeah it's not worth that time to save such small amounts.

Re .zip, it's compressed my library down to 63% which is a good benefit, but yes it could be better with 7z, which I may do in the next case
 
Last edited:
Back
Top