Secret of Evermore SPC Format

I'm trying to extract SoE BRR samples. The ROM map state 71 music related pointers (019903-0199D7). (71 songs?)

If we take one of them, first two bytes are number of 7 bytes data. As an example, 0AB2E1-0AB3D0 is same size as 0x22 * 0x07. Now for each 7 bytes AA BB CC DD EE FF GG, you get BBAA bytes at offset EEDDCC. From what I was it's either 2, 4, 6, 8 or a big amount of bytes. When it's not 2, 4, 6 or 8 bytes, it's a BRR sample (I checked 3-4 so far). It lands directly on the 1st byte of BRR data. Each BRR have though 3 bytes previous to their 1st data byte and it's often two 00 and a value like 5F or 7F. I'm not sure what this header does.

As for bytes FF GG, it's definitely a GGFF format but I can't figure it out, seems like a (RAM?) offset..

I guess the ROM map guy figured as much, maybe more. I think I might have enough to extract BRR samples but I'd like to understand more the song format, at least this data related to it. There's also the pitch modification, ADSR and looping data that might be extracted in this sequence but I'm not sure..

So if anyone has an idea about how to expand SoE music knowledge, your help is appreciated.

Edit: Update!

Edit2: More updates!

 soe-spc-data-v3.zip (224.22 KB, 321 downloads)

Code:

// offset 0AB2E1-0AB3D0

22 00  // 34 * 7 bytes
04 00 90 A7 81 38 1F   // get 4 bytes at 01A790 and ???
98 13 1C E4 81 8E 67   // get 0x1398 bytes at O1E41C (BRR sample)
04 00 94 A7 81 3C 1F
47 0A 4D F8 81 26 7B
04 00 98 A7 81 40 1F
08 1C B7 82 82 6D 85
04 00 9C A7 81 44 1F
22 08 7F 9F 82 75 A1
04 00 A0 A7 81 48 1F
C7 17 FC A7 82 97 A9
02 00 74 B0 81 A4 21
06 00 16 E4 81 5E C1
02 00 76 B0 81 A6 21
06 00 47 F8 81 64 C1
02 00 78 B0 81 A8 21
06 00 B1 82 82 6A C1
02 00 7A B0 81 AA 21
06 00 EF 9E 82 70 C1
02 00 7C B0 81 AC 21
06 00 CB A7 82 76 C1
02 00 C2 B4 81 C2 22
8A 00 F5 9E 82 7C C1
02 00 C4 B4 81 C4 22
2B 00 D1 A7 82 06 C2
02 00 50 9B 81 B8 2E
11 00 DE E3 81 31 C2
27 00 EF E3 81 42 C2
3E 00 B4 F7 81 69 C2
3F 00 F2 F7 81 A7 C2
16 00 31 F8 81 E6 C2
1D 00 94 82 82 FC C2
30 00 BF 9E 82 19 C3
2A 00 A1 A7 82 49 C3
37 00 C3 BF 82 73 C3

Pointers

Code:

// offset 019903-0199D7

BE A7 8A
E1 B2 8A
D1 B3 8A
D6 B4 8A
FE B5 8A
42 B7 8A
40 B8 8A
A0 B9 8A
7E BB 8A
5C BD 8A
56 BF 8A
D9 C0 8A
47 C2 8A
99 C3 8A
C1 C4 8A
CD C5 8A
3B C7 8A
8D C8 8A
95 CA 8A
B6 CB 8A
BE CD 8A
D8 CE 8A
FC D0 8A
04 D3 8A
1E D4 8A
90 D4 8A
60 D6 8A
50 D7 8A
EC D7 8A
8B D9 8A
CF DA 8A
1A DC 8A
37 DE 8A
35 DF 8A
A7 DF 8A
AF E1 8A
C9 E2 8A
FF E3 8A
35 E5 8A
CD E6 8A
85 E7 8A
36 E8 8A
96 E9 8A
C5 EA 8A
09 EC 8A
07 ED 8A
2F EE 8A
68 F0 8A
82 F1 8A
9C F2 8A
E0 F3 8A
E5 F4 8A
FF F5 8A
CF F7 8A
4B F9 8A
B9 FA 8A
19 FC 8A
25 FD 8A
85 FE 8A
86 80 8B
2C 82 8B
EE 83 8B
16 85 8B
BC 86 8B
7E 88 8B
E9 88 8B
62 89 8B
44 8A 8B
6C 8B 8B
4A 8D 8B
8E 8E 8B

Wow, that's odd. Maybe because it was coded outside of Square in Japan they used some sort of different SPC code and not the standard Square SPC core?

Wow, that's odd.  Maybe because it was coded outside of Square in Japan they used some sort of different SPC code and not the standard Square SPC core?

The SPC core is probably same revision as games released the same year or so, maybe with minor differences, it's just the way to fetch the data that is odd. I will know when I get the pitch modification 2 bytes data. While the looping data is self explanatory and ADSR data is a SPC-700 fixed 2 bytes format, I suspect the pitch modification data might not behave the same on different SPC core revisions. It's hard to tell what the data do but it look it differ from games to games.

I've looked at FF6 SPC disassembly and 1st byte affect the Master Pitch Multiplier and 2nd byte affect the Master Pitch Multiplier envelope change rate. I don't know yet as an example how changing from E0 to A0 the 1st byte do on the actual pitch but the behavior could be different from games to games.

The most obvious difference is FF4 where the pitch data is 1 byte and the absence of ADSR data for instruments.

Wow, that's odd.  Maybe because it was coded outside of Square in Japan they used some sort of different SPC code and not the standard Square SPC core?

The SPC core is probably same revision as games released the same year or so, maybe with minor differences, it's just the way to fetch the data that is odd. I will know when I get the pitch modification 2 bytes data. While the looping data is self explanatory and ADSR data is a SPC-700 fixed 2 bytes format, I suspect the pitch modification data might not behave the same on different SPC core revisions. It's hard to tell what the data do but it look it differ from games to games.

I've looked at FF6 SPC disassembly and 1st byte affect the Master Pitch Multiplier and 2nd byte affect the Master Pitch Multiplier envelope change rate. I don't know yet as an example how changing from E0 to A0 the 1st byte do on the actual pitch but the behavior could be different from games to games.

The most obvious difference is FF4 where the pitch data is 1 byte and the absence of ADSR data for instruments.

That makes sense actually.

I've generated a disassembly with what I knew, and assumed for the document in a somewhat lazy way that last two bytes of the 7 bytes format was a RAM offset. I've also located the SPC routines which are included as well. Now the hardest part will be identifying what the fetched data by a 7 bytes command actually mean. More precisely if ADSR, pitch and loop data is somewhere there. For the disassembly I also just assumed any byte fetch of more than 0xFF bytes was a BRR sample, it is not the most precise way but I have no other way for the moment to draw a line.

Edit: New version with BRR samples detection and better formatting!

Edit2: Fixed an error preventing display of 1/3 of all songs.

Edit3: Fixed more stuff related to BRR data!

Edit4: More polishing and formatting.

 soe-spc-data-v3.zip (224.22 KB, 199 downloads)