Super Metroid Music Hacking Guide

[DSO]

Music Hacking Guide

[spoiler=Part 1: Basic overview]
1. SPC700 information
The SPC700 chip is responsible for music and SFX in SNES games. It has 8 channels, all of which are capable of playing independent sounds.The SPC only has a tiny boot ROM built in and the actual sound engine and sound samples, in other words all of the data it uses must be transfered from the game ROM and fit its 64k of RAM (0000-FFFF, henceforth refered to as ARAM). In Super Metroid, the main engine that gets transfered at the start of the game is located at CF:8108.

Basic overview of Super Metroid ARAM contents:
0000-04FF   Song and channel configuration parameters.
0500-14FF   Echo buffer, the size of the echo buffer determines the length of the echo. Super Metroid's is tiny.
1500-56E1   Main engine. Gigantic compared to most games.
1E66-1E7F   Pitch table
581E-6BFF   Song start addresses followed by song note data.
6C00-6CFF   Instrument definitions, 6 byte entries, consisting of Sample #, ADSR1, ADSR2, Gain, and then a 2 byte pitch multiplier
6D00-6DFF Sample table, 4 byte entries, first sample data start location and then sample loop point.
6E00-FFFF   Sample data

We will cover most of this. Some of it doesn't need covering.

2. Echo buffer information
There are three commands involving the echo buffer that we will learn later once we get to note data. However, I wish to put a note of warning here. The echo length as specified by one of those commands can only be 01 or 02, due to the tiny size of Super Metroid's buffer here. This was a major pitfall for me early on, because SNES9X 1.51 (which I was using at the time) does not properly emulate the behavior of the echo buffer. The main engine is right after the echo buffer in RAM, and thus in any accurate emulator, an echo length greater than 02 will set the buffer to overwrite the main engine. In SNES9X 1.51, the echo buffer was not mapped with the rest of ARAM, leading me to think at the time you could use values greater than 02. For instance, https://dl.dropboxusercontent.com/u/10779677/FadedMemoriesQuiet.mp3 was made using an echo length of 0A! Needless to say, unless you're running SNES9X 1.51 or earlier, this will crash your game (and also be unplayable on real console). It is limiting, but we have to deal with what we've got.

3. Pitch table
The pitch table contains 13 entries.

085F 08DE 0965 09F4 0A8C 0B2C 0BD6 0C8B 0D4A 0E14 0EEA 0FCD 10BE

For those unfamiliar with music theory, there are twelve different notes in western music. A, Bb (B-flat), B, C, Db, D, Eb, E, F, Gb, G, Ab. Standard concert pitch A is defined as a sound with a frequency of 440 hz. When rising, each note in the list is just slightly less than 1.06 times higher in pitch than the previous one. However, once you double in pitch, the note to our ears possesses the same quality musically as the starting note. Thus 440 hz and 880 hz are both 'A' notes. Why am I bringing this up?

Well, in the original game this table is never changed. But what if you could think of a situation where you did want to change it? What would it sound like if you brought everything down an octave by dividing the value of each entry in half?

https://dl.dropboxusercontent.com/u/10779677/WSDownOctave.wmv

Now while going down a full octave is a bit extreme, maybe you just want to make everything a few notes lower in pitch whenever Samus enters water? Just multiply or divide the values by 1.06 (or 1.0595 if you want to be really precise) for each note you want to go down. Just be aware, pitch in the SPC chip can only go up or down so far and it will loop around from low to high and high to low. (Note the pause screen in the down octave vid, where lowering the pitch multipliers made one of the pause screen sounds much higher!) This isn't really that important, I just wanted to give you the option.

Now we get into the really juicy stuff!

4. How Super Metroid transfers data to ARAM

What are song start addresses? You're already familiar with them, in a sense. It's a table of two byte entries, each containing the start location for some song data. How are you familiar with them?



That's right! It's the 'song select' in SMILE! But why mention this now? Because this picture can help you understand how data is transfered. Both dropdown lists in the picture are important. Consider the first one. It's a table of 3 byte entries located right before the debug room header in the original ROM. Because pictures are helpful:



This tells us that the data for song collection 00 starts at CF:8000, song collection 03 at D0:E20D, and so on. SMILE does not support other values natively, but if you expand the table by overwriting the debug room header (8F:E82C), the game works just fine and you can use a hex editor to set the room to use collection 4B or 4E or however far you want to go (it can only be 1 byte though, so you can't go beyond FF).

So, what does the song collection contain? Well, the song data! Aka everything the game needs for that song, this includes NOTE DATA (Usually 582C - 6BFF), INSTRUMENT DEFINITIONS, SAMPLE TABLE and SAMPLES! There is a specific jump to subroutine command the game uses to load the selected collection into ARAM. The following is ASM:

Code Select Expand


LDA #$FF12         ;Load 12 song data aka Red Brinstar
JSL $808FC1
LDA #$0005         ;Load song track 5 (First track from song data)
JSL $808FC1

The same jump (JSL $808FC1) is used both to load song data (done first) and then to tell it which set of note data to play. It knows which is which by the high byte, if you want to load song data, the value loaded prior to the JSL must be #$FFxx, if you want to tell it which track to play, the value loaded before the JSL must be #$00xx.

You ever notice how some song collections use 06 like Maridia, but others will crash? Well, note data is pretty much always right after the track pointers. Some song collections have 05 has the final pointer, so if you use 06 the game tries to read the start of note data as a pointer and hence the crash. BTW, while SMILE's drop down only shows up to 07 in the track list, if you create the track pointers for it the jump table can handle up to 80 different pointers! I've stayed with SMILE 2.5 for a long time, but I really hope SMILE JX will be able to transcend these unneeded artificial barriers on these tables that 2.5 has, so I won't have to break out the hex editor because I want to use track 09 on song collection 4E... but I digress.

So, how exactly does the data get transfered? It does it in blocks. Let's look at one of the song collection pointers, let's say the one that points to D0:E20D.

At first there is a block pointer, made of 2 words (4 bytes). The first is how many bytes to transfer.



This equals 0x40 bytes.

The second is where in ARAM the bytes get transfered to.



The bytes get transferred to 6D60 in ARAM. That means that the next 0x40 bytes...



Are part of the sample table for this song! These bytes will get transfered from ROM into ARAM starting at 6D60. But that's just one block. After this block is the start of the next transfer block!



This next block is a big one, 0x4ACA bytes transferred to B516! This is sample data. (Did you notice that the first entry in the sample table transferred earlier was was B516?)

Now, at the end of this giant block, there might be another block to transfer more data. I haven't looked, so I don't know. But if the block transfers are set to just go one after another, how do they stop? To stop sending data, you have to set the size of the next block transfer to 0000. That ends the transfer routine.

Edit #1: Summary of above, now with crappy video!
[spoiler]http://youtu.be/MCjEzD_jNLE[/spoiler]
[/spoiler]

[spoiler=Part II: Samples]
So now we know how to transfer data from the ROM to ARAM. At this point I feel it is useful to examine things from the end section of ARAM and work our way backwards. That means that right now we're going to talk about sample data, 6E00 to FFFF.

First of all, not all samples change between songs. There are 0x16 Common Loaded Instruments, refered to as CLI, that are loaded by song collection 00 at the start of the game and then are never touched again. They are samples for SFX and music you can hear in any area of the game, such as your beams, bombs, item collection theme, and so on. I have a document on them saved on my computer, but you can look at it here.

Code Select Expand


00: 6E00 > 73C4 5C4 < sound for beginning a shot,
01: 73C4 > 7988 5C4 < also sound for a shot, first part of grapple sound
02: 7988 > 79AC 318 < Second part of grapple sound, part of doors
03: 7CA0 > 7DF6 156 < Item selecting, Samus landing
04: 7DF6 > 82F4 4FE < Last part of beam firing for non-ice
05: 82F4 > 8318 3DE < Is used in powerbombs
06: 86D2 > 86ED 1EF < Xray/elevator
07: 88C1 > 88DC 30F < spinjump/spacejump noise
08: 8BD0 > 91CA 5FA < Bombs
09: 91CA > 91E5 120 < Samus's footsteps, can kinda be changed to something else without being too noticable
0A: 92EA > 964A D65 < item theme string
0B: 92EA > 964A D65 < ^
0C: A04F > A06A 5A < Simple tone, used for "beeping notes" in elevator music
0D: A0A9 > A15D B4 < No clue, sounds like little insect claws closing
0E: A15D > A2E9 18C < Underwater breathing noise
0F: A2E9 > A6BE 3D9 < entering/exiting water
10: A6BE > A6E2 2B5 < Final part of ice beam noise
11: A973 > A98E 3F < static
12: A973 > A98E 3F < ^
13: A9B2 > ACB8 306 < Samus hurt noise
14: ACB8 > AF5B 2A3 < Common enemy hurt noise
15: AF5B > AF7F 2B5 < Health pickup noise
16: B210 > B516 306 < no clue, but sounds like it could be an alternate enemy sound


I'll mention why some samples are doubled in another update (It's not nessesary at all, this is just how Nintendo did it). The first number is which sample # it is, the second is the starting location of the sample in ARAM. The third is the loop point of the sample (once again, a topic for another update). And finally the fourth is the length of the sample in bytes. So the first sample, sample #00 (1) starts at 6E00 (2) in ARAM, has a loop point of 73C4 (3), and is 5C4 (4) bytes long. So between all these the largest sound is what, only D65 bytes? Clearly we're not streaming MP3s here. What format is the sound sample in?

It's a compressed format for .wav files called BRR. Without getting too technical, it compresses (not losslessly, mind you) 16 bytes into 9 byte chunks, featuring a 1 byte 'prediction' header and then 8 bytes of sample data. Notice how every single sample in the CLI (and every single sample, period) is evenly divisible by 9. The SPC decompresses this data on the fly as it plays the sampled sound. I don't think I have to completely explain everything about this, because there are tools for doing the conversion from .wav to .brr and back for you, the linked one is an updated version of what I've been using.

But honestly, unless you're trying to introduce some new voice acting or something (Even though all you'll have room for is 'The last metroid' 'is in captivity'), you probably won't need it. My prefered method is to rip new instruments from other games like Super Mario RPG and Secret of Mana. I mean, the samples are already compressed and in the game ROM, it's just a matter of finding them, which, like loop points, will be covered in the next update when we do the sample table.

For now I want to direct your attention back to the CLI. Remember in the first part where sample data was being transfered? Notice that it was being transfered to the end point of the last sample in the CLI. This may seem obvious, but the point is that you only have 0xFFFF - 0xB516 or 0x4AE9 of sample data to use per song! That means that your block transfer for sample data cannot exceed 0x4AE9 in size or you risk serious problems. However, don't forget that even though the CLI is not tapped for area music other than things like elevator and item rooms, there's nothing stopping you from using it for that purpose. In fact, I tend to replace the item theme string at 91CA with an instrument more suited to an atmospheric sound as a way to sneak in a little bit more sample data.

I intend to take that document with the CLI and expand it to contain all samples, kind of like Kejardon's document but more exhaustive, but I need sleep before too long so I'm posting this now and this'll end part II. Eventually when I complete the list (which will be after the final part of this guide, most likely) I'll come back and re-edit this part to include the complete list of sample information for Super Metroid in all songs.
[/spoiler]

[spoiler=Part III, Sample table]
Last time we briefly covered samples. However, there's more about them that you're going to learn in this part. One of the constants between all SPC engines (due to it being a part of the hardware) is the sample table, a lookup table of 4 byte entries that point to the location of the samples. Each sample has two pointers, a begin point and a loop point. Both are important, but let's look closer at the table and the samples themselves. Once again, pictures our are friends.



First, let's talk about begining points and how they can help find samples from other games, and how finding samples from other games can help in finding the sample table. A small word about .spc files, first, though. There are SPC files on the web that are essentially RAM dumps of the SPC700's memory at the time a song was playing. Because everything for music is contained in the ARAM, that means if you want to find a particular instrument from a particular song, all you need is to find the SPC file on the web, you don't nessecarily need to find a ROM and play the game up to the point where the song plays. However, these SPC files come with a 0x100 byte header, so all locations are adjusted by that amount. Compared the picture above (from a debugging emulator) to this picture (looking at the sample table), and noticed how it's been shifted down by 0x100 bytes. You'll have to remember that when looking into SPC files.



Now, at the time of this writing, I'm going to look into a game I haven't looked at before. If you're familiar with the SPC700's instruction set (which is different than the ASM we normally use) and hardware, it's not too difficult to find the sample location that way, but I'm going to write this assuming you don't know all of that stuff. All you need for this is a hex editor and an SPC file. Speaking of which, I'm looking at the intro to FFVI now. I haven't looked at this game's SPC before, I don't know where the sample table is set to, so how do I find it? Well, in this case it might be easier to find the samples before I find the sample table. It's actually not really difficult to find sample data, there are certain telltale signs. The biggest and most obvious is the header. All samples have this big header of mostly zeros. So the best way is to search for a pair of 3 or 4 zeros.

(While actually looking, I found the sample table first, due to FFVI using the same location for it as Secret of Mana. But let's pretend that didn't happen for the time being.)

So finally I found some sample data, here is what it looks like.



Not every sample, but almost every sample I find begins with 02 00 00 00 00 00 00 00 00... When playing a sound, the SPC/DSP have to decode the BRR sample, and it's done in 9 byte chunks. Samples start with a bunch of zeros because there is a buffer that is being filled once decoding begins, and so this empty chunk exists so the buffer can be fully filled before sound starts being played. Anyway, this sample is quite small. Maybe it's used for a sound effect. And right after it is another small sample. Make a note of the start locations, 4800 and 4824 (remember the adjustment by 0x100 bytes for .SPC files!), and search for these bytes, reversed, in the file. And here we are! The sample table in all its glory.



The smaller samples at the beginning are most likely for SFX. If you're looking for music samples, the bottom of the table looks more promising. If I were to start cataloguing these, I'd first record the pointers, change them and listen to the changed file to figure out what they are, and so on. So it'd start like this:

494D > 4C26
56FA > 590D
6312 > 632D
71A0 > 8631

That's the start point and loop point of each music sample. The length of each sample is determined by subtracting the start point of the next sample. So then I could determine length. To double check if you're right, see if the number is evenly divisible by 9, since .BRR files are made of 9 byte chunks, they must be divisible by 9. (Or you could end up with harsh sounding digital errors...) Minor point but it's easy to tell in base 10 if something's divisible by 9. Just add the digits together, if they add up to 9 then it's divisible and you're set. For example, the first sample...
56FA - 494D = DAD (Easier if your computer has a calculator that does hexadecimal. Windows 7 has one, you just have to set it to 'programmer' mode)
0xDAD (hexadecimal) = 3501 (decimal)
3+5+0+1 = 9
Therefore, the length is evenly divisible by 9 and we have confirmed DAD is the proper length of the sample.

For the last sample I would try looking to find a spot where the sample 'ends' and just make sure that the point I think is right results in the total size being evenly divisible by 9. I ended up at 9B90, and 9B90 - 71A0 = 0x29F0 = 10736 = 1+7+3+6 which is one short, which means I need to add one more byte to the end location. 0x29F1 is the sample size (I believe, but I could be wrong. One could test it by corrupting towards the end of this data and seeing if it affects the sound.)

I also do this for loop points. It's the same thing as before, only subtract the loop point instead of the start point. I get AD4 for the first sample, and so on. Now that I know that, it's time to determine what instruments these are, specifically. I use BRRamp by our resident MathOnNapkins as it lets me play and pause SPC files and I can choose which sample to play, but lacking that I would make a copy of the SPC file and change the pointers in a hex editor so they all point to one sample. (Incidentally it also tells me where the sample table is located, but seeing as most of you don't have a program for that I thought it necessary to show how to find it with only a hex editor.) Anyway, the complete set of data is:

Code Select Expand

494D > 4C26 0xDAD bytes 0xAD4 loop ;Organ
56FA > 590D 0xC18 bytes 0xA05 loop ;Vocal, female, operatic
6312 > 632D 0xE8E bytes 0xE73 loop ;Vocal, male, operatic
71A0 > 8631 0x29F1 bytes 0x1560 loop;Keyboard, piano, softer/brighter than a grand, and sounds slightly muted

And that's basically how I find and document instruments. I also rip them and save them individually as binary files, so today I just added 4 more instruments to my collection. At this point you know enough to start grabbing custom instruments you could use for your songs, but they won't exactly sound the same or be tuned properly when you import them into SM. There's a pitch modifier involved, and maybe some other stuff going on (I don't know myself for sure yet, but I REALLY hope not). That'll have to go into the next part. For now, let's cover some more about samples themselves.

You might have noticed in the Common Loaded Instrument Table from last part that covered the pointers for all the 'always loaded' instruments that certain samples had their loop points set to the beginning of the next sample. Now, in the header of the .brr, there's a bit that determines whether the sample will loop or not. Not all samples are set to loop, for instance ones used for SFX. Those ones tend to put their loop pointer at the beginning of the next sample. However, with samples that do loop, there is one important thing. The size of the loop is important for getting the pitch right. With custom samples ripped from other games, you pretty much always want to leave the loop point as it was. Why?

When playing a sample, how quickly it runs through the 9 byte chunks is determined by how high the pitch is. The 9 byte chunks contain the waveform, so to raise the pitch it must play more oscillations in the waveform in the same time period. Hence, a sound effect or sample that is not looped that lasts 1 second at the normal pitch will last 2 seconds when played an octave lower, or .5 seconds when played an octave higher, ect.

When testing an imported sample before, I cut off the end of the sample to make it fit in the space of the sample I was replacing it with. So even though I transfered the loop point properly, the size of the loop point changed. And since it was playing through the loop faster than the instrument was recorded for, every time the imported string was played long enough to loop, as soon as it looped the pitch was raised and the instrument became slightly distorted. There are factors that mean that this doesn't always happen, but I'm not fully prepared to discuss them in detail as they are still a little bit beyond my current understanding. But here, you can listen to what it sounds like when you import a sample but cut off the end to 'make it fit'.

https://dl.dropboxusercontent.com/u/10779677/ImportedInstrument.mp4

Now, as I said, this doesn't always happen. If you remember Faded Memories, the file I linked in the first post that was made with rediculous echo buffer, the vocal instrument used was Green Brinstar which was not naturally found in the Maridia instrument set. And to make it fit, I had to chop some of it off. But the pitch of the loop stayed the same. As I said, I don't fully understand everything behind why it happens or doesn't happen yet, but it's something to keep in mind if you think you want to try and make a sample 'smaller' in size.

Speaking of loop points, how does one test how a loop point sounds? Well, LazyShell, a SMRPG editor, has an audio editor that lets you import/export sounds. It's how I filled my SMRPG collection of instruments. But it also lets you play them, edit their loop point and listen to the result.



So this is the tool I use to create loop points for custom samples I make myself, like if I record my own keyboard with a mic and convert it, I use this tool, import the converted .brr, and test out loop points until I find one that works. Note, this editor only lets you move loop points in groups of 9 bytes so it always works. So in this pic, the loop point (grey vertical line) is 240 in decimal which becomes 0xF0 which multiplied by 9 is 0x870. So in this picture, the proper loop point is the location of the start point plus 0x870 bytes.

Also in this pic, note that at the loop point, there are two complete oscillations from it to the end of the sample. If you set the loop point so that the waveform is uneven, you'll create a harsh, unpleasant buzzing sound, especially with a sample like this where the loop point is so late in the sample. This is why it's so nice to have this editor for importing and testing your custom samples.

[/spoiler]

I think that covers it for this part, took me a little while to write up. Next time, we'll cover another table, the instrument table. The instrument table contains additional information for the samples being played, like volume, ASDR or gain settings, pitch modifiers (which is where we'll discuss tuning custom instruments), and so on. There'll be a lot to the next update too, so hold on for a little while longer, k? Thanks.
-DSO

[DSO]

Reserving space for more walls of text to come.

[DSO]

And extra in case I need it or decide to cover sound FX here at a later date...

AND THAT DAY IS TODAY 4 MINUTES BEFORE I LEAVE FOR WORK

Here's compilable code that you can edit to change the sounds in library1.
Just don't add more bytes than there are originally or you may run into trouble.

[code]lorom

;instrument sample index of permanently loaded samples
;SFX can also use area song loaded samples

;00: 6E00 > 73C4      5C4 < sound for beginning a shot,
;01: 73C4 > 7988      5C4 < also sound for a shot, first part of grapple sound
;02: 7988 > 79AC      318 < Second part of grapple sound, part of doors
;03: 7CA0 > 7DF6      156 < Item selecting, Samus landing
;04: 7DF6 > 82F4      4FE < Last part of beam firing for non-ice
;05: 82F4 > 8318      3DE < Is used in powerbombs
;06: 86D2 > 86ED      1EF < Xray/elevator
;07: 88C1 > 88DC      30F < spinjump/spacejump noise
;08: 8BD0 > 91CA      5FA < Bombs
;09: 91CA > 91E5      120 < Samus's footsteps, can kinda be changed to something else without being too noticable
;0A: 92EA > 964A      D65 < item theme string
;0B: 92EA > 964A      D65 < item theme string again
;0C: A04F > A06A       5A < Simple tone, used for "beeping notes" in elevator music
;0D: A0A9 > A15D       B4 < No clue, sounds like little insect claws closing
;0E: A15D > A2E9      18C < Underwater breathing noise
;0F: A2E9 > A6BE      3D9 < entering/exiting water
;10: A6BE > A6E2      2B5 < Final part of ice beam noise
;11: A973 > A98E       3F < Static
;12: A973 > A98E       3F < ^
;13: A9B2 > ACB8      306 < Samus hurt noise
;14: ACB8 > AF5B      2A3 < Common enemy hurt noise
;15: AF5B > AF7F      2B5 < Health pickup noise
;16: B210 > B516      306 < no clue, but sounds like it could be an alternate enemy sound



; Sound "piece" format:
; II VV Pa Pi TT

; PP - Pointer to pieces (SPC RAM address format), put more pointers in a row to play more pieces


; setup of a "piece", as I call it:
; II - Instrument sample index (defined in sample table)
; VV - Volume      ;00 is silent, FF is max
; Pa - Panning      ;00-14, 0A is center
; Pi - Pitch      ;80 (low C) - C7 (high B)
; TT - Timer      ;frames until the sample is cut off

;additionally, there's a two extra commands that can be used. A pitch slide (F5, arg1, arg2), and a loop
;pitch slide, F5 xx yy, changes pitch of next played 'piece' to yy at a speed determined by xx. higher xx = faster pitch slide
;loop, use FE 00 to start a loop point, then FB to jump back to the loop point

;Library 1:
{
;orig pointer   ROM loc, bank CF
; 71 2B    96F5   01|Power Bomb
; AF 2B    96F7   02|Clears sounds from library? Plays health pickup sound but no volume
; B7 2B    96F9   03|Fire Missile
; C4 2B    96FB   04|Fire Super Missile
; D1 2B    96FD   05|Fire Grapple
; FC 2B    96FF   06|Grappling on a block
; 2F 2C    9701   07|Short grapple sound, unsure when used
; 37 2C    9703   08|Charge Beam
; FF 2C    9705   09|X-Ray
; 12 2D    9707   0A|Clear sounds from library?
; 1A 2D    9709   0B|Power
; 27 2D    970B   0C|Ice
; 4B 2D    970D   0D|Wave
; 5D 2D    970F   0E|Wave/Ice
; 5F 2D    9711   0F|Spazer
; 76 2D    9713   10|Spazer/Ice
; 95 2D    9715   11|Spazer/Ice/Wave
; 97 2D    9717   12|Spazer/Wave
; 99 2D    9719   13|Plasma
; A6 2D    971B   14|Plasma/Ice
; A8 2D    971D   15|Plasma/Wave/Ice
; AA 2D    971F   16|Plasma/Wave
; AC 2D    9721   17|Charged
; C8 2D    9723   18|Charged Ice
; E7 2D    9725   19|Charged Wave
; FE 2D    9727   1A|Charged Wave/Ice
; 00 2E    9729   1B|Charged Spazer
; 17 2E    972B   1C|Charged Spazer/Ice
; 19 2E    972D   1D|Charged Spazer/Wave/Ice
; 1B 2E    972F   1E|Charged Spazer/Wave
; 1D 2E    9731   1F|Charged Plasma
; 34 2E    9733   20|Charged Plasma/Ice
; 36 2E    9735   21|Charged Plasma/Wave/Ice
; 38 2E    9737   22|Charged Plasma/Wave
; 3A 2E    9739   23|Ice SBA
; 68 2E    973B   24|Ice SBA fires off
; AF 2E    973D   25|Spazer SBA
; D0 2E    973F   26|Spazer SBA fires off
; F6 2E    9741   27|Plasma SBA
; 2C 2F    9743   28|Wave SBA
; 37 2F    9745   29|Nothing?
; 3F 2F    9747   2A|Wallump/Helmet noise in the start menu
; 47 2F    9749   2B|Nothing?
; 4A 2F    974B   2C|Nothing?
; 4D 2F    974D   2D|Nothing?
; 50 2F    974F   2E|Saving
; B0 2F    9751   2F|Spinjump
; B8 2F    9753   30|Resuming normal spinjump
; C3 2F    9755   31|Starting normal spinjump
; DD 2F    9757   32|Stop spinjump
; E5 2F    9759   33|Screw Attack
; 40 30    975B   34|Stop screw-attack
; 48 30    975D   35|Samus hurt
; 55 30    975F   36|Map click when scroling
; 5D 30    9761   37|Selecting item, HUD and pause menu
; 65 30    9763   38|Sound for changing map/equipment screen, equipping items
; 70 30    9765   39|^ but quieter
; 78 30    9767   3A|Nothing?
; 7B 30    9769   3B|Going from world map to area map
; 8B 30    976B   3C|Going fro

[P.JBoy]

If it's helpful, I have the music data banks logged out here (banks $CF..$DE) and here ($DF and highlighted)

[Quietus]

Like a lot of things hacking related, it often takes a hack or a guide such as this to galvanise people into creating more custom content.  A guide for music has been a long time coming, so it's nice to see one finally appear.  Great work, DSO. :^_^:

[thedopefish]

Nice work DSO.  It looks like I'll soon have what I need to start building some music editing tools.

[DSO]

Part 2 is up! Also a video covering part 1! I will probably be adding more to it later, but right now I'm trying to push through to the point where people can start making their own songs. We still have an update or two before we reach that point, but it's coming!

[DSO]

A fairly large part 3 appears! For those who are curious, next time we cover the instrument table and then after that we do song and note data where we get you to the point of actually writing music!

[Metaquarius]

When testing an imported sample before, I cut off the end of the sample to make it fit in the space of the sample I was replacing it with.

Cutting off a looped sample is the best way to make it sound bad. It's like trying to create an arbitrary loop point in hex then expect the sample to loop nicely. :nuhuh:

Btw, this BRRamp program looks interesting, where can we get it ? :heheh:

[begrimed]

Cutting samples off should sound fine if you use a very short volume fade-out.

[DSO]

CHECK OUT THAT LIBRARY1 SOUNDS DISASSEMBLY IN THE THIRD POST MANG

ALSO LIKE YOU CAN SAVE THAT TO A .ASM FILE, IT WILL COMPILE
SO USE THAT AND TWEAK THE SOUNDS TO YOUR HEARTS CONTENT

LIBRARY2 MAY BE COMING NEXT MONTH

[Metaquarius]

Just a few additions :

;09: 91CA > 91E5      120 < Samus's footsteps, can kinda be changed to something else without being too noticable

Power bomb sfx uses this sample, not sure you can change this one that easily.

;0C: A04F > A06A       5A < Simple tone, used for "beeping notes" in elevator music

Also used for missile pickup sound.

;0D: A0A9 > A15D       B4 < No clue, sounds like little insect claws closing

Used for freezing sound and chozo gripping sound at least.

;11: A973 > A98E       3F < Static
;12: A973 > A98E       3F < ^

Used for lava/acid steam I think.

;15: AF5B > AF7F      2B5 < Health pickup noise

Also used in pause menu when toggling on/off equipement and switching screens.

[DSO]

DSO is here to tell you a wild Library2 appears in the third post in the third person! Tons of space to be saved or opened up, especially if your hack doesn't have things like Mother Brain or Crocomire or Etecoons...

[thedopefish]

I've been working with DSO on a tool to make this stuff more accessible to mere mortals.  I don't expect it to be terribly useful just yet--all it current does is show you the samples in an .SPC file (basically, the first half of the "Sample Table" section in the first post).  But more features will be coming later, and anyone that wants to play around with it is welcome to.

http://vespenegas.com/dopetool

[spoiler=Everybody loves screenshots]

[/spoiler]

[Quietus]

Oh, man.  I love the 91E5 bit.  It's so damned catchy. :^_^:

* Quietus taps his foot.

[Alisa Orlova]

Maybe someone wants to make a noob-friendly video guide?

[DSO]

SFX Library 3 has been added to the usual post! Going to work on creating a more optimized version with the libraries in one file to cut out the wasteful things Nintendo did. As well as get with Dopey on setting up an SFX editor.

[messiaen]

http://forum.metroidconstruction.com/index.php/topic,2475.msg31631.html#msg31631

If it helps,  AFAIR this works if you want to convert . Mml files from SMCentral to Super Metroid format.

[PHOSPHOTiDYL]

Posting here since it's the most relevant thread available...

$DF is just unused music data.
I'm not using it either so I wanted to move all the music into a nice 16 bank spread from $D0-DF.

First copy bytes from 00278000 to 002F7FFF, aka banks $CF-DE.
Paste @ 00280000, aka bank $D0.
FF bytes from 00278000 to 0027FFFF, aka bank $CF.

Then +1 to all the music related banks.

Code Select Expand

LoROM

ORG $80845D
dl $D08000

ORG $8FE7E1 ;//[music pointers]
MusicPointer:
dl $D08000 ;//ADSR settings
dl $D1E20D ;//"title sequence" sample table
dl $D2B62A ;//"empty crateria" sample table
dl $D388CA ;//"space pirate" sample table
dl $D3D9B6 ;//"samus theme" sample table
dl $D4933C ;//"green brinstar" sample table
dl $D4E812 ;//"red brinstar" sample table
dl $D5B86C ;//"upper norfair" sample table
dl $D5F420 ;//"lower norfair" sample table
dl $D6C844 ;//"maridia" sample table
dl $D798B7 ;//"tourian" sample table
dl $D7EF9D ;//"mother brain" sample table
dl $D8BF73 ;//"boss fight 1" sample table
dl $D999B2 ;//"boss fight 2" sample table
dl $D9EA8B ;//"miniboss fight" sample table
dl $DAB67B ;//"ceres" sample table
dl $DAF5DD ;//"wrecked ship" sample table
dl $DBB650 ;//"zebes boom" sample table
dl $DBD63B ;//"intro" sample table
dl $DCA40F ;//"death" sample table
dl $DCDF4F ;//"credits" sample table
dl $DDAF6C ;//"the last metroid" sample table
dl $DDFAC7 ;//"the galaxy" sample table

$CF is free for level data, tileset gfx, tiletables, or tileset palettes. Everything else is less than $C0. LoROM.

[PHOSPHOTiDYL]

Okay, I've been struggling with my mewzick, til I found this combo.

[spoiler]https://github.com/nathancassano/snesgss
https://dgrfactory.jp/spcplay/index.html[/spoiler]

Snes GSS lets you export as an spc, it even lets you import midi filez!!
SPC play is just an spc player, I'm sure there's more of them...

It'z a damn good day.

[Smiley]

Alternatively you can use mITroid by tewtal to convert tracker files directly into n-spc, the Super Metroid specific format, instead of generic spc. :^_^: