[BOUNTY] CHD Support for PCSX ReARMed
-
Hello there, love the project, can we get some CHD love for ReARMed core, there is a bounty, we ar eat 40$ right now, tons of arm, android and Pi users will benefit
Please retweet us to make some noise!!!
we need all the help we can get and attract someone to use libchdr with ReARMed as it has been implemented in so many cores by now and double the PSX fun in the same spacelibretro has retweeted us, it would be great if retropie would help us too, reaching its great community:
https://twitter.com/RubenJavier77/status/1024962310111207425bounty:
https://www.bountysource.com/issues/57712065-chd-support-for-pcsx-rearmed-40-bountyThanks in advance
Best regards -
@rubenjavier curious, how would a .chd file benefit over a .pbp file?
-
@edmaul69 Well, the biggest benefit would be that compressing to CHD is effortless. All an end-user has to do is supply their PSX games then run a simple batch file alongside
chdman.exefrom MAME.Example: https://www.reddit.com/r/RetroPie/comments/72kh6q/stepbystep_guide_how_to_convert_sega_cd_or_pc/
Also, CHD is a more efficient compression.
Final Fantasy VII (USA) - PBP: 1.46GB - CHD: 1.27GB
Final Fantasy VIII (USA) - PBP: 2.06GB - CHD: 1.72 GB
Final Fantasy IX (USA) - PBP: 1.75 GB - CHD: 1.44 GB -
Gt46l said here
Something no one has mentioned yet, but PBP is a lossy format. You can't convert from a PBP to other formats with with 100% quality of the original, or playable on the original hardware at all, because it destroys the original format and converts audio/video to lossy versions. CHD on the other hand is a non-lossy archive quality format that you can convert to any other file format playable on emulators or hardware. CHD is the only format I would want to save 1200 roms in, even if I intended to use some in other formats.
Can't comment on if this is true or not but if it is then CHD all the way.
-
@rion As far as I know only the original pbp files that you can download from PSN are lossy compression.
The reverse engineered pbp format that we can use is a normal lossless zlib compression. -
@mick2k thats what i thought. I know you can rip them right back to bin and cue and iso and cue.
-
@edmaul69 just like @Eckaji said,
.-lossless compression
.-15-18% better compression than pbp (this makes a bin cue collection almost half its size)
.-its a streamable format, it doesnt need to decompress, just play
.-its increadibly easy to convert entire folders filled with uncompressed psx games with a batch file
.-every disc turns into just one file
.-for copy protected disc (LibCrypt) if you have the .sbi file along the chd file it would work
.-supports redbook audio in flac compression
.-its becoming the defacto standard for libretro cores with support in mame, saturn, pcengine/turbografx, segacd/megacd, psx beetle and future support for dreamcast -
@Mick2K said in [BOUNTY] CHD Support for PCSX ReARMed:
@rion As far as I know only the original pbp files that you can download from PSN are lossy compression.
The reverse engineered pbp format that we can use is a normal lossless zlib compression.@Mick2K & edmaul69, Then you would be incorrect. PBP does 3 things to ISOs thar are lossy and irreversible:
-
PBP kills part of the original copy protection on PS1 roms. They had files with padding in them (zero filled) which served as a DRM check, but when you pbp them, it trims those 0s. Sure you can convert a pbp back to an iso, and even burn it to a disc, but you'll never be able to play it on the original PS1 hardware again.
-
When you PBP a disc it internally converts cdaudio, raw wav tracks, into lossy mp3s and for MPGs it re-encodes them to lesser quality clips. Depending on how you encode the pbp, it can even rip them out completely. Again, yes you can covert back to ISO, but now you don't have the original quality audio/video. You can't get around this with PBP.
-
-
That's wrong. I have converted many (selfmade) PBPs back to bin/cue and they work flawlessly on original hardware (with a modchip of course).
The part about the copy protection I can't confirm nor deny cause the few that are protected are already patched by myself.
I still think the compression with psx2psp and other tools is lossless and I can't find anything that proofs the opposite.
-
@Mick2K said in [BOUNTY] CHD Support for PCSX ReARMed:
I still think the compression with psx2psp and other tools is lossless and I can't find anything that proofs the opposite.
MP3 is a lossy format, so you can hardly call PBP lossless. The fact that you can convert it back to ISO or BIN/CUE doesn't mean is lossless.
-
@mitu where in the world is it documented that psx2psp or others convert the audio to mp3.
There is no lossy audio compression when you convert your game to PBP. Try a game with many redbook audio tracks and look at the file size.That's why CHD is the better format. It has higher compression then PBP because it compresses the audio (lossless FLAC)
-
@Mick2K said in [BOUNTY] CHD Support for PCSX ReARMed:
That's wrong. I have converted many (selfmade) PBPs back to bin/cue and they work flawlessly on original hardware (with a modchip of course).
The part about the copy protection I can't confirm nor deny cause the few that are protected are already patched by myself.
I still think the compression with psx2psp and other tools is lossless and I can't find anything that proofs the opposite.
PBP destroys the 0 padding. If you have a mod chip that ignores the padding, then so be it, but don't go telling everyone on the planet that you know it will work for them. Chd does not destroy the padding, so I CAN say I know it will work for everyone.
I am intimately acquainted with how psx2psp works, having compiled it from source, and written scripts automating the conversion of all 1200+ North America roms, including multidisk games into 1 pbp. I can assure you that unless you are at that level, you have little understanding of what it is actually doing. The fact is PBP is not able to store CDAudio tracks within its container, and it does not convert to FLAC or store as raw wav, therefore audio is stored lossy. You may be able to set the video clip re-encoding to same as source depending on what version of PBP code you find floating around out there, but for audio it would take a significant update for storing different audio formats like FLAC.
Don't confuse the ability to convert something back and forth with similar file sizes and unnoticeable drops in quality(to your ears/eyes) with no loss of fidelity.
-
@gt46l okay it seems I have to believe you even if compiling something from source and writing a script to batch convert is no proof to know how exactly a program works at the core.
So what compression algorithm is used for audio inside a PBP? If it is something like mp3 the PBP should be significantly smaller then a CHD but it is not.
The point about 000 padding I still don't understand. Even if this is the case it doesn't matter because a original PlayStation will never play copies without a mod chip or another modification so it's irrelevant if any padding is removed or not.
A CHD may be an exact 1:1 copy of the original CD image after converting but it will also never work on original hardware after burned back to a cdr.
-
The point is you cannot guarantee that everyone has the same modchip. You keep thinking because your chip plays files with their padding removed, that every modchip will do the same. That is not a good assumption. You may need a modchip to play burned games, but that doesn't mean that every modchip will play stripped files.
As for the audio, I seem to remember it is OGG Vorbis, though I did this a year ago now, so don't quote me. I don't believe I remember seeing the ability to alter the bitrate beyond just selecting the overall compression for the batch meaning all levels zlib, audio, video. I think there was more ability to set switches if you compile from source, but it still is a lossy codec.
-
@gt46l so i made a few tests and i can now say with a 100% certainty that you have no idea what you are talking about.
i converted a .bin to pbp with max. compression and then back to bin and the checksum of both files is exactly the same.
So there is absolutely NO lossy compression of any kind!!!
-
Lol, and does Doom have CDAudio tracks??
-
@gt46l YES!!!!!!!
-
Well I won't argue the 2 SHA-1 hashes you have there are the same. But I also don't see what redump says the SHA1 should be for that disk if it were bin/cue'd, so in essence you are just showing us a comparison of 2 files that we have no idea where you got them or what you did with them, not to mention I don't read german. Having said that, since you are so sure you are right and I am wrong, I suggest you go to all the PBP wiki pages you can find out on the internet, and update them where they say they are lossy to now "Mick2k verified LOSSLESS". Here you can start with this one: http://emulation.gametechwiki.com/index.php/Save_Disk_Space_for_ISOs
-
@gt46l
it doesn't matter if the checksum of the whole image is not on redump. I just compared the bin that I had with the bin that I extracted from the eboot.pbp that I made myself.
The redump link was only to show that there are CDDA tracks.
I tested a few games and it was always 100% identical. I just made the screenshot of one of them.
And it's irrelevant that you don't speak German cause there is not one single information in German that is necessary to understand my point. -
So if you downloaded a copy of the iso and did not compare the sha1 of your download to redump, you can't verify that the version you have was not compressed with lossy compression, and then re-inflated to a bin file. Compressing and reinflating files with the same compression rate won't change the SHA1. The fidelity is already lost. I get what you are trying to say, but you just keep missing the finer details of how these things work. I can see you are adamant that you are correct though, so get to updating those Wikis so the world can know what you KNOW.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.