The soundtools are only loading soundbanks. The rest of the data is unaccounted for. The issue is that nobody's made up a complete ROM map for the game yet, of the form:
0x0 bin bootstrap.bin
0x1000 bin system.bin
0x1DCC0 bin game-1.bin
0xC5BF0 bin game-2.bin
So in fact you don't have a complete set of tables, and no extractor, as of yet, will automatically work that out. Sadly, you'll probably have to disassemble the ROM to build that list yourself.
There's obviously the text table, and that really will let you split all the strings and (theoretically) reorgainize/resize them. There's also the image tables, and you should easily be able to parse out the simple non-indexed images without much effort. The indexed ones use a more complicated table, but again somewhat trivial.
Without knowing how the game is set up stats may be hardcoded in ASM or could be in a table. I'd lean toward the first over the second, but without disassembly it's hard to know for certain.
Then you get into something interesting.
If you notice, there's no actual display lists besides a token base for the font. That's because this title, like Eurocom titles, generates its display lists at runtime from instruction lists. Naturally, that also means they aren't using the typical N64 vertex tables either. Usually they'd be set up like:
0x0 2 xpos
0x2 2 ypos
0x4 2 zpos
0x6 2 RESERVED
0x8 2 s (horizontal image mapping position)
0xA 2 t (vertical " " ")
0xC 4 vertex color or normal depending on mode
Without knowing where the build instructions are it's impossible to know what the data format's going to look like. For instance, Eurocom's microcode used floating-point numbers for vertices, omitted vertex color except as a special case, had a table of shorts for image mapping, and a bunch of strange overrides to play tricks with palette swapping. It was a real pain to turn it into 'normal' N64 display lists
So, this could either make it easier or much harder to eventually rip/view/replace models. Either way, it's what they used and you're stuck with it.
You'll need to do the disassembly work anyway since replacing tables will require changing the addresses they're called from in ASM. If you move something or expand something, everything that shifts will need to be readdressed. That's an easy thing to automate though.
Anyway, this game's never been poked much so you'll have to disassemble a fair amount of it yourself. It's not going to do the work for you ;*) The real trick is to use a debugger and breakpoint on each table access. Watch how they call each other, what the offsets are for each table's subsequent calls, and from the data they use determine their uses.
It's a large but well orgainized game and shouldn't give you too many problems.