I think the music is probably the DAT4 chunks. DAT4 header: 00-03: DAT4 (silencio) 04-07: byte size of data 08-0b: channels 0c-0f: sample rate 10 blah blah maybe loop stuff padding blah 800-..: "DAT4" data
The data looks strangely familiar, particularly the A-Z byte, but I can't remember where I've seen it. Looks like IMA, anyway, header looks like: 0-1: initial history (first sample?) 2 : initial step 3 : A through Z
Frames are 0x20 bytes, stereo frames are interleaved.
Ah yes, and in fact I made the same comment over there. I'll try to cobble together some support eventually. I don't think GENH will cut it for the IMA as it is now.
edited 3:48 AM EDT September 23, 2009
by pietastesgood at 11:51 AM EDT on September 23, 2009
I tried out a quick hack, that file_002.musx at least works with something like NDS IMA if you ignore that 3rd byte in the frame header (ordinarily we assume that's the high byte of the step index, though that's always zero since frame index only goes up to 88) and read the nibbles in reverse order (high nibble first).
So how obvious are the ngca files, I don't really know what to do with them/how to decode them from it. Im kinda inexperienced with nintendo audio formats.
Finally got this supported somewhat in vgmstream as of r718. It expects the files to be called .musx. The extractor I used calls them .sfx so I had to rename them (this is another form the Eurocom's MUSX format seen in several other places). Only the DAT4 form is supported, as the NGCA only seems to be used in multi-sound banks.