SPC export assumes contiguous sample indexes

[PhoenixBound]

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

	// 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.