You can download the latest precompiled version of the tools from here.
Unpackers and modding tools for the GameCube version of the «Sphinx and the Cursed Mummy» game.
The game files are all packed inside an uncompressed container file called Filelist.000. The game engine actually reads a small binary descriptor file called Filelist.bin,
which contains a table mapping various internal hash codes with their original internal filenames, lengths and (one or more) container numbers with their respective offset/position inside every container. Those packed files tend to appear sector-aligned, and they are often duplicated in two or more places inside of the same container file to improve disk seek times.
As far as I can, tell only the PlayStation 2 version of the game splits the game files in more than one container (Filelist.000 and Filelist.001), also the PlayStation 2 and XBOX fields are stored in reversed byte-order (little-endian), while GameCube uses big-endian.
This tool should comply with all the different variants.
I have sucessfully extracted the contents of the GameCube, PlayStation 2 and XBOX versions.
My extractor is written in simple C99 with some UNIX functions, which require Linux, Mac or BSD to compile, even if you could compile it as a Windows executable with some small changes.
Compile the C file like this with your favourite Linux compiler (GCC or Clang):
gcc sphinx_filelistbin_extract.c -o sphinx_filelistbin_extractCopy all the Filelist.bin, Filelist.000, ... files from your original game disk. That's all you need.
Place them in the same folder than the extractor. Run the extractor in your Terminal:
./sphinx_filelistbin_extract Filelist.binThe unpacked files will appear in the current directory as subfolders named as the original Windows hard drive letters (either x:, or d:) used by Eurocom.
Here is a rundown of the unpacked contents of the game. Sorted by extension.
*.h files: Text-based C/C++ headers from the original source code. They are there to map hexadecimal hashcodes to human-readable tags (of EDB files, items, songs, sounds, levels and other assets) used by the programmers.
Probably autogenerated from some internal tool and included there to be read by the in-game editor/viewer.
*.edb files: General-purpose workhorse proprietary binary container format. Extension probably derived from Engine/Eurocom database. Non-exhaustive list of things you can find inside:
*.sfx files: Binary Sound effect container. Used also by music tracks.
All formats are documented as 010 Editor binary templates.
[X] Filelist.bin: Finished, format completely documented in sphinx_filelistbin.bt.
[ ] EDB: Initial header, looks like there's a table with different subsections, in sphinx_edb.bt. So far seems to be the most complex format here, and for a reason.
[X] SFX: Header, properties offset/size and soundbank offset/size, in sphinx_sfx.bt. Actual sample encoding is still work in progress for most platforms, even if I'm pretty sure that they all use some form of hardware-accelerated ADCPM, which was the preferred audio codec in those consoles. Every console seems to use custom platform-dependent sound encoding depending on the target DSP and endianess. Opening a GameCube sound bank as raw VOX ADCPM outputs mostly correct music, but with a lot of headache-inducing noise.
Update: I have managed to demux and convert the GameCube byte-interleaved IMA ADPCM stereo music data (4 bits per sample at 32000 Hz) into a playable format. Take a look to sphinx_sfx_gcn_demux.py, and its companion batch script sphinx_sfx_gcn_demux_convert.sh to convert the entire soundtrack into your favourite audio container/codec.
Standard sound effects are stored in a similar way but in mono (a single ADPCM channel instead of two, byte-interlaced), modifying the Python script to demux the mono soundbanks should be easy, just comment-out the byte-splitting (so all bytes go to the right channel) and subsequent second (left) channel code. Implementation is left as an exercise for the reader.