[Request] Support for CHD format #10417
Comments
|
adding it to the standalone version would also be nice since not everyone uses RetroArch |
|
We already support CSO format. While it might compress slightly worse, it's still pretty good. |
|
All such formats will compress files in blocks, which won't compress as well as a 7z of the entire file. Have you actually compared a CHD of an ISO to a CSO? Note that you can use maxcso to create CSOs with a larger block size, and using 7-zip's deflate algorithm, which compresses better than most CSO programs. Files compressed this way already work fine in PPSSPP. -[Unknown] |
|
One 'advantage' of CHD is that chdman and mame are supposed to have support for a form softpatching (parent-clones relationships, where clones store different files/sectors). Pity it doesn't work anywhere else (including retroarch, except, ofc, the MAME core)... and they nixed my proposal on their chdman issue report page to add 'reversible hardpatch' to their format (basically, do the boring work of integrating a 'patch update' tool that takes a binary patcher, patches the underlying bytes, and creates a reversal patch to add as header for the next 'patch update' and recompress that again). Big advantage of such schemes is that they don't depend on lazy/dead emulators implementing softpatching to work (reimplementing the wheel every time), while still being easy to update. Emulators still need to implement reading chd, but that's much easier. The devs thought that since the format specifies that the format should support parent/clone relationships this wasn't needed. I'm more pessimistic, complicated features are the first to be handwaved away. Anyway, CHD is bad for now for retroarch anyway because the metadata database and their scanner is not ready to accept CHD checksums, internal or external (even the internal checksums are different from the raw cue/bin because they're of a 'sum' of the involved files, not only the 'first track' or whatever hack RA is using - they previously used cues and gdi and of course this failed alot since many gdi are indistinguishable due to dumping group bad idea, so i'd actually prefer the CHD approach). This may change thou, since they seem proud of the CHD support. |
|
@unknownbrackets I know the question is not for this topic, But do you have a plan to make a GUI for maxcso? What I want to do is to compress iso files, but keep integrity. I mean: 1st - Original ISO file, check CRC32 on database (for example I use renascene) With CSOPlus you will have the best compression but that's because it will delete UPDATE partition, so ISO file will never be as the original once you decompress it. |
|
Is ZSO even ment for the biggest compression? Using The Leecherman's "ISO~PBP converter" for PBP and maxcso for other formats, maybe I just don't understand the settings which I should use for ZSO, but from my testing it was the fastest while leaving the biggest file. Anyway if few mb's is a big deal PBP format seems the best for me, it's also supported on PSP and doesn't modify the file in any way, commonly overlooked with some myths caused by Sony's using it for non-PSP games as well, but PPSSPP supports it just fine. CHD did had a sligly better compression even than PBP, but I don't think it's worth storing PSP games in that format, it's not native to the platform and doesn't have anything which would make it worth using while coming with all MAME stuff that we don't care about. Guess I'll change the title as PPSSPP is not related to RA it looks like posted in wrong place. |
LunaMoo
changed the title
|
The performance difference for ZSO only really matters on the 222Mhz CPU of the PSP. A CFW implemented it, so I tried experimenting with it, but it really didn't seem all that worthwhile for desktop. If your device has a Mhz higher than 1000, it's probably going to make almost no difference in speed (for decompression.) And CSO compresses better. However, LZMA has a more significant impact typically on CPU, mostly because it usually uses larger lookbehind buffers and lots more memory and memory searching. This means using CHD might have a non-negligible performance impact compared to using CSO/ZSO even for modern devices. Would need to be tested, though. Not really planning to add a GUI to maxcso, and also not planning to make it do destructive changes. Note that maxcso is kinda like pngcrush - it tries to compress the same data multiple times to achieve the very best compression ratio. It will usually compress slower than other tools (although can use tons of cores, so not always), but get a better ratio. -[Unknown] |
|
there any update on this? |
|
No. |
|
Sorry to ask, but it seem that this hasn't been looked fior a while now. Do you thing its possible at all? |
|
How much of a win is CHD over CSO anyway? CSO already successfully squishes games pretty well, as previously mentioned, and we do support that. |
|
Depends on data, but if I recall maybe alike 10mb per gb, PBP container which we also support is somewhere between max compression CSO and CHD, making this pretty irrelevant, through there's only windows software for PBP, so CSO is more widely used. |
|
I will run a test now on Final Fantasy type 0 and will come back to you with the result for chd, gz and cso level 9 |
|
I did a quick check on two games: In theory, chd should also have faster I/O, but I don't have any easy way available to benchmark that. |
|
The biggest win with CHD support is being able to use the same tool everywhere, and native fast scan support in dat tools like clrmamepro. The disk space savings are nice too. |
|
Isn't PBP used for psx iso only? I don't know if this is a good example or not Final Fantasy Type-0 (English Patched v2) Dante's Inferno (USA) (v1.01) Summary Saving |
|
CHD has support for parent-child relationship, which are both a interesting way to softpatch and a interesting way to save space in multiple cd games (by making cd 1 the 'parent' of cd 2). I definitely don't recommend doing the second ofc, since it's kind of a 'semantic' mess - and i'm not sure you can do both at the same time. Or at least you can't do it twice (parent-parent2-finalchild). Notice the complete lack of filename or paths here. It's to the application to use a convention to find the 'sets'. Either dats to find the filename, path conventions or a scanning step to collect the sha1sum of all chds on a 'game directory' are all options (i prefer the last option because it doesn't depend on users). Supporting this is currently not supported in libchd (the non mame library handling chd for other projects). |
|
The method 2 you describe is a form of deduplication, I think it will be a total nightmare and a massive performance impact if you don't have the necessary cache or cpu to data crunch. I think the compatibility and easy maintenance of the chd is definitely a worthy method of backup. |
|
As the person who opened that issue, I agree clone support is wonderful, but it's also not terribly important for PSP. It would be quite nice for minor patching, sure, but it's really not as useful as for systems like the PS1 with tons of multidisc games. Also, PBP is only used optimally for PSP, either for uncompressed PSN titles or for PSX-PSP (which is only of value on real hardware). Most of us ripped our PSN versions to ISO for ease of use though. EDIT: Clones don't have any performance impact. CHD splits the image into tens of thousands of "compressed hunks of data" (hence the name), each of which is compressed individually based on which compression method is most efficient. Duplicated hunks are already referencing the same data, clones just reference almost all of the data from the parent, barring the few hunks that have changed. As an example, this is the hunk type breakdown from a clone I made of a translation for a PCE-CD game: To be clear, clones are a fantastic feature and were it supported I'd definitely use it, but I feel like worrying about them before they're supported by libchdr would be a bit premature. For now, let's just see about getting the basic format handled. |
I would expect that chd is a better format than most for this and doesn't use silly half baked features like putting the original file in memory to 'patch it' which is the achilles flaw of every 'softpatching format expanded to cds' that causes all of them to be massive failures with cds - i'm looking at you BPS. Libchdr may still screw up of course, but the format was done for this kind of 'deduplication' usecase. And it's not like the native filesystem dedup works for isos or cue/bin anyway, the FS dedup is oriented to file - it does absolutely nothing to two 99% similar files, and compression dedup often screws up and turns that 99% similar into 20% similar if there are some insignificant but regular offsets discrepancies between two files. In fact, often a file compressor is so worried about compressing inside the file that it loses the opportunity to recognize that two large files are very similar since it forgets about the first file because of the compression window. While chd knows those two files are related and uses filesystem block matching. Of course, even CHD may not help if those two cds are themselves using filesystem compression or cryptography inside their filesystem. Modern games are lame like that, use it case by case. |
|
OK, so a win, but not an enormous one. Some people might find it worthwhile and I do understand that it's nice with a common tool. So if anyone is interested in implementing this, what you need to do is:
I probably won't get to this in the near future myself, busy with finishing up stuff for 1.10 in the time I have. |
|
I don't have the time or expertise to do it myself, but I did toss a $15 bounty on it in case anyone else does. Though bountysource seems to be having some issues right now, so it may take a bit to show up correctly. |
|
I am also willing to support the bounty, its also failing for me too. I tried to top it up with 15 also... getting a massive red errror something went wrong, I will try again later to see if it works. It had an error but it went through anway, kinda strange anyway my pledge went through and the strangest thing is it is still staying at 0 dolar in the bounty... Hopefully someone pick this up as it is a big bonus for everyone. Here is my proof for the pledge and no expiration. |
|
If it hasn't shown up by tomorrow I'll contact them about it. Given that the transactions are being recorded, it should catch up eventually. |
No, PBP is Sony's native container, it's used for all PSP games available from PS Store, it also can be used to compress iso's althrough there's only one software for that and it's win-only ~ https://sites.google.com/site/theleecherman/IsoPbpConverter You probably used PSOne software to end up with larger file, it has no sense as PBP has better compression than CSO with large chunks and as far as I recall testing size was comparable to chd. Adding to your results of FFT0, converted to megabytes for readability: So you save 50 mb on 3000 mb file(PBP - highest compression format supported currently in PPSSPP vs the unsupported CHD), that's roughtly 16 mb per 1000 mb's. Also the tool you use for CSO sucks, most modern CSO tools can support filesize above 2gb, I'd recommend [Unknown's] Max CSO, it also allows compression with larger chunks which is producing smaller file size than just using lvl 9 compression CSO. Edit: included cso2 with [Unknown's] settings. So that's an 11,33mb difference per 1004mb between what we already have and CHD.
In other words CHD compresses by 1.13% better vs currently supported format with highest compression.Not that impressive as comparing it to standard CSO. |
I hate checking this spammy issue, anyway:
Anyway I was never against the chd format itself, but against:
|
|
Respectfully, who is talking about libretro on the issue? The whole reason of 'why chd' has nothing to do with libretro. It has everything to do - to me - with delta chds, which are the only softpatch format for isos around. If you think you're going to get translations 'at the emulator level' you're completely going against portability - i'd prefer not to have emulator lock in, yes - also, try to convince romhacking.net to convert all of its psp patches. I don't have the energy to go against the defaming about 'this is just for piracy' going on in the rest of the rant. Is 'cso' just for piracy? Why not, because it can be used on the psp? Doesn't it make it more likely to be used for piracy? This is just weird format hate. There are reasons not to use chd - you want a psp compatible compression, or you want to run compressed isos on platforms that can't open more than one file per user process at a time, or you want to rename dumps against redump or redump updates (for now), but this paranoia about 'associated to MAME' or 'libretro wants this' is just bizarre. Remove or sabotage the upstreamed libretro backend if you hate their guts that much and quit transferring that hate to a fileformat from another project. |
I think you are right. Did you try it out though? From what I read it looks like someone made that update but it was not supported by the repo developers? So I'm scared to switch over to it only to have no updates. But at this point I just really want to use CHD for many reasons. |
I didn't compile the changes, but was just reading the related discussion where it seemed to die on the vine for no discernible reason. Same dude did the PR to support CHD to PCSX2 iirc. |
Many people who say that the compression ratio of chd exceeds cso ignores the fact that chd uses logical blocks of 19584 bytes for compression by default, which is 8 sectors in size (chdman uses full 2448 bytes as logical sector）. Then under the same conditions, it is fair to compress into cso by setting the block size to 16384 bytes. If you use maxcso compression, you need to use the parameter maxcso --block=16384 |
|
Maxcso takes ages to compress at max whereas chdman is much faster by default with better compression. Outside of the initial time to compress, CHD files are also supported by Retro Achievements. |
|
CHD for performance. would love to see it implemented |
|
Responding to LunaMoo MaxCSO takes a while while still being bigger than CHDMan by default and resulting in bigger files. The main feature that they tout to improve compression even further takes ages longer and still doesn't match CHD's default. There might be some theoretical settings that give it better compression than CHD but at what compression speed? It's not a lie, but its been tested repeatedly, at the defaults, CHD beats CSO in speed and compression ratio and while using it's flag to get even better compression that STILL doesn't match CHD. Maybe if MaxCSO changed to new defaults to at least match it's speed or ratio then that argument would be moot but its not. And I understand you dislike Mame because you consider it piracy, but that kinda is beyond pointless in this one because pretty much every emulator can be used for piracy, including this one, and refusing to use an open source item that works out to be better overall just because of that is, to use an old saying, just cutting your nose off to spite your face. And your support for 7-zip does have some major drawbacks compared to CHD. Having tried that on another system with equally big files, that leads to pretty long load times as it has to actually decompress the entire thing into ram which can add upwards of another 30 seconds to the load time if you are using a Hard drive over an SSD. While the CHD can match a 7-z with ultra settings and a 192MB dictionary. Adopting the 7-zip wouldn't be a win over CHD, it would be a sad consolation prize that gives massive drawbacks over actually supporting CHD. One of the actual advantages of CHD is that it can run the game while compressed unlike the 7z that requires decompression first to run and PSP titles aren't like SNES where it is so small it takes a fraction of a second to deal with. As far as the 0.5MB bit, that was with the MAX settings selected on an 8 core processor, the default settings which much faster but still slower than CHD's defaults. Updated since to a Ryzen 9 5900x and haven't tried it recently but honestly don't expect a miracle. The old processor wasn't exactly giving me a problem it anything either and the upgrade was more about scratching an itch and giving the older one to a family member but having an upgrade go from running a game at 160FPS to 200+FPS doesn't make much of a difference to the end user. Borderlands 2 only needs to go but so far and no CPU bound programs I used ever gave issues except CSO compression. Sir, the fact of the matter is CSO is an antiquated format at this point given the more supported options. BY DEFAULT, it has been beaten by CHD in both speed and size, if MaxCSO wants to change their defaults in a newer version to at least match the compression ratio of CHD without taking 10 times longer than it or at least beat it for the added time, you can have a point. But at this time, there is little point to having CSO over CHD. CSO's main selling point is that the PSP can actually read it which doesn't really matter when the PSP is a dead system that is far gone that it is hard to get a hold nowadays so your choice of playing it either through emulation or not at all for most people. Now, if CSO was something like RVZ is for Dolphin where it actually had a real benefit over the other formats, I could see that. But at this point CSO over CHD is just being stubborn to be stubborn with no benefit to the emulator or its user base. There is a reason that virtually every other disc based emulator outside of Nintendo (RVZ) and Xbox (XISO) has adopted CHD support and not CSO. Heck, even at this point, I have recommended that XEmu emulator add support for CHD compressed XISO as it even offers major benefits there. I know it feels like people are trying to use it for everything, but that is because, for disc based emulators, it beats other disc image formats where it counts. Refusing to use CHD because it came from another emulator who open sourced it for anyone to use is foolish if it improves your own software in the process. And not including that software doesn't fight piracy in any way, shape or form, it just lowers the usability of your own software in the process by omitting that one feature that many want and has tangible benefits to the end user. And to say its because Mame is associated with piracy is pointless as emulation as a whole is associated with it outside of the community itself. My friend actually used to collect arcade machines before he got married and we even got gold memberships to a local barcade for the systems he donated to them but the fact of the matter is I would still prefer mame to the cabinets he had because I have never been good on a joystick and preferred a directional pad for most things with the only exception on those old things being Daytona USA because the steering wheel setup can't be matched on a typical emulator setup. Also, never try and outrace a man who owns the machine, he has every turn on every track memorized into muscle memory, same goes for Mortal Kombat. If the author refuses to support CHD, that is on him, but to claim CSO is the better option is untrue for the average end user. And to claim it is "good enough" still really doesn't hold much water for many users as they only use it begrudgingly because its the only real format they are able to use. The instant CHD support was enabled, you would likely see new users wanting CSO drop like a rock with a large portion of older users actually transitioning over as well. PPSSPP is really the only thing I know of giving CSO any relevance at all nowadays given the overall death of disc based games and systems outside of consoles. |
|
In my experience... Using CSO has horrible performance issues on some
systems... Where as chd doesn't really cause performance issues where I use
it .. so instead of using CSO I just sacrifice the disc space and use iso.
CHD is just superior and it works. It's the best format for disc based
content. It stores well... It plays well. It has the crown
…On Fri, Dec 9, 2022, 10:30 AM Fugus ***@***.***> wrote:
I hate checking this spammy issue, anyway:
* MAXCSO "takes ages" to compress only because by default it tries to compress each block with various compression algorithms then keep the one that worked best, this is it primary feature and what actually allows for lower file sizes with some games despite CHD generally using stronger comprssion(since it's NOT universally stronger for every data type), you can limit it to algorithm of your choice and also specify number of threads to use and block size, depending on your options it can be really fast, but then you're loosing on the primary feature.
* It doesn't have hidden options, in fact it's opposite to CHD, when you run MAXCSO without any argument you get an actual list of arguments and options, doesn't need to search through some archaic places over the net nor look at mame's codebase to figure it out as it's the case with CHD which sucks hard the user friendliness of CHD is under the sea level compared to MAXCSO despite both being CLI.
* MAME is the king of piracy in emulation world, many of us don't want to be linked to that side of emulation, CHD as of now is unfortunately part of it, also being part of it, it's developed around MAME specific needs which are completely different from what modern emulation needs. I'd rather support extracting 7z to RAM since on modern hardware many of us cache ISO into RAM anyway and if you cared soo much about size that would win.
* If you had 0,5mb on a 4ghz cpu then what can I say, time to move on from your P4:), it's slow, but not that slow and again that's MAXCSO feature, it has worse compression algorithms, but it compresses with multiply algorithms and then picks the best one, which is why it can achieve better results in some cases and in others it's really close. Saying you'd need better compression when the difference is around 1% is like really bending reality to your needs as even CHDMAN fans want a different algorithm with slightly worse compression, but better decompression for use on mobiles:).
Anyway I was never against the chd format itself, but against:
* it coming from mame and being full of stuff we don't need nor care to deal with,
* saying it has much better compression - which is just bs, the difference is like 1% which is not "much" by any means and since maxcso compresses the same data a few times then keeping whichever compression was the best which CHD does NOT support, I did had case where MAXCSO had better compression again due to MAXCSO feature of using multiply compresion algorithms which CHD lacks(I think it was some MH game, but it's somewhere above in this spammy issue),
* saying it has essential emulation based features - it does not as explained with hashes last time it doesn't benefit PPSSPP at all since we have param.sfo files provided by the games itself and don't need to store hash which is also not usefull for validation, it can tell you for example "you downloaded a copy made of proper dump", it CAN'T tell you that your copy is STILL a proper dump and file corruption is common within PPSSPP(mobiles) userbase,
* same can be said about softpatching, which in case of PSP games would be better on an emulator level, not on file format level, since for us it would only be useful for something like fan translations and then those always keep compatibility with original hardware, we don't have much use for it otherwise, even for game updates(which btw require use of actual hardware) it's better to develop a sideloading of decrypted files since due to how updates on PSP work, game could still technically access both, updated executable and old one, softpatching doesn't solve that,
* also I'm very much against any arguments surrounding it around "libretro depends on it, you provide it" that project it leeching on emulation for long enough and still their port of PPSSPP sucks, they should start working instead of depending on other project's work.
-
MaxCSO takes a while while still being bigger than CHDMan by default
and resulting in bigger files. The main feature that they tout to improve
compression even further takes ages longer and still doesn't match CHD's
default. There might be some theoretical settings that give it better
compression than CHD but at what compression speed? It's not a lie, but its
been tested repeatedly, at the defaults, CHD beats CSO in speed and
compression ratio and while using it's flag to get even better compression
that STILL doesn't match CHD. Maybe if MaxCSO changed to new defaults to at
least match it's speed or ratio then that argument would be moot but its
not.
-
And I understand you dislike Mame because you consider it piracy, but
that kinda is beyond pointless in this one because pretty much every
emulator can be used for piracy, including this one, and refusing to use an
open source item that works out to be better overall just because of that
is, to use an old saying, just cutting your nose off to spite your face.
-
And your support for 7-zip does have some major drawbacks compared to
CHD. Having tried that on another system with equally big files, that leads
to pretty long load times as it has to actually decompress the entire thing
into ram which can add upwards of another 30 seconds to the load time if
you are using a Hard drive over an SSD. While the CHD can match a 7-z with
ultra settings and a 192MB dictionary. Adopting the 7-zip wouldn't be a win
over CHD, it would be a sad consolation prize that gives massive drawbacks
over actually supporting CHD. One of the actual advantages of CHD is that
it can run the game while compressed unlike the 7z that requires
decompression first to run and PSP titles aren't like SNES where it is so
small it takes a fraction of a second to deal with.
*As far as the 0.5MB bit, that was with the MAX settings selected on an 8
core processor, the default settings which much faster but still slower
than CHD's defaults. Updated since to a Ryzen 9 5900x and haven't tried it
recently but honestly don't expect a miracle. The old processor wasn't
exactly giving me a problem it anything either and the upgrade was more
about scratching an itch and giving the older one to a family member but
having an upgrade go from running a game at 160FPS to 200+FPS doesn't make
much of a difference to the end user. Borderlands 2 only needs to go but so
far and no CPU bound programs I used ever gave issues except CSO
compression.
Sir, the fact of the matter is CSO is an antiquated format at this point
given the more supported options. BY DEFAULT, it has been beaten by CHD in
both speed and size, if MaxCSO wants to change their defaults in a newer
version to at least match the compression ratio of CHD without taking 10
times longer than it or at least beat it for the added time, you can have a
point.
But at this time, there is little point to having CSO over CHD. CSO's main
selling point is that the PSP can actually read it which doesn't really
matter when the PSP is a dead system that is far gone that it is hard to
get a hold nowadays so your choice of playing it either through emulation
or not at all for most people.
Now, if CSO was something like RVZ is for Dolphin where it actually had a
real benefit over the other formats, I could see that. But at this point
CSO over CHD is just being stubborn to be stubborn with no benefit to the
emulator or its user base. There is a reason that virtually every other
disc based emulator outside of Nintendo (RVZ) and Xbox (XISO) has adopted
CHD support and not CSO.
Heck, even at this point, I have recommended that XEmu emulator add
support for CHD compressed XISO as it even offers major benefits there. I
know it feels like people are trying to use it for everything, but that is
because, for disc based emulators, it beats other disc image formats where
it counts.
Refusing to use CHD because it came from another emulator who open sourced
it for anyone to use is foolish if it improves your own software in the
process. And not including that software doesn't fight piracy in any way,
shape or form, it just lowers the usability of your own software in the
process by omitting that one feature that many want and has tangible
benefits to the end user.
And to say its because Mame is associated with piracy is pointless as
emulation as a whole is associated with it outside of the community itself.
My friend actually used to collect arcade machines before he got married
and we even got gold memberships to a local barcade for the systems he
donated to them but the fact of the matter is I would still prefer mame to
the cabinets he had because I have never been good on a joystick and
preferred a directional pad for most things with the only exception on
those old things being Daytona USA because the steering wheel setup can't
be matched on a typical emulator setup. Also, never try and outrace a man
who owns the machine, he has every turn on every track memorized into
muscle memory, same goes for Mortal Kombat.
If the author refuses to support CHD, that is on him, but to claim CSO is
the better option is untrue for the average end user. And to claim it is
"good enough" still really doesn't hold much water for many users as they
only use it begrudgingly because its the only real format they are able to
use.
The instant CHD support was enabled, you would likely see new users
wanting CSO drop like a rock with a large portion of older users actually
transitioning over as well. PPSSPP is really the only thing I know of
giving CSO any relevance at all nowadays given the overall death of disc
based games and systems outside of consoles.
—
Reply to this email directly, view it on GitHub
<#10417 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOUFVB35IVA43W2BWCIVI2TWMNNDTANCNFSM4EIRPVFA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Nobody is refusing to support CHD, it's just not a priority. Again, if someone contributes fully working CHD support and commits to help update it as needed, it'll get in. As for me, I prefer to work on things that can actually improve gameplay and graphics. ISO formats are not very interesting to me and CSO works fine right now. |
|
Understood, I was not directing my responses towards you. I understand your viewpoint and have no issues with it as it is a completely acceptable answer that it isn't a priority given all the other work. My comments was directed more a LunaMoo who seems to have this irrational hate boner for CHD and Mame almost like he designed CSO himself and can't fathom why anyone would want something better. CHD really seems like the better way to go in the long term but it isn't a short term priority. Hope to see it included eventually but it's understandable why it isn't yet given all the other work that can be done. |
Damn how this gets a bounty while the state of ad-hoc/multiplayer support and other preservation related functions on the emulator are way worse since the emulator inception. |
|
I don't want a bounty, but I gave it a shot and came up with something much smaller and maintainable than the previous attempt: #18198 Note that I still recommend CSO. |
|
Basic CHD support (without parent/child iso support, since it's unclear how to do that efficiently without scanning every file in a directory) is now in. |
Ive been looking everywhere but what is Parent/child iso support? Multi disc games into one CHD? |
Parent child relationship is like in the real life, means a game that is "derivated" from another. For example a translated game, hacks, and if I'm not wrong different regions. It's a way to keep related Roms together. |
So like final fantasy 0 was a two UMD game it can be stored as one chd? Thought CHD didnt have that yet. I remember ppl wanting CHD to store multi disc games as one file like sonys PBP format. |
|
Basic CHD support (without parent/child iso support, since it's unclear
how to do that efficiently without scanning every file in a directory) is
now in.
Ive been looking everywhere but what is Parent/child iso support? Multi
disc games into one CHD?
Parent child relationship is like in the real life, means a game that is
"derivated" from another. For example a translated game, hacks, and if I'm
not wrong different regions. It's a way to keep related Roms together.
So like final fantasy 0 was a two UMD game it can be stored as one chd?
Thought CHD didnt have that yet. I remember ppl wanting CHD to store multi
disc games as one file like sonys PBP format.
No. If a game had for example one release for USA and one for Europe, one
release (the parent) would have a normal full size CHD and the other
release (the child) would have a separate tiny CHD containing only the
difference from the other one, and you'd need both files to play it.
|
I forgot this point, the child are "differential" copies. Multi disk is not supported by the CHD format itself as long as I know, so there is no way to do it. |
Oh that makes sense. Thank you for the explanation |
|
So what is an example of a game with this parent child relationship? Something like Birth By Sleep Final Mix with an English patch/translation cannot be used as chd? |
For normal people this feature is not important. Only is important if you want to preserve the PSP library with all games and all versions saving some space. Anyway by the nature of the differential patching, this will not work in almost all PSP games (if not all), because normally the games are ISO rebuilds and they don't share data positions. This feature is more important in other consoles ROMS or games patches using ppf patchers or similar. Anyway, maybe an example can be to have the Final Fantasy Type-0 game which is a JP game (which will be the parent), and the English patched version (child). Best regards |
|
and others
Hello,
I'm using from about a month this emulator, and I've discovered the CHD format. It uses lzma compression so is a space saver (much more than CSO format). Now i'm storing the games in 7z and extracting the ISO when I want to play, but CHD has both benefits (stored in lzma format and playable).
Please, add support for CHD to this core.
Thanks!!
The text was updated successfully, but these errors were encountered: