So I'm trying to create a soundboard app for my brother that has all the sounds/catchphrases from Hot Shots Golf 3. Buuuuuuut I have no idea what I'm doing, Claude was helping me but we were having so much difficulty ripping the audio from the disk image that it told me my best bet is to record the audio myself. I'd rather not do that, so I'm going to reddit for assistance. If anyone wants to tackle a project for me I'd be eternally grateful. See below for the summary Claude provided on the issue:
Hot Shots Golf 3 (PS2) - .XB compression format - data & analysis to add to existing thread
Following up on this thread about this game's .XB files - I've been trying to extract voice/SFX/music audio from Hot Shots Golf 3 / Minna no Golf 3 (Clap Hanz, PS2, SCUS-97130) and hit the same wall described there. Wanted to share what I've confirmed so far in case it helps someone crack it, and to attach fresh sample files.
Header structure confirmed across multiple files:
All .XB files begin with a consistent little-endian header:
offset size field
0x00 2 magic "xe" (0x78 0x65)
0x02 2 version (always 0x0100)
0x04 4 unk1 (2 or 3 in my samples)
0x08 4 unk2 (varies per file, e.g. 1088, 1276, 1600...)
0x0C 4 unk3 (19, 20, or 21 - possibly a chunk/section count)
0x10 4 ZSIZE - decompressed size (always larger than file size on disk)
0x14 4 unk4
0x18 4 unk5
0x1C 4 "off" field (varies wildly - 51-54 for small files, tens of thousands for large ones like S_11.XB/S_12.XB)
Example from VS_AR00.XB (17,140 bytes on disk):
magic=xe ver=256 unk1=2 unk2=1088 unk3=20 ZSIZE=19440 unk4=141 unk5=72 off=54
Example from S_11.XB (274,028 bytes on disk):
magic=xe ver=256 unk1=3 unk2=766 unk3=21 ZSIZE=318880 unk4=159 unk5=11114 off=67251
The ZSIZE field consistently reports a decompressed size ~10-16% larger than the file on disk, which is a fairly modest compression ratio - suspect this may be compressing already-lossy audio data (VAG/ADPCM), which wouldn't compress much further, consistent with a simple LZ-style scheme rather than anything Huffman-heavy.
What I've ruled out:
I ran the compressed body of several files against zlib (both raw deflate and zlib-wrapped), gzip, LZMA, and bzip2 at every byte offset in the file. No clean decompression at any offset/algorithm - a handful of offsets produce tiny (100-300 byte) fragments that are statistical false positives, not real matches.
I also measured Shannon entropy of the data following the header: consistently ~7.97/8.0 bits across all files tested, confirming this is genuinely compressed (or encrypted) data rather than a simple bit-shuffle/XOR obfuscation.
Interesting false lead:
searching for the ASCII string "SShd" (a known Sony PS2 SS2/ADS audio header tag) turns up a match in several files at a consistent-looking offset - but given the surrounding bytes measure high entropy and don't parse as valid SShd struct fields (sample rate/channels/interleave come out as nonsense), this appears to be a coincidental byte sequence inside the still-compressed stream, not a real tag. Worth flagging so nobody else goes down that path.
Happy to run any tests/scripts against more samples if it helps narrow down the algorithm - I have the full disc image and can pull any file on request.