If you play ROMs both on PC/Android emulators and also on physical hardware
(e.g. PS2: using OPL and Free Mcboot, PS1: using burned CDs and FreePSXBoot, etc.)
then what is the best way to store ROMs?
And best way to load them (HDL Dump Helper GUI? WinHIIP? WLaunchELF + exFAT drag and drop?)
You can talk about any console you like, it might help others if you share a nice workflow.
The (.iso) inside a (.7z) way:
For example for PS2, would it be better to just store a .ISO game file inside a .7z file or convert the .ISO file to .ZSO?
The .7z way saves space (can't remember if it saves more or less than .zso) but there's extra steps in extracting the ROMs one by one.
Well I guess with 7-Zip you can extract multiple folders at once, wait for it to finish
and then search .iso files within the folder and drag and drop them where you need them, then delete the emptied folders when you're done.
The .iso files work both on real hardware and on emulators (unless a specific game has compatibility issues).
The (.zso) way:
The .zso way would mean you would have to use something like OPL Manager to convert ROMs.
In OPL Manager, I think you can only convert .bin to .iso one by one
but when converting between .iso and .zso, you can add multiple ROMs to a queue instead of one by one.
I prefer to use it offline when possible.
I think converting from .bin to .iso (for CD games), errors out if you're offline or block OPL Manager at the firewall or a server problem,
but converting .iso to .zso or .zso back to .iso works even offline, at least on OPL Manager V23.
An offline alternative software for converting .bin to .iso could be WinBin2Iso but I haven't tested it yet.
OPL Manager V23 works offline if you add your OPL game art manually, but obviously requires internet if you want to quickly grab some art from the server, and rename the ROMs to be readable by OPL. Actually, I think it won't even allow you to add art until you connect to the server and rename the game files first. I prefer not to be reliant on an internet connection.
Can't remember if .zso requires WLaunchELF + exFAT.
I think the downside of .zso files is they work on real hardware but not on emulators (except maybe the newest PCSX2? But I don't use that because I refuse to "downgrade" to Windows 10/11 which is inferior, slow and spies on you). Most PCSX2 builds don't work with .zso files.
There might be a Windows 7 compatible hack for one of the earlier 1.7 versions though.
Also curious if there's any difference between .zso and .iso files when it comes to:
gameplay/FMV performance, loading times, fragmentation and if they wear out the HDD/micro SD card at different rates?
The (.CHD) way:
Some people convert .ISO games to .CHD but I think that's only good for emulators (although I've heard there are batch scripts that allow you to convert them back to .iso). In your experience, what method is the best?
Obviously you should backup your ROMs if you can (or keep one copy on the console, and another on a hard drive). I think HDDs are more reliable than flash memory like microSD cards and SSDs which seem to fail more often and hard to recover data from (at least in my experience).
(e.g. PS2: using OPL and Free Mcboot, PS1: using burned CDs and FreePSXBoot, etc.)
then what is the best way to store ROMs?
And best way to load them (HDL Dump Helper GUI? WinHIIP? WLaunchELF + exFAT drag and drop?)
You can talk about any console you like, it might help others if you share a nice workflow.
The (.iso) inside a (.7z) way:
For example for PS2, would it be better to just store a .ISO game file inside a .7z file or convert the .ISO file to .ZSO?
The .7z way saves space (can't remember if it saves more or less than .zso) but there's extra steps in extracting the ROMs one by one.
Well I guess with 7-Zip you can extract multiple folders at once, wait for it to finish
and then search .iso files within the folder and drag and drop them where you need them, then delete the emptied folders when you're done.
The .iso files work both on real hardware and on emulators (unless a specific game has compatibility issues).
The (.zso) way:
The .zso way would mean you would have to use something like OPL Manager to convert ROMs.
In OPL Manager, I think you can only convert .bin to .iso one by one
but when converting between .iso and .zso, you can add multiple ROMs to a queue instead of one by one.
I prefer to use it offline when possible.
I think converting from .bin to .iso (for CD games), errors out if you're offline or block OPL Manager at the firewall or a server problem,
but converting .iso to .zso or .zso back to .iso works even offline, at least on OPL Manager V23.
An offline alternative software for converting .bin to .iso could be WinBin2Iso but I haven't tested it yet.
OPL Manager V23 works offline if you add your OPL game art manually, but obviously requires internet if you want to quickly grab some art from the server, and rename the ROMs to be readable by OPL. Actually, I think it won't even allow you to add art until you connect to the server and rename the game files first. I prefer not to be reliant on an internet connection.
Can't remember if .zso requires WLaunchELF + exFAT.
I think the downside of .zso files is they work on real hardware but not on emulators (except maybe the newest PCSX2? But I don't use that because I refuse to "downgrade" to Windows 10/11 which is inferior, slow and spies on you). Most PCSX2 builds don't work with .zso files.
There might be a Windows 7 compatible hack for one of the earlier 1.7 versions though.
Also curious if there's any difference between .zso and .iso files when it comes to:
gameplay/FMV performance, loading times, fragmentation and if they wear out the HDD/micro SD card at different rates?
The (.CHD) way:
Some people convert .ISO games to .CHD but I think that's only good for emulators (although I've heard there are batch scripts that allow you to convert them back to .iso). In your experience, what method is the best?
Obviously you should backup your ROMs if you can (or keep one copy on the console, and another on a hard drive). I think HDDs are more reliable than flash memory like microSD cards and SSDs which seem to fail more often and hard to recover data from (at least in my experience).
Last edited: