Dante's Inferno XMA Audio Help.

[OrangeC]

Hello this is from the demo of the game, this looks like pure xma audio however the file header doesn't mention anything useful and i appear to be what i see the sample rate but it still doesn't work with it corrected in the xma header. Little help in figuring this one out, i don't think its multichannel either.

http://www.megaupload.com/?d=BX94R4DT

[hcs]

Cut off the first 0x20 bytes and run it through unpack1943. I guess it's EA's own special brand of XMA. Wonder if their layer 3 stuff is similar in principle...

[pietastesgood]

Aha, thanks HCS!

[OrangeC]

Your a Life saver man thanks.

EDIT: Audio seems to have some glitches though when i converted with 48hz assuming its the correct rate.

heres one.
http://www.mediafire.com/?imlt5mxtt51

[cryogen]

[cryogen]

I converted most of them to wav, a real pain in the ass anyway.
I noticed that all the english vocals of the game work good,they convert without glitches, the other regions work bad, there are lot of glitches after the conversion(it happen here only with france and spain vocals, but who cares when I can have them in english? ).
For who is interested u have to use ToWav for the final conversion.
All the music and atmos sounds seems to work good
One last thing, u don't have to cut the first 0x20 but another value and they work...
Again thx to Luigi for his script...

Ops, another last thing, some extracted files(after Luigi's script) seems to be containers of other files....

yo

[hcs]

If you still have the files around could you upload one of the other language files? I'd like to see why they're glitchy.

[cryogen]

The contents of this post was deleted because of possible forum rules violation.

[hcs]

Woke up with the solution to this...
I think the situation here, and what also may have been the case in Battlefield: Bad Company (which I never quite understood), is that EA's XMA packing encodes sets of samples independently, but they don't always fit in a single packet. In XMA in general:
A packet will contain some number of frames, and because they don't pack exactly into the packet one frame will overflow into the next packet, so the first real frame of the packet will start at some offset in the packet, this is stored in the packet header as the "skip bits" because it's how many bits from the previous packet you need to skip to actually start decoding. In the last packet in a stream in XMA1 the skip bits value may be 16384, which is invalid (a packet has 16380 bytes of payload [2k-4 byte header], so this would skip the entire packet and more which makes no sense). XMA2 has a similar mechanism, though it uses 32767 (all bits of "skip bits" set), but the message is the same: rather than skipping bits in this packet to get to the first frame, there is *no* frame starting in this packet, so the decoder can skip it. This happens when the last packet only has the overflow of a frame rather than any frames of its own.

So why is this a problem?

EA seems to encode fixed groups of samples entirely independently. In the France file this seems to be 4608 samples at a time (9 frames at 512 samples each). Ordinarily they choose this value such that the encoded frames will always fit in a single packet. However in this France file (and in Battlefield:Bad Company, I went back and checked) it doesn't always fit, so the frames overflow into an additional packet. The trouble is that toWav apparently doesn't support the "skip whole packet" mechanism I described above, either in XMA1 or XMA2. In XMA2 we encountered this issue a lot more often because even normally encoded XMA2 had this stream end a lot, at the end of blocks. XMA1 has no concept of blocks, though, so usually you'd only see this at the end of a stream so toWav messing up on it wouldn't matter. With these files, though, it occurs all throughout the stream, so you get little skips.

The generally available xmaencode seems to properly support this for XMA1. So the workaround is to use the method I describe here (once you've cut off the 0x20 byte header):
http://aluigi.freeforums.org/post9118.html#p9118

I'm glad to finally understand why this worked in xmaencode but not in toWav. Unfortunately this involves some crap to create a more valid .xma file, more work than simply sticking a header on it. The real solution would be for xma_test to support rebuilding XMA1 streams the same way I support rebuilding XMA2 streams as XMA1, so that everything is packed contiguously and this issue doesn't come up (as well as correcting the sequence numbers). I also guess I need to remove the "Unknown = 0, expected 2" warning on 16384-skip packets; I take it this is yet another way of signaling end-of-stream.

[hcs]

Figure this is worth another post:
I've updated xma_test (0.7) to be able to rebuild XMA1 streams as well, like:

Code: Select all

xma_test infile -1 -r outfile

I also updated ea_multi_xma (0.1), it should now work on all of these EA-packed XMAs. It's also a lot simpler to use, and it works out the number of streams, so it should work on the 1, 2 and 3 stream files in Dante's Inferno, as well as all the old stuff that unpack1943 worked with (which is now deprecated). It makes up file names by putting _streamN on the end of the input file name. It also comes with a -o option, so you can specify a header to skip, this saves the trouble of cutting off 0x20 bytes all the time.

So now for these infernal files you do:

1. ea_multi_xma to unpack the streams
2. xma_test to rebuild each stream as usable XMA
3. add header, decode w/ towav

[cryogen]

WOW!!!THX this will be a long night for me .....
Well done I'm going to try your tools...later

[OrangeC]

This might interest most of you.

I have created batches mostly for some of hcs tools needed to decode dante's inferno.

ea_multi_xma.bat > use this to automatically extract all streams from the packed files. NOTE: you have to specify the offset for some files in the bat, but the default is 20, like most of the files, only like 60 of those have different offsets, it shouldn't be too hard to filter those out.

xma_parse.bat> this is intended to rebuild the unpacked xma2 streams to xma, it outputs the fixed streams to blah.out.

I also included an addXMAheader bms script along with quickbms latest version and a batch file to automatically add a stereo xma header to the fixed streams, ready for decoding with towav. Thanks for alphatwentythree on the script and batch help.

http://www.mediafire.com/?dobmmymtmzj

This should greatly reduce the time by half so it can relieve the stress of manual labor for these thousands of files.

thanks to hcs for the additional batch help.

[norm]

I also included an addXMAheader bms script along with quickbms latest version and a batch file to automatically add a stereo xma header to the fixed streams, ready for decoding with towav. Thanks for alphatwentythree on the script and batch help.

Could you say how you go about changing the header file with this script? I need to add mono headers for files from Bad Company 2. (http://hcs64.com/files/xma_header_mono.zip)

I looked in the addXMARIFFHeader.bms but don't see where you specify anything.

Thanks to hcs on his great work.

EDIT: Nevermind. I compared the XMA mono file and saw it was practically identical to the bms script except for one byte. I changed it from 02 to 01.

set MEMORY_FILE binary "\x52\x49\x46\x46\xb8\x59\xa7\x00\x57\x41\x56\x45\x66\x6d\x74\x20\x20\x00\x00\x00\x65\x01\x10\x00\xd6\x10\x00\x00\x01\x00\x00\x03\xe3\x9a\x00\x00\x80\xbb\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\x02\x00\x64\x61\x74\x61\x00\x58\xa7\x00"

[AlphaTwentyThree]

The contents of this post was deleted because of possible forum rules violation.

[OrangeC]

Wow thanks alpha for the tool pack.