It sounds like a fun idea to play with and think about, but there are a lot of things that you need to take into account. Start thinking more about the required bandwidth.
If your using those links to support the assertion that "the spy agencies use the damn thing", don't. At least, not in the context that your intending. All of those "spy" devices didn't deal with audio. They all talk about Morse Code or RTTY (FSK). Voice doesn't have the power density that these modes have and wouldn't be very useful for critical messages. Their meaning of "high speed" is quite different than yours. Their intent was to transmit a longer more detailed message, at high speed, so that their message could be completed before anyone could locate them. But their pre/post encoding operations were quite lengthy.
If you now take this to the audio range, you need to think about the pre/post steps that need to be done. A simplified approach would be to select a audio bandwidth that maximize intelligibility yet minimize bandwidth, say 1.9 KHz. Then, sample the audio at a rate such that the audio can be put back together later, without losing intelligibility. To then put this on a carrier, you would need to serialize it, so each audio sample will take 8 to 10 times longer to send. If you add error correction, even longer. On the other end, you will have to put this back together and convert back to analog.
You could use compression to squeeze the audio samples into a smaller package, but you would also need to decompress on the other end. Something simple, like a DPCM, could cut your data requirements immediately in half. With DPCM you only send a 4 bit number that represents the encoded difference from one sample to the next. Old technology but still useful.
But by the time your done figuring out the bandwidth required to store 120 minutes of audio, convert it and prep it for a 1 second transmission, you will need in excess of 100 MHz of bandwidth. That easily exceeds the capabilities of any, easily available, RX/TX.
Just as an example of bandwidth requirements, about 35 years ago I worked on a program where we data-linked to an jet flying at 35,000 Ft that was sending us real time radar data. There were two channels of analog (I and Q) information, plus what ever was necessary to track the signal. The bandwidth required for these signals was in excess of 200 MHz. However, we were running at 18 GHZ, so we had the room.
On the receiving end, each received channel had to be sampled by A/D converter that ran with a 100 MHz clock, and the samples then had to be stored on magnetic tape. To do that, the data samples had to be slowed down by a 6:1 de-ramp buffer and then stacked 4 words high (6-bit words) for writing to a 24 channel tape unit. Even at that reduced rate the tape had to run in excess of 150 IPS. Each tape could hold about 15 minutes of data. On playback, if you then slowed the tape down so that the data rate was slow enough for a computer to process the data (1-7/8 IPS) the tape took almost 24 hours to play back.
So I am not saying, don't continue with your idea. All I am saying is to consider the requirements of each device as you work through your idea. Possibly start with greatly reduced requirements and work your way up. And then expect the possibly that the whole idea might just be impractical.