Sid Meier's Alpha Centauri - Printable Version +- Scoring Central (http://scoringcentral.mattiaswestlund.net) +-- Forum: Miscellaneous (http://scoringcentral.mattiaswestlund.net/forumdisplay.php?fid=20) +--- Forum: Off-topic (http://scoringcentral.mattiaswestlund.net/forumdisplay.php?fid=21) +--- Thread: Sid Meier's Alpha Centauri (/showthread.php?tid=258)

Sid Meier's Alpha Centauri - Samulis - 07-31-2017 I was curious in Alpha Centauri after reading so many good reviews and enjoying Civ III immensely all my childhood and even today. I took a cursory glance around the game files and was shocked to find there were zero actual audio tracks, aside from a short main menu piece, nor were there any midi files! Instead, the game has a set of ~350 .wav samples, they appear to all be 22.05 kHz Mono @ 16 bits and take up (for the time, 1999) an astounding 78 MB of space (keep in mind at that time, the max amount of RAM you could put in the ESI-4000 sampler was 128 MB and the default was only 4-8 MB). Files with the '.amb' extension seem to reference these samples (almost like tracker files?), although it seems the actual music is done dynamically. Very cool! This is honestly the only time I have seen {almost} the entire soundtrack of a PC game being comprised of bundled samples. Too bad it'll be another what, 80 years before anyone can legally work with or redistribute these samples. :/ The composer's (or at least, implementer's) name is listed in the files- David Evans. Maybe someone else has heard of him? I haven't had a chance to do any more research yet. EDIT: On a second listen through, it sounds like a lot of these sounds are commercial libraries from the time. One of them sounds like a bowed glass patch I think was on the Mirage, and the timpani sounds reeeaally familiar but I can't put my finger on it... maybe a Roland thing. That might mean at least some of these samples are of questionably more legal standing? RE: Sid Meier's Alpha Centauri - bigcat1969 - 07-31-2017 I think they used midi files and samples. It is kind of an interesting idea as the midi files take up virtually no space so the limit would be on the number and size of the samples, but then you could make any length of soundtrack. I wonder if back then they were not as worried about distributing individual wave files as we are now? RE: Sid Meier's Alpha Centauri - Samulis - 07-31-2017 Yes, it's possible they used MIDI to some degree, but these files are as big as 20 KB and more- too big for most standard MIDI files! I quite frankly have no idea what technology they were using to accomplish this, but it seems very smart. I could be wrong and this could be a lot more common than I think- I've seen loads of console games distributed with special sounds, and PC games that come with soundfonts, but never a game with files that are not standard MIDI files and a load of raw samples. RE: Sid Meier's Alpha Centauri - Mattias Westlund - 07-31-2017 It appears the .amb files are actually some kind of midi files. RE: Sid Meier's Alpha Centauri - Samulis - 07-31-2017 Very cool! It does remind me of trackers in that case, since they combine MIDI and samples in files. I still don't get why they didn't use .mp3, although maybe the licensing for that was too much. Ogg Vorbis didn't exist at the time either, I assume. I played around with some of the samples in Maize. You can get some pretty interesting results, but they kept them very short so I assume loop points are needed. I reckon that is contained somewhere in the first part of the .amb's. I guess it should be pretty easy to turn it into a MIDI file then- just cut out the MIDI section in a hex editor or something, save it as a .mid, then build a quick soundfont or something using the samples and play back the track. Pretty rough, but would probably work. A smart enough person could probably make a program to convert the first part of the .amb into a .sfz file even, since basically all it seems to be doing is define sample paths and sample parameters. EDIT: it looks like a lot of people have assumed that it would be impossible to turn a MIDI file into part of an .AMB. I think the answer is simply a matter of copying the right part of it, and vice versa. I'll see if I can do an experiment. RE: Sid Meier's Alpha Centauri - Samulis - 07-31-2017 The experiment was a resounding success! I managed to extract a MIDI file from the .amb- and more (read on). The MIDI file loaded up zero problems after extracting the data following the MIDI track header and saving it as a .mid, I assume it is correct, but I could be wrong, in Sonar- [attachment=36] The hex editor does indeed say there are 26 tracks, and there they are in Sonar, so I can't see that any issues occurred. For the immensely curious, here's the complete MIDI header, with the portion that designates the number of tracks highlighted. This portion is hex for '26'. From there I decided to map instruments in Kontakt (which can import .wav files by drag and drop). I tried a file and found apparently (at least some of) the .wav files have loop points designated in them, because Kontakt automatically looped a strings sample perfectly without me having to touch anything. However, at this point I found an issue: although most of the instruments included note names, how was I to know which samples were used out the set (did they use ALL of the samples for a given instrument or just pitch shift one?), AND how were they mapped (it's always possible they didn't actually map them directly to the keys they were assigned). To answer this, I was inspired by the forum post you found where they mentioned that first they establish programs, and then paths. This is like making regions in SFZ, and the assigning samples. I took a look in the file and found this section- My first guess was that the number after the period was the key, i.e. 37 (which ends up being hex for G3). However, this was incorrect, as noted previously, and then I looked around and found that the value after the period actually corresponds to the NEXT path, that is to say, the key is defined and then the path. In this example, 3C = C4 in hex (midi note 60). I also see '38' later on. This appears to be the lower stretch (in this case, Ab3). The '01' three from the start of the path appears to be a simple indicator of which program this sample is for- as for the second program ('backwards'), it is instead '02'. There are still lots of other values, particularly preceding and following the patches including a 'kmap' (which I assume means 'keymap'), and information in what appears to be the 'program header' where the patch is named before the files are linked and mapped. But, we have enough information, we can map some instruments! The first thing we notice is that the mapping is terrible. Everything appears stretched down and nothing appears stretched up, meaning that unlike a balanced mapping, the instruments end up with rather sudden changes. This may be part of the system, however- there is the possibility their engine couldn't increase the sample rate, or maybe that doing so would be too costly, or even that this was just the easiest way to do it. Here's what our map looks like in Kontakt. I didn't stretch it up because I didn't see any inherent instruction to do so, but I assume that if this behaves like most simple samplers, the highest sample should be stretched to the edge of the key range. And... like a sound from the lost deep of time, here's what our single track sounds like- https://instaud.io/18Gr?t=2s Whew! Figuring out an entire primitive sampler system in a hex editor is exhausting! Time for a break.  I'm going to see if I can do some more work later, and hopefully share an unprocessed track or a portion thereof later!