About PAC (Sounds) limitation


PSOBB plastic surgeon
So far when it comes to sound modifications, we could only add SFXs with the exact same size or less than the originals. It is impossible to improve the SFX experience like high res textures and such do for the graphics.

I remember at one point Lee said it was possible to unlock those limits so we can add better quality sounds, actually he was even surprised he didn't already did it :roll:
Then this topic was forgotten i guess, i can't blame him because he probably had a lot of stuff to manage/ work on before the server eventually died.

So my question is, do you think it would be possible to finally unlock those size limitations?


Staff member
I would bet the sizes for the files are in a separate table either outside of the sound or in the executable. You'd probably just have to edit the table as well as the PAC to extend the limit.


I recall that, the size or offset of each sound being hard-coded in the client.
I guess you could extract 2 contiguous files or at least get their offsets and search in a client hex dump for the same values to see what you get.
I'll toy around with it.

This appears to be each file's header 01000100 22560000 44AC0000 02001000 64617461 ...."V..D¬......data if you want to go and check file sizes/offsets.
Probably you already know but the files themselves don't have a valid wav? (I think) header but then I doubt the client would make use of it.


I remember as well there being something different about Eps 4's sound files? I could be talking out my butt, but I'm pretty sure as some point someone said there's something about them that crashes if they're changed at all?


You are talking about the multi-stream ogg files, I don't recall anything about crashing but I never messed with those.
What Echelon talks about are the files inside the .pac (containers?) under pso_folder/data/sound


Ok, so far this is what I got, is not much but is a start
The sounds on pac containers are WAVE files, subset of RIFF files, we already knew that, they have stripped 0x14 bytes of the header, it's not a big deal since it can be retrieved easily (you just need to calculate some size) the rest (should) never change.
More info on WAVE files here: http://soundfile.sapp.org/doc/WaveFormat/

So going by the idea posted before, I searched for file sizes which didn't work, then for offsets and got a table of indexes and offsets apparently... but they are 4 ints each entry, will have to mess with it, or get some assistance about what it (could) mean.
http://i.imgur.com/giFSxRs.jpg (0x00617600 = start of the highlight in the client)

The table seen there is a bit weird, probably someone else could give some more insight.
The indexes are not straight forward, maybe inside the pac file there should be groups?

Other thing too, is that for example, in the picture, the last set of 4 ints (whole window), has the 3rd and 4th int used, which is not the case in the rest of the table so, who knows what that is used for.


PSOBB plastic surgeon
First, thank you very much for the responses.
As much as i find the topic exciting, i really don't have the knowledges to help with hex editing and such :oops: *shamefull* (let alone the language barrier).
Still, thats the first time someting is done on this subject and i'll try my best to learn and help as much as i can.
Thanks again!


I was going to write this before, but idk why I didn't.

I messed up with the files and client. (I had successfully used a custom sound before, for the racast steps but it was smaller than the original)
All of this with common.pac

I tried to modify offsets making room for a bigger sound but didn't work (I believe my sound was "corrupted")
I then added it to the end of the file and modified the offset to it in the client and didn't work (that's why I believe the sound was corrupted)
However, I added an original sound (sound_130) to the end of the file itself and it worked (sound_130 is almost 4 times the size of sound_8), but I'm still unable to play custom files this way, 22050, mono and all the stuff to no avail.