60fpshacksrock
Member
So basically only zero-bytes data, sort of like CISO for GC without the trimming.
PS2 [Testers Needed] Open PS2 Loader with ZSO support (compressed ISO)
- Thread starter Acid_Snake
- Start date
So basically only zero-bytes data, sort of like CISO for GC without the trimming.
Acid_Snake
Developer
Not at all, LZ4 is a far more complex de/compression algorithm than a simple sparse file, also a GCM compressed into a ZSO will probably be smaller than using that sparse-CSO format. Maybe one of these days I stop being a lazy ass and add ZSO support on Nintendont.
The fact that empty or repetitive data gets compressed better is true for all compression algorithms.
Berion
Developer
All advanced compression containers have specified None Compression Areas which are used when application during compression found video/audio, already compressed or encrypted data which will not compress very good or even results in negative compression. NC are for speed up decompression on target app side which don't need waste resources on decompression twice compressed or encrypted data.
60fpshacksrock
Member
Oh, okay. Thanks.
And if Nintendont gets ZSO support, hopefully USB Loader GX will be updated to support it. Too bad the decrypted RVZ format doesn't work on Wii. I mean even a low compression ratio would be nice to use on hardware.
I am stuck using a 32GB SanDisk from 2017 (when they still worked on Wii) as I even bought a 2TB SSD to try with it and it wouldn't work. Not much a loss anyway. My PS3 needs it more than my Wii. If only Windows would stop deleting files from it every now and then.
But how does it detect such data like this? I can understand if the file system is ISO9660 or UDF. But on the other hand Nintendo disc images (GCN and Wii, I am not sure about the Wii U as I don't have one) use a file system that some call FST.
Last edited:
Berion
Developer
Compression isn't on filesystem level but in all cases, on sector level (each 2048B). For NC some formats have table but this can be solved out in different way.
I don't know much about Wii and WiiU but as far as I know, the NR Discs (official name, other is e.g "GOD" from GameCube Optical Disc) have two sections, and second is standard ISO9660 (or maybe I'm wrong? many years have passed since I look at it, sorry), while first contains some meta data for menu and booting (interleaved by so called garbage data). What contains and how are build formats which extracted data from disc, I don't know, I'm relevant to full disc dump in original form but only decrypted.
I don't know much about Wii and WiiU but as far as I know, the NR Discs (official name, other is e.g "GOD" from GameCube Optical Disc) have two sections, and second is standard ISO9660 (or maybe I'm wrong? many years have passed since I look at it, sorry), while first contains some meta data for menu and booting (interleaved by so called garbage data). What contains and how are build formats which extracted data from disc, I don't know, I'm relevant to full disc dump in original form but only decrypted.
Last edited:
60fpshacksrock
Member
I know about the 2048 Bytes on ISO and 2352 for BIN/CUE. Speaking of GameCube, it does not, as far as I know, use ISO9660.
Acid_Snake
Developer
All compressed formats from the PSP (CSO, ZSO, DAX and JSO) can be generally specified as a file containing a header (with a magic number to detect format and information about the file needed to read and decompress data), followed by a table containing the offsets of each and every single block (a block is generally equal to a DVD sector, but it can be bigger than that). After that there might be more data depending on the format and finally the actual data (the blocks) start.
To detect if a block is not compressed various formats came with different solutions:
- CSO/ZSO: the offset of the block (in the offset table at the beggining of the file, right after the header) is encoded such as the top bit of the offset is a flag determining if the block is compressed or not. So lets say that block number 4 starts at offset 0x00001234, but the block is not compressed, so its offset will be encoded as 0x80001234.
- DAX: version 0 doesn't support non-compressed blocks, which actually results in some "compressed" blocks being bigger than when uncompressed, for version 1 it one uses something called the NCAreas, which is data that is appended after the block offset table and before the blocks actually start. Parsing this information is a pain in the ass and I don't recommended, you can use the same trick that JSO does for determining NC blocks (see bellow).
- JSO: this one is quite simple and easy, and can actually be applied to other formats (CSOv2 actually adopts this method). It's as simple as checking the size of the "compressed" block, if it's equal to (or bigger than in CSOv2) the uncompressed block, then the "compressed" block is not actually compressed.
So the way a CSO/ZSO/DAX/JSO reader would work (very simplified) is as follows:
- Game requests reading N sectors starting with sector S.
- CSO reader checks the block offset table to get the starting offset of sector S and the ending offset (of last sector S+N+1). So it now knows exactly how much compressed data it needs to read (last_sector_offset-first_sector_offset).
- Now the reader has to iterate over every single sector and handle: if it's compressed, decompress it, if not, memcpy it.
- The end result is the game obtaining the data exactly as if it were a RAW sector read.
60fpshacksrock
Member
Berion
Developer
On PS2, even for CD it is 2048 (*.zso not support 2352). For PSX, only *.chd or *.ecm can be used.
For about GC, You have right, it is custom fs:
Last edited:
60fpshacksrock
Member
Berion
Developer
@60fpshacksrock It is, yet in older versions tree is split into two sections; in current there is only one and user must choose show meta data to see boot stuff. FYI.
If You know some docs describing Wii and WiiU layout, they also could be added.
If You know some docs describing Wii and WiiU layout, they also could be added.
Last edited:
If that WERE the case, why would you ask anyway and why would you mix stuff up? Why would you bring up non-2048Byte stuff??? Makes ZERO sense... Duh.
60fpshacksrock
Member
Yes, you DID!
See here:
The whole questionnaire/discussion surrounded the topic of non-2048Byte Sectors (because of compressed sectors support in compresed images)........ Nothing else, so stop lying...
Guess what........ That issue does not exist..........
See here:
The whole questionnaire/discussion surrounded the topic of non-2048Byte Sectors (because of compressed sectors support in compresed images)........ Nothing else, so stop lying...
Guess what........ That issue does not exist..........
Last edited:
djhazardous
Member
From my testing with MX4SIO, most ZSO images require mode 1 to run, otherwise you get a black screen on boot.
I don't know if this is a ZSO issue, a MX4SIO issue or a combination of the both.
I don't know if this is a ZSO issue, a MX4SIO issue or a combination of the both.
disco4000
Member
I would suggest this is related to the decompression process in the background, as a result the data stream is inconsistent and the system comes to a hold. Enabling accurate read (Mode 1) prevents the data stream from becoming inconsistent.
Acid_Snake
Developer
This makes sense yes, ZSO makes IO access completely different than with ISO, then add the processing and decompressing. I'm surprised it works with MX4SIO at all.
AgentSmith
Forum Noob
hello guys, i dont know where to ask.
I tried the newest opl beta and formatted my hdd in exfat as GPT. i dragged my games on it and started opl. but there are no games in it.
Do i have to make a folder or something anywhere? do i need to change settings in ulaunchelf?
i followed any tutorial there is, but it wont work. a normal usb stick worked without issues (ZSO games didnt show up either, i converted them via opl manager)
I have a WD7500BPKT and a network adapter. after opl startet and the list were empty, i plugged the hdd to the pc. suprisingly there were new folders (dvd and art etc.)
could you help me?
greetings
Edit:
Okay, i dont know how to edit the post.
i dont know why but maybe the HDD was loose. it worked on the second try loading OPL. Also ZSO Games worked (Alone in the dark, Alone in the Dark - New Nightmare).
ill have to test it now with 350+ games now
Thank you.
I tried the newest opl beta and formatted my hdd in exfat as GPT. i dragged my games on it and started opl. but there are no games in it.
Do i have to make a folder or something anywhere? do i need to change settings in ulaunchelf?
i followed any tutorial there is, but it wont work. a normal usb stick worked without issues (ZSO games didnt show up either, i converted them via opl manager)
I have a WD7500BPKT and a network adapter. after opl startet and the list were empty, i plugged the hdd to the pc. suprisingly there were new folders (dvd and art etc.)
could you help me?
greetings
Edit:
Okay, i dont know how to edit the post.
i dont know why but maybe the HDD was loose. it worked on the second try loading OPL. Also ZSO Games worked (Alone in the dark, Alone in the Dark - New Nightmare).
ill have to test it now with 350+ games now
Thank you.
Last edited by a moderator:
1052
Member
@Acid_Snake, How is it possible that some games work in ZSO but don't work in ISO? More details I wrote here.
Similar threads
-
-
PS2 [POC/Outdated] unofficial Open PS2 Loader (uOPL)- Started by Ripto
- Replies: 58
-
-