All files including decoded audio can be downloaded here: EDRAM files
The EDRAM card for the DMS-100 is the Enhanced Digital Recorded Announcement Machine. The purpose of the card in the DMS is to provide various call treatment announcements (such as 'Your call cannot be completed as dialed' or 'The number you have dialed is not in service') as well as generate some tones for the switch. The EDRAM replaced and supplemented the functionality of the DRAM, which was an entire card shelf that performed similar announcement functions. An interesting point of note is that the EDRAM cards are a single-card voice peripheral module. This means the EDRAM gets it's own DS-30 as a single card. The only other card I'm aware of like this is a 30 port conference card (configurable as a mixture of 3- and 6-port submodules, for 3 way and 6 way calling features). [editor's note: this used to incorrectly state that the EDRAM card was, to my knowledge, the only single-card peripheral. However I remembered that the 30 port conference card also existed and was similar in this fashion.]
Perhaps some other time, I'll write more about the card itself, but for now I created this page so I could document some work that was done to take the files from the DMS-100 that get loaded into the EDRAM by the control complex and decode them into a more standard audio format. The work isn't 100% complete and there's more to the format to be understood, but enough work has been done that individual samples and announcements could easily be pulled out of the data at this point. The collection of everything can be found here.
Most of the files used with the EDRAM are so-called bin44 files, though a couple were S-record. The S-record files likely contain the same type of binary blob as the bin44 do, so I'll start with those.
Starting with the files directly and attempting to play them using a few common telephony codecs revealed that G.711 Alaw produced the best results, but there was still something missing. Aside from high degree of noise or distortion as well as some tonal artifact, the voice announcements were understandable.
(audio is LOUD)
Looking at the files in hex editors revealed a repeating pattern: the files contain headers, which is to be expected and not really a surprise. This would explain the tonal artifact heard in the raw file, at least.
The format of the original files feel very similar to an S-record format, which I will nickname the G-record format (given that each record starts with the ASCII code for the letter G). This has also been referred to as bin44 given the bin44 file extension used.
Unlike S-record, the file is not remotely human readable given the more binary nature, but shares what feels like a similar structure. My suspicion is that a G-record, like an S-record, is merely a way to store what amounts to a binary data blob with specific address locations encoded as part of the file. The exact format and meaning of that binary data blob and the significance of the addressing is dependent on what it's being loaded into (in this case, an EDRAM card).
I'm not the first person to have taken a look at the G-record format, so I was not starting from scratch. Firstly it was obvious that the record length was always a fixed 44 bytes, and always began with the ASCII code for 'G' followed by ASCII codes for '0', '2', or '6'.
At the start of each file was a single G0 record, followed by a number of G2 records, finally ended with a single G6 record at the end. The third byte appeared to contain a length in bytes, the fourth through sixth bytes a 24 bit big-endian address, seventh through 42nd bytes are the data, 43rd is a checksum byte, and the last is always 0x16 (possibly a terminator byte of a sort). I was also able to establish that the checksum byte was calculated similar to an S-record. That is, an 8 bit checksum performed on bytes three through 43 should always add to 0xFF
000000 47 30 24 00 00 00 00 01 01 d0 04 01 02 d5 0c 01 0a 35 34 01 01 b4 38 01 03 e0 44 01 03 21 50 01 03 18 5c 01 03 63 68 01 03 29 ae 16 >G0$..............54...8...D..!P...\..ch..)..<
00002c 47 32 24 00 00 24 74 01 03 8a 80 01 03 2f 8c 01 03 8d 98 01 03 eb a4 01 01 48 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 80 16 >G2$..$t....../...........H..................<
...
07bf44 47 32 24 07 5b 34 81 00 00 00 00 00 00 00 81 00 00 81 00 00 00 00 81 81 00 00 00 00 81 00 00 81 00 00 00 00 00 00 00 00 00 81 3d 16 >G2$.[4....................................=.<
07bf70 47 32 18 07 5b 58 00 00 81 00 00 00 01 00 81 00 00 00 81 81 00 00 00 00 00 00 00 00 00 00 28 00 00 00 00 00 00 00 00 00 00 00 00 16 >G2..[X........................(.............<
07bf9c 47 36 01 1a 1f e9 75 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 >G6....ug....................................<
07bfc8
With the file format at least partially understood, I wrote some dirty code to strip the headers and leave me with just a straight binary dump of the data.
(audio is LOUD)
This time the audio lacked the tonal artifact, but was still heavily distorted. We contemplated a number of possibilities such as bits robbed from samples for sidechannel data of some sort, alternate bit depths, proprietary codec types, byteswapping for endianness differences, and bitshifting for unknown reasons.
However, one possibility that didn't come up until I read the wikipedia page on G.711 was XOR. It turns out that A-law, once it has been converted into a companded mantissa/exponent format, is finally XORed with 0x55 (presumably to do rudimentary scrambling for plenty of 1 bits for E1 or T1 synchronization).
With that as a hunch, I modified my bin44 stripper to also XOR the payload data with 0x55. This turned out to be the key, and the decoded audio now sounded great when played as A-law.
While this gets us audio that sounds good enough to play and listen to, there's still more details about the internal format of the EDRAM data that aren't understood. I suspect there are some headers at the beginning of the data, and also that there may be some headers or padding between different announcements or tone samples. Some day I may find some time to continue farther with understanding that formatting, and it may also help to have access to an EDRAM to generate files with known content for the purpose of testing the behavior of the file format.
All of the decoded audio from the stock DMS sets can be downloaded from the link at the top of this page.