Working with RAW VAG (Compressed ADPCM) packs in games

[SlavaVlasov]

Hello. There was a question regarding the correct packaging of modified ADPCM-Compressed Sounds (which are loaded into RAM) back into the game. How I currently resolve this issue:

1. I extract the file from the image in which the RAW VAG sounds are supposedly located (hereinafter - “VAG-Pack”).
2. I extract sounds from “VAG-Pack” using the VGM Toolbox (Sony ADPCM Extractor).
3. I listen to single VAGs in MFAudio.
4. I convert VAGs to WAV through MFAudio.
5. I create a new modified sound in Audacity, observing the same length and sound parameters (frequency, bit depth, number of channels) and save it in the new WAV.
6. I am converting a new WAV to RAW Compressed ADPCM through MFAudio
7. Checking that the sizes of the original and the new VAG coincide.
8. I open the “VAG-Pack” and the one extracted single RAW VAG in HxD.
9. Based on the data at the beginning of a source single VAG, I look for its location in “VAG-Pack”.
10. Through HxD I replace the data in the “VAG-Pack” (on the offset, where the desired file beginning) with the data from the new VAG.
11. Then I check the result in PSound.

So: sometimes the following problems are encountered:
1. When scanning again, the PSound may not find the modified file (found fewer files than in the original).
2. While playing in PSound, modified file sometimes ends with a “click” (an eerie tone signal may appear in the game).
3. Rarely, but it happens that a game plays two files in sequence (is the end of the "77" byte sequence is erased?)
4. Sometimes the sound after playing it in the game causes common sound glitches (from a barely noticeable tone of the signal, increasing in volume when the modified file is played repeatedly to the roughness of the whole sound, even the original XA music).

While I deal with glitches very simply: since a glitch occurs at the end of the file, I just copy 2-4 lines of 16 bytes from the end of the original file to the end of the modified one. Most often it helps, but sometimes not. But I understand that this is not the right way out. I suppose that the problem is not even in reverse packing (after all, the file sizes are the same), but in the encoding of MFAudio in Compressed ADPCM. Maybe there are some other ways to work with RAW ADPCM and their packs?

[paulyc]

Per https://www.psdevwiki.com/ps3/Multimedi ... _Tools#VAG :

Because ADPCM uses sample blocks that are aligned one after the other, a wave compressed with ADPCM may have an unfinished, partial block at its end. The ADPCM decoder generates silence for the remainder of this partial block, which keeps the wave from looping seamlessly.

So what may be causing glitches is if the size of the decoded PCM data is not an integer multiple of the sound engine's buffer size. When it isn't, the GIGO Principle (Garbage In-Garbage Out) takes over: the decoder will pad out the available space with zeros, or garbage (like the end of the previous block, or random numbers), and the resulting garbage-out may not be audible if the sample only plays one time, but it will be if it starts playing again from the beginning.

Tricky part is, every game engine, and sometimes even different games using the same engine, has a different buffer size that can only be determined empirically. This generally corresponds to the "interleave" or "block" size you see in VB encoder/decoder settings. As an example, the PS2 GTA games have a interleave/block size of 0x2000 bytes of 16-byte-per-channel ADPCM samples, so 256 stereo or 512 mono samples. Since each ADPCM sample decodes to 28 16-bit PCM samples (56 bytes), so multiply the interleave size by 56/16 to get 0x7000 bytes of PCM data corresponding to the block.

So the size in bytes of the WAV/PCM input should be an integer multiple of 0x7000 bytes, (or for 16-bit stereo, 0x3800 bytes per channel, 0x1c00 samples per channel), or in terms of time at a sample rate of 32000 Hz, an integer multiple of 224ms so that when decoded again the PCM samples will fill the buffer completely. (If the interleave size is 0, then the input PCM data should at least be a multiple of 56 bytes since less than 56 bytes will encode to an ADPCM sample ending in garbage...)