PS1 Extracting (ATRAC3?) audio tracks from EBOOT.PBP

Heel

Heel

Member
I've been banging my head against this one for a few days, hopefully someone here can point me in the right direction.

I have a number of PSX games in EBOOT.PBP format that I downloaded from my PS3. Some of these, for instance GaiaSeed (JP version NPJJ-00277) uses CDDA audio in separate tracks. However, these are compressed to what I believe to be ATRAC3 format, but either missing the headers or perhaps are compressed or encrypted. Data in these audio files seems to be very dense and there are no obvious hints as to what it is when examining in a hex editor.

I've extracted these with psxtract (later version that seems to have support for audio tracks), but the audio tracks are just raw data of some kind that's about 10x smaller than the corresponding WAV files you get if you dump from the disc.

To verify my assumption I converted some WAV files from a disc dump of the same game to ATRAC3, and the file sizes seem to match up reasonably well. So I suspect these are indeed ATRAC3 versions of the CDDA audio tracks, but I can't figure out how to get the data converted into WAV so that a proper bin/cue could be generated from the EBOOT.PBP.

I found the pops-fe is able to take a disc dump with WAV audio and generate EBOOT.PBP with compressed ATRAC3 audio that will play on later version of POPS, so my assumption is there is some way to work backwards and get working bin/cue version out of the EBOOT.PBP you download from PSN.

Any hints of suggestions appreciated, and I'm happy to provide more info or debugging.

Thanks!
 
GuilloteTesla said:
If you can convert your PSP PKG game to ISO, you can use UMDGen to extract it's contents: https://www.romhacking.net/utilities/1218/

Never tried to extract PSX audio from an EBOOT.PBP, it's way easier to get the ISO of the PSX game and rip it's audio (CDDA or XA audio).
Click to expand...

Let me clarify, I'm not looking to rip the audio from a game, I'm looking to generate a playable bin/cue from an EBOOT.PBP of PSX games that has compressed CDDA audio. I haven't seen any tools or discussions addressing this as it seems originally eboots used regular CDDA audio in WAV format that you could just extract, but at some point switched to ATRAC3 compressed format and none of the tools I've been able to find are able to handle this format for CDDA audio tracks.
 
Heel said:
Let me clarify, I'm not looking to rip the audio from a game, I'm looking to generate a playable bin/cue from an EBOOT.PBP of PSX games that has compressed CDDA audio. I haven't seen any tools or discussions addressing this as it seems originally eboots used regular CDDA audio in WAV format that you could just extract, but at some point switched to ATRAC3 compressed format and none of the tools I've been able to find are able to handle this format for CDDA audio tracks.
Click to expand...
If its a official Eboot you are trying to extract from PSXtract can rip the game back into BIN format (although not sure if it generates a cue), it doesn't work on unofficial eboots though, it should extract the ATRAC3 files and the games data and any other junk hidden in there (only ever tested it on Tomb Raider 1 official eboot and it seemed to work but results might vary).
 
Devildwarf said:
If its a official Eboot you are trying to extract from PSXtract can rip the game back into BIN format (although not sure if it generates a cue), it doesn't work on unofficial eboots though, it should extract the ATRAC3 files and the games data and any other junk hidden in there (only ever tested it on Tomb Raider 1 official eboot and it seemed to work but results might vary).
Click to expand...

Yes I'm using psxtract to get the audio tracks. The issue is they are compressed audio of some kind (I suspect ATRAC3) so not usable directly. While psxtract claims to generate bin/cue with -c option it actually only really generates the .cue file but does NOT add the audio tracks into the resulting CDROM.BIN. It does run isofix on it which is good as that makes CDROM.BIN playable at least, but the audio tracks are not packaged up in there.

So what I'm looking for is a way to take all those audio tracks that are dumped by psxtract and convert them into WAV format in order to create a playable bin/cue pair - psxtract does NOT seem to do this correctly for CDDA audio tracks currently, it might have worked back when these eboots had full WAV files, but it doesn't work on current PSN eboots with their compressed audio tracks.
 
If psxtract didn't output *.bin+*.cue with all tracks, it means ATRAC3 tracks wasn't decrypted and/or decoded/converted. There are several of forks of this application, and all using the same name... ;)

CDDA is not *.wav. It is Windows Explorer which showing them like that but as often, he lying the user. ;]

Original PSX games from store, all using *.at3 and always use, custom PSX games using *.flac if I'm correct.
 
Berion said:
If psxtract didn't output *.bin+*.cue with all tracks, it means ATRAC3 tracks wasn't decrypted and/or decoded/converted. There are several of forks of this application, and all using the same name... ;)

CDDA is not *.wav. It is Windows Explorer which showing them like that but as often, he lying the user. ;]

Original PSX games from store, all using *.at3 and always use, custom PSX games using *.flac if I'm correct.
Click to expand...

Yeah I was thinking psxtract was the culprit, and sure enough looking at the source it doesn't actually decrypt the audio tracks, nor even tries to add them into the bin/cue (other than filling out the cue entries). So assuming the audio tracks just need the same decryption process as the other data I'll try to see if I can make some progress on pulling it out... It's quite strange to me that this has never been implemented by anyone though... has everyone just been pirating rather than fighting with these eboots :highly amused:
 
Okay I tried applying the same PGD decryption to the audio track data but it fails with:

PGD: Invalid 0x80 MAC hash!
​
Is there any documentation on what format this data is meant to be in or a tool that processes it? It seems none of the psxtract variants have code to actually deal with these correctly...
 
I downloaded all my games so also PSX games (around 22GiB) in time of 3.55 and checked all if PSARs can be converted to *.bin/*.cue. None have problems.

PGD is the encryption format used in PSARs (disc images which are inside *.pbp, which is inside *.pkg).

What exactly psxtract are You using? Maybe it is some broken experimental fork. ;]
 
Last edited:
Berion said:
I downloaded all my games so also PSX games (around 22GiB) in time of 3.55 and checked all if PSARs can be converted to *.bin/*.cue. None have problems.

PGD is the encryption format used in PSARs (disc images which are inside *.pbp, which is inside *.pkg).

What exactly psxtract are You using? Maybe it is some broken experimental fork. ;]
Click to expand...

I've looked at all the psxtract forks, the one I started modifying is https://github.com/Mr-Berzerk/PSXtract2021 as it seems to claim to have merged all the latest code. But I've looked at them all, the source I mean, not just try running them. None of them support CDDA tracks in the bin. They do extract the audio tracks, but they don't actually include them in the final .bin file (since there's no code there to convert them from ATRAC3 I imagine).

Please try loading one of your bin/cues for a game that has audio tracks, you'll see what I mean. I've also since found a discussion of this issue on the issue tracker for that version of psxtract, it doesn't look like it's ever been addressed:

https://github.com/Mr-Berzerk/PSXtract2021/issues/2
 
What You said is obvious and I was just bind. :| Indeed none of my games have CDDA except Castlevania SoTN mentioned in the same gh issue but it is never used in game and game probably not checking its existence. But at last I have one test case.
 
Berion said:
What You said is obvious and I was just bind. :| Indeed none of my games have CDDA except Castlevania SoTN mentioned in the same gh issue but it is never used in game and game probably not checking its existence. But at last I have one test case.
Click to expand...

Yeah I was in the same boat, I ripped all my PSN games with psxtract and just assumed they would all work since the bin/cue was generated and the output showed all the audio tracks being pulled out. It's only recently that I finally tried to play one that has CDDA audio tracks that I realized psxtract is busted :)
 
Okay so looking at the way pops-fe packages up CDDA audio, it seems like simply encoding to ATRAC3 and stripping the first 96 bytes which contains the header. So assuming Sony generated audio files are similar, then at least in theory it's more or less a matter of attaching the right header to the binary data generated by psxtract and then decoding ATRAC3 to WAV (and then stripping the WAV header). I'll try to use my PS3 to rip some audio as it apparently supports ripping to ATRAC3 using Sony's actual encoder and maybe I can then figure out an appropriate header for these tracks...

One other thought is maybe there is some homebrew on either PS3 or PSP that is able to extract PSX iso from eboots which can use Sony code on the console to handle the audio...
 
I forget if Fedor's CDDA Enabler application can handle audio conversion both ways?

Like I know that multibin audio tracks can be tricked to function inside of finalized EBOOT.PBP (in various ways) but once all tracks have been scanned and properly converted there was also that issue I was bringing up about how audio tracks would play once instead of looping

I can't remember best but I did have a lengthy discussion with FWAF and Berion about audio tracks that are inside of ROMs that use multiple bin tracks, although in the end a .PPF patch was the best answer

And the method other than .PPF was to give the files a WAVE header, I'm not sure but that may be cause for tracks playing once instead of looping. If you want, give the link below a read

https://www.psx-place.com/threads/solved-ninja-s-o-d-for-ps1-on-ps3.23583/page-2
 
Only XMB can ripping CDDA to *.at3 (or *.wma?). No homebrew soft designed for that. There is SACD Ripper but it is for SACD as name suggest, totally different and very obscure audio format, and app works on models with SACD/DCD DAC.

I can look into my list of backuped games, maybe I can find some CDDA games besides Castlevania (I have bought almost all PAL titles available in store back in 3.55 era).
 
SKEPTiCK said:
I forget if Fedor's CDDA Enabler application can handle audio conversion both ways?

Like I know that multibin audio tracks can be tricked to function inside of finalized EBOOT.PBP (in various ways) but once all tracks have been scanned and properly converted there was also that issue I was bringing up about how audio tracks would play once instead of looping

I can't remember best but I did have a lengthy discussion with FWAF and Berion about audio tracks that are inside of ROMs that use multiple bin tracks, although in the end a .PPF patch was the best answer

And the method other than .PPF was to give the files a WAVE header, I'm not sure but that may be cause for tracks playing once instead of looping. If you want, give the link below a read

https://www.psx-place.com/threads/solved-ninja-s-o-d-for-ps1-on-ps3.23583/page-2
Click to expand...

Ah this is interesting, I didn't know about the leaked at3tool.exe from Sony mentioned in that thread, that's helpful to test some encoding/decoding on the fly. As far as I can tell it seems to function similar to "ffmpeg -acodec atrac3p" but may be more compatible with Sony generated content.

Fedor's CDDA-Enabler (not to be confused with the PSP CDDA Enabler) is this one here right?

https://www.psx-place.com/threads/obsolete-cdda-enabler-for-psx-eboots-on-ps3.23539/

It looks like it's also one-way only to encode exiting WAV files into AT3 for making custom eboots rather than extract audio tracks from PSN eboots. And is just a wrapper around atrac3tool, which only does encoding:

https://github.com/Treeki/atrac3tool/tree/master/atrac3tool

In other news, I made a little bit of progress trying to decipher the binary data, and in terms of file size it seem sto be very close to 132bit ATRAC3 encoding for the corresponding PCM (WAV). However, the content looks very different, there's no regular frame markers like you would see in a normal AT3 file, and the data is quite dense even at the start of the file whereas the AT3 encoded WAV will have lots of empty frames at the start, I assume to account for the 2 seconds of silence.

So my first guess was that these are encrypted somehow, the problem is it doesn't look like custom eboot code, such as in pops-fe, does any encryption on the audio tracks. It just strips the WAV header off the AT3 file and the resulting tracks seem to work fine on the console.

So that means, whatever data is there is NOT encrypted and the code that processes it on console is able to use it directly, otherwise the headerless AT3 data that pops-fe (and some of these other eboot packagers) inject wouldn't work. So I'm confused... I guess it could be this is just a different format all together, but given that these are raw data and no headers how would the code on console know what to do with it?

One other possibility is psxtract is just dumping the wrong regions at the correct size and I'm simply looking at trash data. That wouldn't be entirely surprising given that it seems nobody has ever verified these audio tracks to actually function after psxtract dumped them. I might have to dig into what psxtract is doing and if I can maybe locate what looks more like the expected audio data in the PSAR...

Are there any other tools out there besides psxtract that can dump PSX eboots? Comparing to another tool's output would help, otherwise I'd have to debug it manually and dig through the PSAR..

This is turning into a real deep rabbit hole haha
 
Good news everyone! I found the version of psxtract that does the needful.

The one that implements all the magic needed to extract ATRAC3 data correctly is this one:

https://github.com/DeadlySystem/psxtract-2

There's no official release compiled for it but I built it locally and it does indeed produce track data in AT3 format! So now it's just a matter of running the conversion to PCM and we can have working bin/cue!

Stay tuned...
 
Some quick tests show that decoding with ffmpeg is not as close to the original as with at3tool.exe. Both sound the same to my ear, but looking at the wave forms it's clear that ffmpeg generated ones are much less similar to the original than the ones generated by at3tool.exe, so from that perspective at3tool.exe output seems superior. The trick is at3tool.exe requires the header to be written in a very exact way, and that's not actually documented anywhere I can find or implemented in any existing atrac3 codecs. The good news is I think I finally managed to reverse engineer all the values that need to go in the header myself, so time to write a little code and see if I can get this thing finally working.
 
You must log in or register to reply here.

Similar threads

Back
Top