[BOUNTY] CHD Support for PCSX ReARMed
-
@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.
-
Even if the file was compressed before another compression would alter the checksum.
Nowhere I looked is anything mentioned about lossy compression.
The link you posted says: Can be reverted? Yes. Using the same tool, to generate BIN+CUE files. There's data loss, although it's negligible in terms of functionality.Maybe in some cases there are a few bytes that are altered. I can't test the whole library but that's absolutely negligible in terms of emulating with a raspberry pi.
Maybe I am wrong but you give nothing to proof your point.
Show me something that says the audio compression is ogg vorbis or something. Show me that the FMVs are recompressed (which would take way longer then the few seconds to compress a PBP)
Show me proof and don't just say you know it.Official released psone classics by Sony are compressed with lossy (afaik) audio compression but the developers of the tools that are available to us have never replicated that feature.
-
So I need to prove to you how the PBP source code processes ISOs, but you don't need to confirm your SHA1 against Redump or explain the documentation that I found that proves my point? Nah, since you are giving up, I think I'll stop there as well. Everyone else can decide to believe one of us, or do their own research.
-
Okay. Let's agree to disagree and no hard feelings.
CHD is the better format and I would prefer it but PBP is a good alternative especially for multi disc Games.
Good night! -
Yes, I did my own research and decided that you have no idea what you're talking about and are spreading false information. The tool PSX2PSP produces PBP files that can be re-extracted into bin/cue files with no loss in audio or video quality.
You say you converted 1200 game images with PSX2PSP and all the time you thought the audio tracks were compressed into mp3? You are not the smartest tool in the shed then, because the size difference would be enormous for many games if that were the case.
(I don't care what Sony has done with its own PBP releases, they are probably lossy.)
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.