A few of the files are not IMA (2746867.wem and 554404705.wem), but they are just PCM, any player should be able to play them if you just rename the file .wav.

It's IMA/DVI ADPCM, nibble interleave. Here's a quick (but slow) Python 2.x decoder. Run as python cars.py input.wav output.wav #!/usr/bin/python from io import open from sys import argv from struct import unpack, pack from math import floor IMA_Scale = \ [ 7, 8, 9, 10, 11, 12, 13, 14, 16, 17, 19, 2...

The solution is to force unmodified packets: ww2ogg 660566263.wav --no-mod-packets --pcb packed_codebooks_aoTuV_603.bin This is mentioned in the Troubleshooting section of the readme, though this switch was only introduced in ww2ogg 0.24. I discovered that the logic I was using to detect mod packets...

Only do this if the audio sounds like it is running too slow, otherwise just changing the sample rate is going to speed it up, but it won't fix your quality problem.

He wants to go the other way, vgmstream only outputs PCM. I believe the original SDK encoder for these tracks is called dtkmake or trkmake, maybe you can find that somewhere online. edit: I won't link directly to it here, but it looks like emuparadise has it, in GameCube.7z it's "NINTENDO GameC...

There are a few decoders for Wwise's codec 2 files, wwise_ima_adpcm (inside sound_converter_v1.15.zip , which can also encode) and my own ima_rejigger5 . I haven't tested this with your example files, but I expect it to work. It turns out that these can't be just rewritten as codec 11 (see my explan...

Bytes 0x14 and 0x15 (technically 4 bytes after the "fmt " chunk identifier) in a RIFF WAVE file are the "format tag", which says what encoding or format the audio data uses. This is a 16 bit little-endian value; 16 bits means it takes two bytes (8 bits in a byte), little endian m...

Ah, ok, it looks like that is the PCM format spider91 is describing in his post. The code he gave is a QuickBMS script, you can get QuickBMS here: http://aluigi.altervista.org/quickbms.htm Save spider91's code to wem.bms, put that in a directory with quickbms.exe and the .wems, and try running this ...

Everything up to #4 is good, sounds like it doesn't use Vorbis (given the error from ww2ogg). You should delete the .wems at this point, though, in case the steps you took in #5 messed up the files somehow; in particular ima_rejigger2 modifies the original input file. So try recreating the .wem file...

ffmpeg's libavcodec has WMA Pro support that does XMA and XMA2 (RIFF codec 0x165 and 0x166): https://github.com/FFmpeg/FFmpeg/blob/54ccaaeb2b93e19d2a19267db1781bc9d5d36f27/libavcodec/wmaprodec.c#L294 XMA is essentially just WMA Pro with decode_flags = 0x10d6, though the blocking is different (especi...

I think you should just need to run the RIFF/RIFX scanner BMS on the .dat, or just directly on the .cpk.

I'm not really following you... if you extract the RIFX at 0x100 in voe027_us.dat, you can decode that with ima_rejigger5 for a noisy but seemingly complete voice sample. Actually there are a few in there, also at 0x4300 and 0x5580. Attached is the decoded wavs.

Coefs definitely aren't in that file.

Here's a Ruby script that seems to work for fn in ARGV do File.open(fn, mode='rb') do |f| print fn, ': ' magic, data_size, six, zero1, id, neg1, sample_rate, zero2, zero3 = f.read(0x24).unpack('a4 L<4 l< L<3') raise 'Missing SECT' unless magic == 'SECT' raise 'unknown values differ' unless six == 6 ...

It looks like Microsoft IMA (RIFF WAVE codec 0x11) starting at 0x24, block size 0x24, I'll try to write a quick converter but that might be enough to figure it out if I don't get to it.