Writing a PPF to fix CDDA Games?

Romanenko

Romanenko

Member
Title, more or less.

I just got into PS3 homebrew and custom firmware, though I have decent experience with other consoles. I don't have much experience with modding, however.

I play a lot of PSX titles, which of course can use CDDA. Ridge Racer is one such title, and as a result music doesn't load during certain sequences (menu, winning race, credits, etc.). It's pretty minor but the game is one of my favorites and it's always a bummer to have silence where upbeat 90's euro EDM should be.

I read around and see that it can be fixed with a ppf patch file, and that other users on the forums (looking at you, krHACKen!) have fixed CDDA titles previously. I can't think that much goes into writing one, especially on a game as simple as Ridge Racer, and I assume that I'm the only person on Earth that cares about this, so I want to give it a shot.

How do I get started with writing ppf's for PSX? My first issue is that my text editor won't open the ppf's. After that I assume there's some assembly involved, which sounds intimidating, but should be as simple as pointing it to the proper portion of the bin.

Thanks!
 
Two kind of issues You can face which are related to not reading CDDA tracks.

First is improper container with image, most of apps making it wrongly (in addition, *.flac is not supported, instead only *.at3?), so first try pack Your PSX games by pop-fe.
https://www.psx-place.com/resources/pop-fe-a-utility-to-create-psx-classics-packages-for-ps3.1256/
https://github.com/sahlberg/pop-fe

Second is wrong pregap set and need executable patch if I remember correct (and this is what KrHACKen did for Tomb Raider [?]). I don't remember now.

PPF is binary file, not text file if I'm right (didn't use it for ages, XDELTA completely replace it). Use hex editor.
 
If you are using ISO or BIN without a CUE file, you won't get the CDDA sound.

If you're using a multi-part bin image with a CUE file, you need to merge the bins in a single bin file.

Another common issue is the pregap or incorrect tracks time in the CUE file.

Very few psx games need a PPF patch to play properly. Most of them play fine with the correct BIN format and CUE file.
 
aldostools said:
Another common issue is the pregap or incorrect tracks time in the CUE file.
Click to expand...
This was what did it. No pregap time on this one, but the cue was incorrect. The original cue that matched redump did not work in the PS3 emulator, and another cue I had created since worked better, so I assumed it was good enough. I took another look at it and it had strange times listed.

I used a tool another forum user created that totally worked (psx-comBINe by ADBeta). Thanks for the help, all!
 
To play the PSX games as a PS Classics on the PS3 there are two ways that the audio tracks can be added.
They can either be stored inside the EBOOT as part of the full disk image (merge the bin files) and a TOC
OR they can be converted into ATRAC3 format and injected into the EBOOT.
ATRAC3 is a compressed audio format, like mp3, but proprietary to SONY. And just like mp3 it also compressed the audio quite nicely.
In my use cases they conpress to about 10% of the original CD-DA track.

IF the ATRAC3 audio blobs are present in the EBOOT then the emulator on the PS3 will play them instead of the CD-DA tracks in the disk image.
This means you can actually skip writing the CD-DA tracks to the EBOOT and ONLY write the first data track! and the audio will still play (as long as you injected the ATRAC3 blobs) eventhough the CD-DA tracks are not present.
This makes your PS Classics that use CD-DA audio a lot smaller, which is nice.

In this scenario you don't need a PPF since you actually don't have any CD-DA tracks in the EBOOT.
You can use pop-fe-ps3 to do all this automagically for you. It is a bit of a hassle to to it manually.
 
So *.at3 are outside PSAR? What about original games which are shared between PSP and PS3? They are significantly good compression and *.pbp are the same on both (on PS3 after unpacking *.pkg and on PSP/PSV/PSTV).
 
Berion said:
So *.at3 are outside PSAR? What about original games which are shared between PSP and PS3? They are significantly good compression and *.pbp are the same on both (on PS3 after unpacking *.pkg and on PSP/PSV/PSTV).
Click to expand...

You can do the same thing for EBOOTs for PSP. I.e. strip off/ignore the CD-DA tracks and ONLY store data track in the PSISOIMG section of the EBOOT.
And then inject the compressed AT3 files. that is what I do in pop-fe-psp nowadays so that the EBOOTs become much smaller.

Interesting thing though on PSP is that IF you store both the full disk image, including the CD-DA tracks in PSISOIMG and also store the AT3 tracks then the emulator on the PSP will play BOTH! Yes, it will both tell the cd-drive emulator "play cd-da track #n" and also play AT3 audio #n simultaneously.


When it comes to sharing EBOOT.PBP between PSP and PS3. I have never managed to get that to work. When I create a EBOOT.PBP for PSP the sectors in PSISOIMG must be compressed (I use compression level 1) or the EBOOT will not work.
When I create a EBOOT.PBP for PS3 then these sectors must be uncompressed (compression level 0) or else it will not work.

I don't know why this is. It could be something to do with that the EBOOTs from the PS store are also encrypted and that this triggers a different codepath on psp/ps3 where this works while the codepaths that are used with my not-encrypted EBOOTs diverge between the two platforms emulators.
(The AT3 files are technically stored inside PSISOIMG I guess but after the disc blocks of size 0x9300 bytes)
 
Last edited:
To clarify :
https://www.psdevwiki.com/ps3/ISO.BIN.EDAT#ISO.BIN_structure

If you look at the section for PSISOIMG it contains an AudioTrackTable (this is for AT3 blobs)
This is the table that points to the AT3 blobs that we inject for the tracks. These blobs are written to the file after the fixed size PSISOIMG section.
But in the PSISOIMG we also have a DiscMapTable that starts in block 17. This points to where the compressed/uncompressed cd-disk chunks are written. These chunks are in 0x9300 size.
The actual chunks are written to the file after the fixed size PSISOIMG section.

When it comes to the DiskMapTable and the 0x9300 sized chunks, you can actually (and I do so) truncate the table after you have written track 1, the data track, and skip writing the CD-DA tracks so that we do not store the whole disk image here but only the chunks for the first track.

As long as you store the AT3 tracks and populate the AudioTrackTable the emulator will play this for the audio instead of the CD-DA tracks.
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top