Stupid question: can't you edit them with a program that can read them ?
A program generating MIDI files (.mid or else) would not work, of course. You can't do anything else than modifying an existing one, I guess. Anyway it seems to me that an AMB file is a sub-category of MIDI file. Not bigger or more complex. A MIDI file can be very complex, believe me. Not bigger anyway, which was very useful in the times you had to record big sequences on small floppy discs. For example you could have one file saying: at bar 1 I play piano with the right hand and bass with the left one, at bar 2 I change piano for guitar and put tremolo on it, at bar 3 I change pitch for both, etc, etc. You could also change channels (MIDI plays on 128 channels IIRC) except for the drums (always on channel 10). There are a lot of things you can do with a MIDI file... this language is really huge and comes directly from the 80's!
I looked around for programs that would be able to perhaps edit them, but was unsuccessful in finding a program that could output it correctly. It seems programs will output in various formats such as .mid, but cannot output the additional information that Firaxsis added to it.
One idea I have, is to create an excel spreadsheet which would contain all the information which always stays unchanged (in either ANSI or Unicode), and allow users to input things such as the wav filenames, timing of the sounds, etc... and then you could save that file as a certain type of txt file (or even a unicode file maybe) and rename it to an AMB, in order to keep the file formatted properly.
But this would be incredibly un-user-friendly in allowing one to time sounds correctly. I think the AMB file only uses a very small amount of what is available in MIDI. The only thing I see is what is discussed in this
Midi crash course page. That being the Midi Header file and Midi Tracks.
You seem pretty familiar with the Midi format though, so the Midi Header file does contain information regarding the number of tracks (which correctly corresponds to the number of tracks/wav files for each AMB), track speed (ticks per quarter note? I'm not too familiar with determining these).
Each Midi Track file contains info on the number of bytes that this tracks music data contains along with the Track Out (end of track) section. I'd have to research on how to come up with this value. Firaxsis added in each Midi Track section a 'Variable' which gets what wav files to play in a portion above the Midi section. Plus, I'm not sure exactly how the Music Data in the track file has anything to do with anything, since it is a wav file being played.
But I suppose the hex value after each 'prgm' word gives the timing information for that wav, since it was all out of whack after I deleted those values in the previous test.
But to incorporate all of this into an easy to use system may be more complicated than I thought. The best thing, IMHO, would be to figure out how to determine what hex value is needed to determine timing from the number of seconds (or miliseconds) in which the sound needs to start. Because viewing an animation in Flicster, or other utilities, you can get a pretty close approximation as to when the sound should start playing. So if someone sees from the animation that 1.5 seconds after start the cannon fires... they would know that the sounds needs to start 1500 miliseconds after the beginning. If those hex values indeed are used for this type of timing, then a timestamp-hex conversion page could be used to determine the value (which are available).
Tom