yeah the MSU-1 making community for A Link to the Past ended up being one of those unfortunate "oral history via Discord" projects that never writes down any permanent documentation. When you Google for it you get incredibly old stuff from the Zeldix forums where MSU-1 was first being developed.
(Context: MSU-1 is an anachronistic "expansion chip" for the Super Nintendo, which never existed in any real cartridge but exists in emulators and flash carts, that plays high-quality audio from .pcm files. In game ROMs that support it, like A Link to the Past Randomizer, you can make music packs to replace the music in the game.)
So I'll tell you what I do and give you an example.
The important thing is a tool called MSUPCM++, which creates .pcm files with the correct headers from a "tracks.json" file where you describe where the tracks are (as .mp3 or .flac files or whatever) and how to process them.
When I distribute MSU packs I distribute this tracks.json file along with the .exe of MSUPCM++. This has some advantages over packs where you just download the .pcm files:
- .pcm files are uncompressed and enormous
- the composers of video game music are real people who don't tend to like it when you just copy their music, so if you're distributing an MSU pack you should do it in a way where the recipient buys the MP3s and then runs your script on them
But it sure makes a simpler example if you don't have to worry about buying the music and saving it with the right filenames, so an example I'll point you to is my Cave Story pack, because the Cave Story soundtrack is free.
So here's the first 3 entries in the Cave Story tracks.json:
{
"track_number": 1,
"title": "Title",
"file": "Cave Story.mp3",
"trim_end": 842000,
"normalization": -21
},
{
"track_number": 2,
"title": "Light World overworld",
"file": "On to Grasstown.mp3",
"normalization": -15,
"loop": 4423680
},
{
"track_number": 3,
"title": "Rain state",
"file": "White.mp3",
"loop": 115200
},
The important keys to know about are:
track_number: these are the internal track numbers that the game ROM was using to trigger SPC music tracks, which we replace with MSU tracks. I've given each of them that's used in ALttPR atitlein the tracks.json.file: points to the .mp3, .flac, or I guess .wav file to create the music from. The devs recommend .flac because mp3 padding can mess up your timing, though I've managed to deal with it.trim_start: this is a time measured in samples, of which there are 44100 per second, saying where in the music to start playing.trim_end: in samples, where in the music to stop playing. If you leave it out, it stops at the end of the file. For tracks that loop (most of them), you'll also need:loop: in samples, the point in the music to jump back to when you hittrim_end. If you leave it out, it's 0. If you accidentally make this higher thantrim_end, you will probably crash the emulator or the MSU-1 firmware when you hit the loop point.normalization: MSUPCM++ will use a normalization algorithm to try to make the tracks the same volume, but it's not the most perceptually accurate. Use this to adjust the volume per track. In my experience, usually recorded music should be around -19 dB and chiptune music should be around -22 dB, but you'll see I had to crank "On to Grasstown" up to -15 dB for some reason.
How do you get these numbers of samples? Use Audacity. You can configure it to display timing in samples instead of seconds. Select a range of music, shift-click the timeline to play it as a loop and hear if it loops correctly, and when you're satisfied, copy those numbers of samples into your .json as the "loop" and "trim_end".
I'm not going to be the one to fully document MSUPCM++, but you may be able to take it from here, given my example. And the #msu-1 channel on the ALttPR discord will be... moderately helpful.
You can find most of my MSU packs, with some more complex examples, at msu-1.link, a site I set up for this where I had the ambition of hosting all kinds of MSU packs but mostly it's for my own. There's even one there for Earthbound instead of ALttP.