Open undeadindustries opened 6 years ago
I'd rather if any compressed image support came it was chd, which is the mame format so it's:
Then if a new version of chd comes out that is revolutionary and you convert, you don't need to extract or add new hashes to checksum, just check the same internal checksum in the archive (to be fair, zip has this too, but zip is not random access nor is it a 'single' checksum).
Considering mame spreads everywhere, RA might very well be thankful for having a 'extra' parameter for chd, even if the actual dump chosen will eventually be different. Associating 'machine in mame' dump to another emulator using the MAME dats (that will eventually get provided by MAME itself) would probably be best, but that might be difficult.
Regardless, it's likely that they'll be imported eventually...
PSP will take longer though.
The only relevant PSP emulator supports CSO, ISO and I think PBP. libretro can't force upstream to support a format.
https://github.com/hrydgard/ppsspp/issues/10417
On Sun, Nov 4, 2018 at 10:56 PM i30817 notifications@github.com wrote:
I'd rather if any compressed image support came it was chd, which is the mame format so it's:
- better engineered for various things including random access
- standardized for the MAME dumps
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libretro/libretro-database/issues/738#issuecomment-435748333, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0P51ZETs5QgLre3hFFayrpC1YRO5ks5ur7bmgaJpZM4YNTeq .
PBP is defective in PPSSPP, i tried it and it couldn't actually change discs on a actual multi-disc pbp. Or was that pcsx1? That too at least.
'multi-disc' formats support are a bit trash to say the least. I don't trust them.
Especially i don't trust them to be random access (this goes to all 'compressed' formats, except external harddisk compression and chd). They're made for maximum compression of single files and that is directly opposed to seeking efficiency. Chd on the other hand was a format originally made to compress hard-disk images, so it better have a 'seek sector -> start decompressing here' table.
Chd also opens the (unlikely) possibility that libchd that RA is importing into emulators will eventually support parent-child 'chd' roms relationship. This would be a very neat form of softpatching for cds (that i actually doubt will ever happen outside MAME, but still).
Feel free to re-open this when PPSSPP or any other cores support the format. If a third-party vendor provides DATs, we could consider bringing them in. Until then, I'm going to close this.
Thanks all!
But this isn't for just PPSSPP, it's for PS1 also? I wasn't sure if that was the only reason it was closed?
Which core supports PDP? Do you know of a database that has hashes for them?
Beetle PSX HW. And I'm very sorry, I meant PBP files. PDP was a Typo.
About a DB that supports or has the hashes. I have all the files. I'm willing to do whatever legwork is necessary to make this happen. :-)
Thanks! I see the extension listed in mednafen_psx_hw_libretro.info.
PBP files unfortunately are not guarenteed to result in the same MD5 hashes. If you create a PBP, and then do it again, will can result in different hashes. Is the serial still readable? If so, we could have that read through RetroArch and things would "just work" :tm:
How would I find out if the serial is readable? I can check tonight or tomorrow. Thanks!
Wait, this was added by @fr500 in https://github.com/libretro/RetroArch/pull/4377 ....
Hmm, the scanner isn't parsing the .PBP file.
Ahh. So this might be an "easy" feature? That is, if the scanner sees the PBPs?
Got pretty far on this over at pbp
branch:
https://github.com/RobLoach/RetroArch/tree/pbp
Pull Request: https://github.com/RobLoach/RetroArch/pull/7
Detects serial as...
[INFO] Found disk label 'SLUS00627'
We'd need to do some figuring out to get the dash in there. Would appreciate some testing there.
Hmm, looks like it was reverted: https://github.com/libretro/RetroArch/pull/4378
Unsure if it was added back. @retro-wertz and @fr500, do you know what happened to PBP scanning?
i cant remember the details from this, but i think just enabling getting serial from PBP will not work since its not the same format used to detect PS1's serial format (PBP's embedded serials dont have "-", ignore this if there is already existing database specifically for PBP)
with a little rework, it could would work by just using existing ps1 db
@RobLoach ah i think i remember now. the offset to scan for the embedded serial is different in PBP and cue/bin. PBP serial is way farther and i think its gonna be a bit problem for multidisks?.. (PBP serial is actually earlier at 0x130)
in anycase, it still about the way the serial is detected. the current ps1 detect method(current using keywords to start fetching the serial) should be modified for the pbp one(pbp header?).
https://www.psdevwiki.com/ps3/Eboot.PBP#Header_and_filetable PBP type should be ME (0x12c) and serial at 0x130 and can even get title if needed at 0x358 (for multidisk, serial and title is repeated)
I miss this feature. All my PS1 games are in PBP format. It would be great if the scanner could recognize the game. The game serial (SLES-01234) is always present in the PBP file.
Many of us use compressed PBP files for PS1 games with libretro.
Is there already a way to account for this in libretro-database?
If not, I'm wondering if we could update the dat files to support that?
Possibly we would add another field so the image field would have to be changed. Possibly call it "compressed_image" or something like that?