I wanted to know how well this compared to ffmpeg | base64 (or base{emoji}), but actually I can't make anything that sounds as good in as small a filesize.

The FMT version is 2379 bytes of shell.

Opus bottoms-out at 6000bps (even when you ask for something smaller like 4000bps):

    ffmpeg -i tripple.wav -ac 1 -ar 8000 -b:a 4000 -ss 4.9 -t 3 tripple.opus

That makes a 3638 byte file. It sounds a lot better than the FMT version, but it's 1.5x the size and still non-printable.

Speex can apparently go as low as 2000bps:

    ffmpeg -i tripple.wav -ac 1 -ar 8000 -b:a 2000 -ss 4.9 -t 3 tripple.spx

That makes a 1322 byte file, or 1788 after base64, much smaller than FMT, even after you add the necessary base64|ffplay shell wrapping. But it sounds significantly worse than FMT (and ffmpeg had clipped off the last few audio frames).

EDIT: AMR-NB (1999) can drop to 4750bps, and Codec2 (2011) can drop to 450bps, but my copy of ffmpeg doesn't support encoding into either format.

> If the thought of running a huge untrusted shell command full of obviously compressed text scares you (like it should)

If, however, I clone it from GitHub and build it without looking at the source, it's good to go.

this is pretty fun. Seems like it's in the same vein as the libraries that let you convert video to ascii to play in terminal. No real-world use but they're a nice display of skill and definitely make you smile.

So, you convert the video and audio and play them in the terminal.

echo -n is not POSIX. Use printf '%s\n' "$var" instead.

bsd is unix

gnu is unix

I don't have the xxd nor aplay commands on my system, but I do wonder: Is there a reason for the whole rigmarole instead of just using base64?

yes, this is significantly denser (shorter total length) than encoding actual audio

Treat the Linux commands as individual characters in your base64 encoder. There are a whoooooole lotta available Linux commands!