Static at loop point when aligning GC-ADPCM audio

[Thealexbarney]

Continued from libertyernie/brawltools#160 from @gheskett

All that being said, the static issues that I ran into were definitely present back when I made that post in November. I was just messing around with some audio trying to replicate what was going on, and I encountered this:

The waveform at the top represents the original waveform and the middle one represents the result after making a BCSTM conversion with VGAudio. The bottom waveform represents the difference between the two, and the split in the audio represents the end loop point of the BCSTM (not the original). As you can see, there is minimal loss going on throughout the conversion (as a natural result of ADPCM compression), but all of a sudden, the last 10 samples before the loop point are problematic. While these samples may not seem like a big deal and require zooming to even see, they are still audible in the result. In this example, it's not that bad, but the one I dealt with back in November was a lot worse.

[Thealexbarney]

Hmm, interesting. I'll take a look at it if you post the file and command used.

There was a bug fixed in August that would rarely cause some static. (I found one file in 50GB of audio that triggered it) This doesn't seem related to that, however.

If I were to make a guess, is the first sample of static a multiple of 14?

[gheskett]

I actually lost the initial data that I used for that screenshot, but I managed to replicate something similar using the same original file and slightly different initial loop points. Here's an archive of the audio: http://www.mediafire.com/file/ed1zn3l8wcq7dzc/VGAudio%20Bug.zip

I actually used the GUI version of VGAudio to make the looping file rather than the command line. I opened the original file and encoded a BRSTM with DSP-ADPCM and set loop points of 204676 and 2388376 respectively. I did not touch the Advanced Options.

I've been messing around with this for a little while, but I feel like the number of corrupted samples from the end has always been around 8 or so. I do believe that the first sample has always been a multiple of 14 though. Additionally, I've personally found (but not confirmed) that the static is more noticeable when the final end loop point occurs in a spot where the audio has a greater positive/negative slope.

[Thealexbarney]

Side note first. This issue is not due to VGAudio's DSP-ADPCM alignment method of applying the alignment to already encoded ADPCM like I thought it would be.

Say we have loop points of 204676 - 2388376. Aligning to 14336 samples will give us loop points of 215040 - 2398740. VGAudio will encode through sample 2388376 and throw the original PCM audio out. It then decodes the portion of the ADPCM that needs to be copy/pasted to the end of the stream, and reencodes the new audio (in this case about 10000 samples) using the same coefficients as the encoded ADPCM stream, placing it at the end of the stream.

This has the advantage of allowing the alignment to happen after encode time, so pre-existing DSP-ADPCM files can be aligned with minimal changes instead of having to reencode the entire file.

Anyway, back to why the issue does happen.

The issue occurs because of how Nintendo's encoder encodes partial ADPCM frames. Each frame contains 14 samples. If passed fewer than 14 samples, the encoder will replace the unused samples with zeros, and encode the entire 14 samples anyway. The sudden jump to a line of zeros will mess with the ADPCM, and increase quantization noise a bit.

I had VGAudio's encoder follow this behavior as well in order to produce the same output as the official encoder. You'll see the same effect if you use that encoder too.