Gamecube Sequence Format? by Volkov73 at 1:42 PM EDT on April 18, 2018
I am very interested in Gamecube sequence data.
Basically I would like to achieve one of these two thing:
1) Generate Channel/Instrument separated WAVs for songs, as in 1x WAV file per instrument/channel (possibly by editing channel headers in the ISO, but I have no idea of the sequence formats yet)
2) Edit the ISO file so certain notes are omitted (possibly by setting the note velocity to 0)
As for working with gamecube ROMs and the sequence data. working out which notes are which would be the hardest part (but may be possible with musyx2midi + log file of how it made the midi).
Perhaps generating a WAV file for each audio channel would be easier - and may not even require editing the ROM? I know for SNES you can do this, but not for N64 as the mixing is down in software.
For the N64 sequences I have done (and you can listen in the link I shared), the best part is that with the edited ROMs I have the ability to use a Flash Cart and then get recordings of these coming from the original console as opposed to sub-par emulation.
Looking for any thought on how I might achieve doing this with gamecube sequences.
Parsing of sequence data highly depends on the game. For musyx based games amuse is a good way to understand or parse sequences. For other games I cant tell.
An alternative (and IMO better way) to achieve what you want is to convert the sequence data of a game to MIDI and its soundbank to SF2 or DLS. That way you get back from the proprietary formats to open standards for which you can use established software to re-synthesize the tunes. Once setup a soundfont properly, you can multichannel render all tunes at full 48 kHz and have full loop control. It is also beneficial for the community when you provide the files.
Frankly speaking, your approach of custom rom hacking is highly complicated, error prone, expensive on memory and pretty useless for the community.
When converting to MIDI/SF2 you are actually losing data, as there are functions in the sequence (many are unknown) that cannot be converted to midi.
I spent a long time trying to recreate N64 songs using midi and soundfont. There were many cases where songs sounded pretty bad. I made several threads (1-2yrs ago) seeking help but all the suggestions fell short. I have seen other people recreate songs that sound at an acceptable level (I'm looking at you Goldeneye HD version), but that is still more manual work (reverb/sample rate/etc)
My current method for N64 songs is actually kind of simple. The only "rom hacking" involved is replacing some 4byte channel headers with 0000. For first-party games I was able to use SEQ64 software to change the velocity of notes to 00 very easily, and in some other games there was minor manual work.
The upside to the ROM hacking is that it produces 100% authentic sounding songs. N64 reverb sounds fantastic Drum samples lined up without any manual work. Not having to manually check every note/part is accurate (correct octave/instrument/etc)
I just hack the ROM to remove the melody line and....done! No messing around and no worrying about any parts being wrong.
I've spent my time ripping Rarewares N64 games. I did not experience the obstacles you described and yet I get accurate results when re-synthesizing the midis. Also so far I did not came across "functions that cannot be converted to midi", SF2 modulators are quite powerful to manipulate any aspect during synthesization. And anything not supported like N64 midi track loops can be implemented.
Sure reverb is an issue. For the N64 this apparently remains unimplemented. For Musyx the guys of amuse have put in effort to reverse engineer and re-implement it.
While ROM hacking does indeed produce an accurate result, how do you cope with track loops? Given your description of wave file extract I guess you loose them.
Speaking of sequenced Gamecube audio, I'm going to make a plugin for foobar2000, possibly integrated into vgmstream if I get approval, to play sequenced Gamecube, Wii, DS, 3DS, etc music natively.
I have done loads of research into SSEQ, CSEQ, RSEQ and various other binary Nintendo formats, so I'll (attempt to) cook something up!
For Gamecube, I think I'll call it .gcsf, coz why not?
There are various threads where several people have made tools involving the BMS data conversion.
If the tools can convert from bms to midi (even without reverb or other functions), then to me that means that figuring out what the notes are in the ISO data should be simple enough. Time consuming maybe but I don't mind the amount of work. I just don't know where to begin right now.
I'm struggling to see documentation regarding this sequence format. I may try to get a programmer friend of mine to compile some of the programs floating about, but that would be on a whim.
In the absolute worst case scenario I would be happy to manually edit the velocity of the notes in a hex editor to 00, and then play the music back in an emulator.
I think muting the channels to have them play back one at a time could be easier, but not sure. At least this was the case for N64 and I feel I need to approach this the same way if I want to make something like this
Okay, so I found that I could extract a sequence.arc file from the ISO.
I thought that perhaps I would edit this arc file and then put it back into the ISO.
None of the tools to decompress/decode/extract this .arc file seemed to work for me.
Once I get to the stage where I can actually make edits and then run the ISO in an emulator, I can spent a lot of my time using trial/error to work out the sequence format myself to set the velocity of certain note to 00, or mute an entire channel/instrument (even though I think this information would be known as there are software that make midi files?)..
In Super Mario Sunshine, for example, the header, which contains the offsets of each sequence is located at the end of a file called "msound.aaf", which is located in the "audi" folder of "nintendo.szs".
I then use yaz0dec to get nintendo.szs 0.rarc I then use rarcdump to get folder "nintendo.szs 0.rarc_dir"
So I figured out how to get msound.aaf I can see the offsets now. I'll see if I can use the values to find the sequences for a specific song in sequences.arc
Are you saying sequences.arc does not need be decompiled, and that I can make edits directly?
And once I do make some edits, how would I put sequences.arc back into the ISO.
I actually think that is all I would need to do to achieve what I need
I'm not sure there should be any offset changes so I won't address that *just* yet. I've simply made an edit to "sequence.arc" file - keeping it the exact same file size and length.
I've downloaded Gamecube ISO Tool (backup manager) so I can extract the ISO out into files/folders and then make my changes and rebuild it.
However, this did not work. I thought it might be because of my changes and what you mentioned....but as a test I rebuilt the ISO (without making ANY changes), and Doplhin won't run this; "SMStest.iso is an invalid GCM/ISO, or i not a GC/Wii ISO."
If I could get beyond this step, I might be able to try rebuild the ISO with my edited version of sequence.arc replacing the original version and see what happens! :D
I'm using a PAL version. Honestly I'm going to have to do this a LOT of times myself as the edits I'm making to sequence.arc right now are just random as I don't know the format yet (thought if people are converting it to midi files then this info should be around somewhere, right?).
Ideally I want to *either* set the velocity of certain notes to 00 (i will need the midi's for this to compare what to change), or just set an instrument value to 00 so it won't play that instrument at all, or a channel value to 00. See, I'm not sure what to do but if I could get the ISO to rebuild and run in Dolphin I would be happy to spent dozens of hours making random edits and reverse-engineer enough of the sequence format myself to achieve what I want to do. It's rough :P
I'm trying a different tool "GC-Tool" now so I'll let you know how I go
I edited a small part of sequence.arc - found the offest for the title music and replaced the entire section 00's and rebuilt the ISO. It worked in Dolphin...and there is no song being played for the title music but everything else is fine. This is a step in the right direction for sure.
Now all that's left is to find some reliable info on this sequence format, do you have any leads I could chase?
Being able to dump sequence.arc to a set of midi files would be highly invaluable and would give me enough information to manually find the notes to change (unless the sequences are compressed but I really hope not - they were in Goldeneye 007 I believe so I couldn't make edits in a hex editor).
Another option would be figuring out how to turn an instrument or channel off completely (this method worked best for a game like Diddy Kong Racing, i made some nice backing tracks)
I would turn off all but one channel and record it the audio. Repeat this step for all the channel's and then I could line them all up in Audacity and just mute the melody parts (because melody parts often occur over multiple instruments or channels)
I failed in recreating nintendo.szs - and I feel you would know what I'm doing wrong here.
I used yaz0dec to get "nintendo.szs 0.rarc" Then rarcdump to get folder "nintendo.szs 0.rarc_dir"
Okay, so time to do the reverse steps, change back into rarc and then back to szs, without editing any of the file contents.
I've tried 2 different tools, RARC Packer and Lunaboy_RARC_Tools, both which give me a .arc file instead of a .rarc file.
I then used yaz0enc but it gave me a file called "nintendo.arc.yaz0" so I thought I'd rename that nintendo.szs
I tried renaming .arc to .rarc before using yaz0enc.
GC Tool will not replace the file as it is "larger than the file it is trying to replace". and this is with with making 0 changes along the way.
The new file I created is 107,744 bytes, whereas the original file is 107,733 (11 bytes smaller).
I need to do this because I want to change the offset/length of the Title Music pointer in msound.aaf to that of other songs (which would results in msound.aaf being the same filesize). However, without any changes - just going szs -> rarc -> folderstructure -> arc/rarc -> szs(?) without changing msound.aaf is resulting in the outputted file to be 11 bytes larger and not being accepted by GC Tools when trying to replace the file.
@Volkov73 Use GCTool to extract all the contents, replace the file you want to replace into the correct direction, then use GCRebuilder to rebuild the ISO. That works for me, no size limitations.
@1425720626 Great, that worked perfectly. I can now have any song playing for the title music (to get clean audio recordings of all songs).
@vajuvaju The page is working, you should be able to hear my tracks.
Okay, so I'm to the final step, and that is editing the sequence.arc file to mute certain channels or instruments. I'm going to try and research this BMS format a bit and see what I can do.
Well, that was easier than expected, I've worked it out myself.
The start of the sequence reads c1 yy xx xx xx c1 yy xx xx xx c1 yy xx xx xx. yy = 00, 01, 02, 03 This leads me to believe they are the channel numbers and the xx xx xx were the offset locations (as they were larger every time).
I went to these offset location in the sequence and found that the previous byte was ff (end of data), so that confirmed to me which blocks of data belonged to each channel of the sequence.
I went to that offset location for each channel and put ff as the first byte. I did this for all but one channel and viola, I was able to isolate playback of each individual channel of a song.
To disable sfx I just filled the entire se sequence with 00's
I think I found the sequence data for the Gamecube IPL/BIOS but it's in a very weird format. I can see A4 commands and "FE 00 78 FD 00 96", which denotes 120 ticks per second and 150 bpm. But the C1 commands don't make any sense as they don't lead to the offsets correctly.
You can find the sequence data at 0x15C460 of the decrypted IPL.
I did find some songs that had some c1 commands, followed by some nonsense, then I found some more c1 commands just after that led to the correct offsets.
Looking over the data again, it looks like the very first C1 commands in the Gamecube IPL (C1 80 00 00 2F C1 81 00 01 70 C1 82 00 02 81 C1 83 00 03 7D) show also have end of track bytes, but they're not FF. They end with an E5 byte. I can't seem to find E5 documented anywhere in any BMS notes online, so I'm wondering if this terminator byte is exclusive to this early version of BMS.
Could you try running a sequence with a single channel and putting FF and E5 at the end to see what happens?
I didn’t look at any notes regarding BMS files, I’m doing everything just from trial and error and comparing to what I know of other sequence formats . Feel free to share some of these notes.
There seems to be a script in some of the sequences to determine what “state†your game is in, and this effects what instruments will play. For example, a percussive track might only start playing when a certain goal/objective has been met. I wish I could edit this because I’m unable to get the sounds to play. I will eventually work it out from brute force . Maybe this week I’ll have a try