I don't know audio well enough to answer this, but you can play with it directly; it took about 7 minutes for me to throw a trivial Go program together to AAC-encode a WAV of half a minute of speech; the only repeated 16-byte blocks I got were a couple runs of zeroes.

The trick with ECB is that you're relying on 128-bit blocks of plaintext repeating with perfect alignment, and, to do anything useful with it, those repeats leaking useful information. In a bitmap image of a penguin, those repeats are easy: they're blocks of pixels of uniform color, and all ECB is doing is permuting their colors. That's less intuitively true of audio (where I'm not really seeing repeats at all, but, again, you should just play with it).

For audio, you don't want to send a wav file over the line, as it's incredibly wasteful. Once it's reasonably encoded, you necessarily end up with a lower entropy steam... So should still have some version of "solid blocks of color", especially for silence. (Exact details depend on the codec, though.)

Lossy compression reduces entropy, I'd expect fewer repeats and more of what looks like random data in any compression worth its salt. Thomas also mentioned AAC, not PCM. I agree on the silence, but it would come up as smaller packets, not repeated packets, IMO. And then we're back to timing analysis of speech.

> Lossy compression reduces entropy, I'd expect fewer repeats and more of what looks like random data in any compression worth its salt.

Um, so, just to make sure I understand you, you're implying that lossy compression is not worth its salt? Because you will surely have more repeats in a lower entropy space.

You get essentially no repeats (collisions, more precisely) in the AAC streams I played with. Some block boundary headers; that's it.

I'm not sending a WAV file (or modeling that); I'm AAC-encoding.

Opus is probably the right codec for some things. I've heard good things about it.