XeNTaX

Well, i've made a script. First of all you need to interleave files with ima_rejigger, then run this script to get playable .wav. Didn't work with music from your archieve, only with voices, don't know why (maybe because of 6 channels?).

I think so - ffmpeg, xmplay with vgmstream, WMP, Audition CS6 reports about unknown codec or loads without sound(silence in 6ch files).

Funny, but Windows Explorer detects audio time even for 6ch files.

Probably need inform hcs about it.

I hate to bump such an old post but I've been trying this and I'm able to get wav files I can play but they all have grinding static sound over them while I can still hear the original sound underneath.
It sounds like this was figured out but I think I missed a step or I may be using a wrong version of ima_rejigger or something. Were you actually able to get completely working files out of this or is it still being figured out?

mono and stereo files plays well if you use ima_rejigger first and my script after that. If you don't you will get that grinding sound

Oh! It worked! Thank you! I was using the wrong version of ima_rejigger and there were some problems with my batch file. Thanks a ton!
I'd also like to ask about the 6 channel files as well. Is there any way of dealing with those and getting something usable out of them? I checked around with some people and they may be used for event dialogue or something similar.

I've got some files here if you'd like to take a look.
https://www.dropbox.com/s/qmb48ahnuboqd ... s.rar?dl=0

spider91's wwise_ima_adpcm gave me the final clue, that Wwise uses one less sample per block than standard MS IMA:

MS IMA has the weird feature that every block, which is fairly small, has in its header the first sample in full 16-bit PCM form, which allows for very accurate seeking. The rest of the block is 4 byte chunks with 8 4-bit samples each, so the sample count of a block is always 8x+1.

In Wwise IMA, the final decoded sample is thrown away, and in fact that last nibble is always 0. Thus, sample count is 8x. I assume they did this because it lets them keep some buffer aligned to nice round numbers.

The upshot of which is that it is impossible to convert Wwise IMA ADPCM to standard Microsoft IMA ADPCM; there are these extra samples hanging out which throw the whole file off. There is actually a space in the extra format data for "samples per block", but I don't think many decoders care about that (sox rejects anything without that extra +1 sample-per-block, libavformat seemingly ignores it).

Anyway, I'm glad to finally be able to put this behind me and retire the old ima_rejiggers, which never worked properly.

Here's ima_rejigger5, which does the decoding to PCM and supports both RIFF and RIFX wems, so it should be usable with The Wonderful 101. It isn't super-necessary but I wanted to get some closure here.

edit;
I'm realizing belatedly that my whole digression into reinterleaving stuff with the rejiggering tools was a huge wrong turn, this IMA turns out to be more common to the stuff we see on consoles all the time than the weird +1 thing standardized in RIFF. Sorry for causing and prolonging the confusion. I hope things are correct now, they certainly sound good.

edit2:
One final thought: I may have been a little too harsh on myself, this is definitely an unusual format, somewhere between MS IMA and normal IMA. Normally when you see IMA/DVI with block headers with a sample in it, that sample is just history, used only for seeking; you have to take that history and compute a new sample from the first nibble of ADPCM data. It is a good idea that MS came up with to not waste that and actually use it as part of the stream, so it is less redundant, but in so doing they wound up with really oddly sized blocks. I think AK came along and realized the best of both worlds, as they've managed to do in such creative ways with Vorbis.

Finally a solution is found!

Credit where it is due: wwise_ima_adpcm is by Zwagoth Klaar (zabb65), whose repository of Payday 2 modding tools is found here.

I'm not sure why spider91 was distributing the .exe without the readme, but it's my fault for not looking hard enough. Oops.

Was just looking over this again due to clipping in some very loud files from EVE Online, here's the heart of the decoder in the x64 debug lib from Wwise_v2015.1.6_Build5553_SDK.Linux
What's notable is that this is a different rounding model from what ima_rejigger5 and wwise_ima_adpcm use, which is the shift-and-add from the IMA specification. There are very small differences, though with the block headers resetting state every few samples it doesn't accumulate. It looks like the noise introduced by this is down in the -50 dB range.

In any case this didn't fix my clipping problem, which is probably unavoidable. Maybe I will release a new revision of ima_rejigger to reflect this but I don't know if I'll bother.

(As an aside I'm pretty sure the adjustment done before division is unnecessary (and unwanted anyway), but the compiler probably didn't look at the constant table to figure this out and had to play it safe with signed division.)