I tried to contact Wwise to ask them how to edit already created .wwise files in case I made a mistake or need to further add something (obviously a fake story just to know how to import those files :P ) but their main contact thing requires you to be a licensed customer (aka paying cash for that)...so no... But would be fun to know what they say to that. Maybe paying customers get additional tools to edit those files, idk, free license Wwise tools and SDK have no such option.
This is quite a strange problem. It's not like ww2ogg can't decode the files -- they're quite listenable -- it just gives out during the conversion process.
At 256K into this file (0x40000 in File0001.wwise) there is a " DNS" header (little endian "SND "). This is approximately where ww2ogg explodes when trying to parse this file. Allow me to explain a bit about game audio and memory subsystems as background for my understanding of the issue:
In general a game wants to load up all the crap for one stage at the same time; this includes any sound effects it'll be using, sequences if there's sequenced music, instrument samples, etc. Compared to dynamically loading stuff as needed, loading a whole chunk like this, even if some of it won't be used, has a lot of benefits, importantly:
1) predictable load time (no seeking, no occasionally things being much faster or slower if the expected item was/wasn't already loaded)
2) optimal use of space (memory fragmentation is a non-issue)
This data is called "in-memory" or "resident".
Of course in general it is not possible to get everything in memory at once. The next best thing is streamed data: if we know we'll be needing some constant bitrate of video, or audio, only for as long as it takes to play it, we can set aside a reasonably-sized buffer for a portion of the data and load/play/load/play/etc. This preserves the benefits mentioned above: load time happens but it can be amortized over the whole playback so as to be unnoticeable, we only need to reserve as much space as we need to be confident that the buffer won't underrun.
Often the audio middleware handles in-memory and streamed samples with a lot of common code. The file formats are often similar or identical, though with in-memory stuff you'll find those files packed into larger "sound bank" files that are loaded at once. Most middleware will require streamed audio to be represented by header data in sound banks, even if the actual audio data is stored elsewhere on the disc and only streamed in on-demand.
Streaming has a big problem, though: starting up a stream is not instantaneous, as the data has to be prebuffered. If the engine wasn't expecting to play a streamed sound there could be a large delay before it starts while it initially fills the buffer from scratch.
A hybrid approach is sometimes used, and I think this is the difficulty you are encountering here: The in-memory sound bank contains the beginning of the audio file, the header data and a second or so of audio data, and the rest is located in another file elsewhere on disc to be streamed in. The resident beginning of the file can be played immediately as it is already in memory, and ideally this will give enough time for the streaming to get going.
This is a fine engineering solution but it makes things a mess for us trying to read the audio! In the sound bank we can find the very beginning of the sound file but the rest may be somewhere entirely different on the disc. For systems like wwise where everything is numbered with hash codes it is hard to figure this out with inspection. What you are seeing here is that the RIFF is actually truncated, the rest of it lives somewhere else, and there is something else stuffed in the sound bank next.
In particular this is frustrating because the rest of the audio data may be stuck somewhere with no header! If we knew more about how the whole wwise bank system works it might be easier to locate this headless data.