question about ea xma and decoding process. by pepper at 4:05 PM EDT on March 22, 2010
I've given up on the pc version res files, and i found that some people have already converted files from the xbox 360 version, i just was wondering if there is a step by step guide somewhere, i have all the tools, and got a dumped iso from my friend's xbox, but the hex editing of the header never works out. I know i'm doing something wrong with either the sizes i put in, the hex format i use, how i put them in (inserting or overwriting whats already there?) etc. I just need a bit of clarification on the process.
If you could upload one of the files (or mention what game...) then maybe we could help.
I believe .res XMA files are usually EA's multistream thing, you can unpack those with ea_multi_xma. You then need to prepend a XMA header onto each resulting file (so make a new file with header3 + stream1, etc). Then you can decode the resulting files with toWav.
Found whats wrong by pepper at 7:11 PM EDT on May 10, 2010
the ea multi xma doesnt rip out the full streams in some cases, im talking about BC2 still, sorry for any confusion. heres an example:
http://www.fileize.com/files/75010f49/fb7/xma.zip
first is the original version which has an offset, I just deleted it to the 48 in a hex editor (48khz) and included that version also. it works fine, but it only does a sample amount smaller in bytes than the source. thought the pre 48 data might help so i gave the two versions.
This .res has multiple streams in it (and not the multiple simultaneous channels that ea_multi_xma is designed to handle). The three streams are at 0x1c, 0xb34, and 0xaaf0. You can tell ea_multi_xma to start from a particular offset with the -o switch.
I think it works like this: 00-03: type? or stream count? 04-07: total samples 08-0b: samples in first stream 0c-0f: samples in second stream? (2 indicates "whatever's left?") 10-13: samples in third stream
14-1B: size of upcoming stream (incl padding) 1C- : first stream (5687 samples = 0x1637)
at 0xAAE8 (0xB34 + 0x9FB4): 0000AAE8 00 00 00 00 00 00 CE 94 0000AAF0 48 00 00 0C AAE8-AAEF: size of upcoming stream (incl padding) AAF0- : third stream (116831 samples = 0x1C85F)
and 0x17984 (0xAAF0 + 0xCE94) is 4 bytes short of the end of the file (another 4 zero bytes which might just be more padding).
Another interpretation of the header is that this is all one sample but with an attack/decay (length at 08), sustain (loop type at 0c) and release (length at 10) specified (or whatever the correct terminology is for parts of a sample). The sounds themselves seem to support this interpretation.
I could make something to support this if you send along a few more files for me to play with.