loveemu / snsfopt Goto Github PK

When exporting a large number of SNSF files to an SPC file, as in snsfopt -x *.minisnsf, it may produce different results than running the command one by one in a separate process. I experienced that during the creation of the SNSF for Shin Megami Tensei II.

Summary

This is a bug which is originally found in gsfopt. However, unlike GBA, it should be considered as a very rare case that the glitch actually erases necessary ROM content, because SNES hardware reads ROM data once and transfer it to audio RAM.

Snsfopt is possible to write wrong value to ROM coverage in snsflib optimization (mode -l for instance). Theoretically it might wipe the ROM data quite slightly without being noticed.

How to fix : If you worry about snsflibs that you have optimized by old snsfopt, redo the snsflib optimization with unoptimized ROM, then replace your snsflib to new one.

Occurrence condition

The mechanism of the glitch is simple. It's too stupid.

u8 * rom_coverage;
u8 * another_rom_coverage;

for (u32 offset = 0; offset < size; offset++) {
    if (rom_coverage[offset] + another_rom_coverage[offset] <= 0xff) {
        rom_coverage[offset] += another_rom_coverage[offset];
    } else {
        rom_coverage[offset] += 0xff; // wait, why += is placed here
    }
}

In words: the glitch occurs when the song A refers to a certain address once, and another song B refers to the same address at least 255 times.