EBMusEd's SPC export code assumes that all the samples in a song have sequential IDs:
|
// Copy sample data and pointers... |
|
// Remap sample data to new locations to repack them |
|
struct { |
|
WORD src, len, dst; |
|
} sampleMap [NUM_INSTRUMENTS]; |
|
WORD offset = 0; |
|
for (unsigned int i = 0; i < NUM_INSTRUMENTS && sample_pointers[i].start < 0xFF00 && sample_pointers[i].start > 0xFF; i++) |
This is not generally true, even if we look at just EarthBound. Exporting an SPC of song 0x9D in vanilla EarthBound (the attract mode, using packs 02 and 99) has a gap in sample and instrument IDs between the primary and secondary pack; there's no sample/instrument 09 or 0A. This loop condition needs to be updated to not assume that.
It also bothers me that the loop only checks NUM_INSTRUMENTS (80) samples, instead of countof(sample_pointers) (128)... together with discontinuous sample IDs, this could theoretically cause issues. But they're purely theoretical and the only reasons I can think of (really crazy manual sound effect programming) don't apply to previewing music via SPC export.
EBMusEd's SPC export code assumes that all the samples in a song have sequential IDs:
ebmused/src/main.c
Lines 484 to 490 in 272b012
This is not generally true, even if we look at just EarthBound. Exporting an SPC of song 0x9D in vanilla EarthBound (the attract mode, using packs 02 and 99) has a gap in sample and instrument IDs between the primary and secondary pack; there's no sample/instrument 09 or 0A. This loop condition needs to be updated to not assume that.
It also bothers me that the loop only checks
NUM_INSTRUMENTS(80) samples, instead ofcountof(sample_pointers)(128)... together with discontinuous sample IDs, this could theoretically cause issues. But they're purely theoretical and the only reasons I can think of (really crazy manual sound effect programming) don't apply to previewing music via SPC export.