Modifying AMB files

Well, I'm not even sure if that is a unit key, that was just an initial thought, since it was one of the only values that was different in every AMB file (the Rogue hex values :)). Then when you stated that after changing it, it still used a different sound for the unit, it kinda drove it home. I don't see anything that correlates with that specific value's decimal though. So for '/' which has a hex of 2F, has a decimal of 47. 47 doesn't really match up to anything relating to the Rifleman unit, so I'm not sure how this is used, unless it is hardcoded.

My hope is that, by deleting this key by entering a 00 in that spot, it won't FORCE a specific unit to use that sound, but will simply just play the AMB file instead.

And hopefully, the game may just use the Unit INI to play the file, instead of relying on matching up units with hardcoded programming.

I'll do a test on it now, and post in about 15-20 min.

Tom
 
Exactly what I thought... However, it does bring up the question...why were the .amb files set specifically for a unit if they can be used without that key?

I am not sure how the Units themselves are labeled with a Key that matches the assumed Key to them in the .amb file.

When I tested the .amb files briefly long ago, I found that if another sound is applied to the .amb file, it also will be played for the original unit...... so this means they do use a key, But How?
 
Well I did a test... using 2 Immortals.

In the first Immortal (Modified Immortal) I deleted (changed their hex values to 00) all the 'Keys' that were behind the prgm portions in the Attack AMB (and there were several of them, so it can't be a unique Key).

The (Regular Immortal) was left alone, so I could hear what differences occured between the sounds.

The Modified Immortal had it's sounds playing out of sync with the animations (EDIT: ALL sounds did indeed still play), whereas the Regular Immortal was in perfect sync. So my initial conclusion would be that these must also be some type of sound timing function.

Tom
 
sounds correct... but what is the Key then and how in the world does the game link the .amb Key to the Unit unless Hard Coded?

I seriously believe what ever the Key is, is Hard Coded. There would not need to be a specific key if the .amb files did not need them for a unit in order to not be confused with any other .amb file in the game... that is probably the case because as I mentioned, if the sounds are simply changed in a .amb file, even the Original Unit in a different folder will play the New Sounds.

Based on my assumption, I believe one of the critical things to be able to do is find a way of setting a Key for a New Unit and a New .amb... That is probably not possible unless we can find how units are Keyed to the .amb files specifically.
 
When I tested the .amb files briefly long ago, I found that if another sound is applied to the .amb file, it also will be played for the original unit...... so this means they do use a key, But How?

I believe that the game assigns a variable to certain sounds... and then probably stores it in memory. See the highlighted below:
Variable being defined:
variable.jpg
NOTE: you see the sequence 'Sword Sword' above.. The first is probably the variable, and the 2nd is the end of filename, but could be something else as well (note, etc).

I'm pretty sure this is a variable which down further relates to the actual wav file, in this instance it is ImmortalAttackASword.wav for the Sword variable.
Wav file being associated with the variable:
VariableAssigned.jpg

It then uses these variables in the bottom portion of the MIDI information part (see below):
Variable being used in the MIDI portion of the AMB file:
SwordVariable.jpg

The highlighted portion shows the MidiTrack Header, along with other Midi information (such as pitch, volume, etc) along with the Sword variable which must relate to the above info (which tells it what wav file to play). The MidiTrack Header also has a timing function contained within it.. which I thought controlled the timing of everything, but apparently the hex value behind the 'prgm' also has a role.

It's possible that for 2 AMB files that are the same, but with 1 that has a modified wav file in it... Civ 3 will store in memory these variables (maybe the first one it plays) which will then stay in memory.. so when the 2nd modified one is played, it will simply access the info from the first.

So a new AMB file, would probably need to have new variables assigned as well, to make it unique. <----- most of this is speculation at this point! :)

Tom
 
Good Deal tom2050... Probably, the .amb files have to be hard coded in order to link to the specific Unit they are for. I assume this because they are specific to each unit and when only the sounds are changed in them, the new sounds play for the Specific Unit they apparently are Hard Coded for. I tried setting different sounds for the settler .amb to use for another Unit. This .amb was placed in the New Unit Folder and worked ok. When The settler Unit played in the game, the New Sounds I placed in the .amb for the New Unit played for the Settler as well.
 
OK, I know that this was quick.. but I had a lucky guess in my above post.

I used 2 Immortals, and modified 1 of the AMB files to use a Battleship wav explosion instead of the attack wav. We'll call them Original Immortal... and Modified Immortal.

First test: I attacked with the Original Immortal first... and his attack played out normal. I then attacked with a Modified Immortal, and his sounds were the same as the Original (no battleship explosions).

Second test: I attacked with the Modified Immortal first... and his attack played the battleship explosions. I then attacked with the Original Immortal, and his sounds played the normal Immortal sounds. I then attacked with the Modified Immortal again, and his sounds played the normal Immortal sounds (not the Battleships).

So the game does indeed use those Variables to store the sound data in Memory. It then will recall this info every time the variable is used (but seems that once the original unit is played, a modified unit will stop using the modified sounds).

So I don't think it is hardcoded, but a person would just need to give their own Unique AMB file a unique variable name to keep it seperate from other units. I'll test this in a minute to ensure it works. (If it doesn't then these 'variables' might be hardcoded)

Tom
 
Two remarks just in case: a MIDI file doesn't contain any sound. It only contains orders. Play this file, at that volume, with that pitch, etc. Then an "audio engine" (a sequencer in fact) reads it and associates the sound files (that are stored in each unit folder) with the orders it follows.
Basically that's what a MIDI piano keyboard does: you play an "A" after you have chosen "violin" and you can hear a violin "A" note. If you move the pitch bend, the sound's tone or volume doesn't change, only the pitch. If you have a sampling function, then you can play any sound, even a noise with no special note.
2nd remark: I thought the AMB file had a name and a place in a folder that linked it to the unit, ie: SwordsmanAttack.amb, containing infos on how to play the swoosh, cloths and metal sounds. The link to the unit is in the INIT file, am I right ? What key are you guys looking for ?

EDIT: I think I cross-posted with both of you. Sorry for this. Nice to read that you're on a good track!
 
That is Great News tom2050. I had not tried testing it that way. Good Find :goodjob:

Now where would we add a unique variable name in the .amb file?
This means that if we can make the .amb files, we can use them :D

See post #26.. I added to that post what I believe are the variables used in the AMB file. I just finished my test... and it did indeed work by changing the variable, so even after using the Original Immortal, the Modified Immortal played his own sound.

In post #26 under Variable being defined:, both variables need to be changed though for it to work. So 'Sword Sword' would have to become 'Swora Swora' (or w/e variable you choose to use), then you need to update it on the other parts as well.

I had keep the filename consistent as well, so the new wav file had to have the filename: ImmortalAttackASwora.wav. (name of AMB file)+(variable name)
(ImmortalAttackA)+(swora)

Tom
 
Two remarks just in case: a MIDI file doesn't contain any sound. It only contains orders.

Yes, but this is an appended MIDI file.. It contains MIDI information; primarily MThd and MTrk info... which is the Header and Track info along with their attributes. But the AMB file contains other information which Firaxsis added to it, which is what I've been trying to determine how it works, in order to create a custom AMB file.

Unfortunately, using programs to create a MID file would probably not work, due to the way the AMB is set up... so in the end, I would have to create some way/program to do this. I took programming for 2 years at Mizzou but never completed the degree, and that was 10 years ago, so my skills aren't exactly up-to-date.

The INI file tells what sound file to play, so it may be a wav file or an AMB file... but if it is an AMB file, the AMB file allows several wav files to be played and sequenced as you mentioned. So a portion of this is in MIDI format, and a portion is the code (variables and wav file names) which Firaxsis added.

I believe we have just concluded a way to make custom wav's, now to determine the easiest way to make a new one, so no one needs to go hex editing :) Also I have info on the MIDI sound timers, but it seems Firaxsis added there own timers in as well (which determine when sound plays). So more testing will be needed first.

Tom
 
tom2050... Very successful tests and good results that are already beneficial.
Just using the currently known information we can at least use existing .amb files for other Units with separate sounds.
The sounds would probably have to match the timing but this is Good so far.

Any successful results you gain that allow making or modifying .amb files will be Tremendously Useful. This has been one of the areas that has not really been researched over the Years and it is Great to finally gain more useful information.
Be sure to write a Tutorial on the subject for people to use.
 
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!
 
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
 
Anything that will allow modifying existing .amb files for use as new .amb files will be fine and perhaps also more "user friendly" anyway.
Once what ever can be discovered is known, if a list is made of what can be changed along with an explanation of how to accomplish it is added, that will certainly be used by many people.
 
Back
Top Bottom