Hacker News Reader

Comment by pjc50 | Hacker News Reader

One thing I'm slightly worried about "machine learning" in compression rather than conventional everything-is-sines mathematical approaches is the possibility of odd nonlinear errors. Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers?

I don't mind compressing a phoneme to <unintelligible> as much as I would mind it compressing it to a clearly audible different phoneme.

View on HN

Are you aware that the same exact uncompressed recording sounds different depending on context? This is known as the McGurk effect.

Very worth your two minutes if you're not yet familiar with the effect: https://www.youtube.com/watch?v=2k8fHR9jKVM

While fascinating, that’s not the same as a codec failing silently by literally changing one word into another, equally clear word instead of getting fuzzy or unintelligible.

At the end of the day, it all comes to using the right tool for the job, and this is just another codec in your toolbox.

This is no different than using, for example, a probabilistic algorithm to solve some NP-hard problem in your real world software. As long as you understand the limitations, I don't see an issue with using an algorithm that has a small non-significant (for your use-case) rate of failure. I would definitely not use this to communicate with the space station, but in the right context (Google Duo, low bandwidth), it's the perfect tool.

It would be curious how the court would interpret this. Just wait for the next high profile SEC shakedown.

That’s probably meant for another thread

I meant phone taps.

[disclaimer: Personal opinion, not that of my employer.]

I had a coworker play me before/after of an early version of the codec "babbling" and it was definitely uncanny valley. It looks like some work has been done on the problem since then.

The second paper linked in the README.md of the repo talks about talks about a few strategies to reduce 'babbling' or 'babble'. For your reference, here's the citation and the link to the PDF.

Denton, T., Luebs, A., Lim, F. S., Storus, A., Yeh, H., Kleijn, W. B., & Skoglund, J. (2021). Handling Background Noise in Neural Speech Generation. arXiv preprint arXiv:2102.11906.

https://arxiv.org/pdf/2102.11906.pdf

This already happens with existing compression algorithms. Certain vowel sounds get collapsed, so someone will say, for example, "66" and it will come out on the other side as "6". Very annoying because you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse.

I'm having a little trouble following this, could you explain a bit more? It seems to me like "66" would be pronounced "SIKSIKS", so for that to become "SIKS" would mean the "KS" (consonants) would be collapsed, no? (Not trying to refute you or anything, just understand :) )

Probably turn into something like SIIIIKS.

Exactly, but sometimes it's so subtle you can't even tell it's the compression taking over.

As someone with a weird sibilant that doesn't seem to compress well, I want to say that it goes across as "sɪkɪks" and I got used to saying "double six" on the phone.

So I would say "seven nine double six", which is another problem if I'm talking to an American.

This applies to GSM digitization and other "regular phone" compression, the newer computer calls have been better at taking the words.

> you can't exactly coach a layperson on how to talk "the right way" to not trigger this vowel collapse

I've never noticed. At any rate, we should not coach people to adapt to technology in this way. It is Procrustean and anti-human and unnecessarily places a burden on people that belongs to the software and the developer.

For what it's worth, amateur radio operators already have specialized rules and techniques for speech, to improve clarity over a muffled noisy analog radio channel.

Going as far as using trinary for on the fly data encoding .

I've always suspected the optimal experience is a balance...we define some intermediate language that both the computers need to be programmed to understand and humans need to be trained to adopt.

The most obvious example is learning to type...I've had by far the most fun working with computers in a keyboard-centric environment, mostly because I'm good enough at pressing keys and the computer is good enough at understanding them.

That said, I agree with both you and GP: trying to train a layperson to talk differently based on the quirks of the codec used to encode their voice seems like a poor choice!

> how to talk "the right way"

Not suggesting it as a fix, but this did remind me of the military phonetic alphabet, which includes numbers too.

3 is "tree", 4 is "fow er", 5 is "fife", 9 is "niner". The rest of the numbers are mostly as-is, but you'll hear very deliberate enunciation, like "Zee Row" for 0.

whiskey hotel yankee delta oscar india hotel alpha victor echo tango oscar sierra papa echo alpha kilo tango hotel echo lima alpha november golf uniform alpha golf echo oscar foxtrot tango hotel echo mike alpha charlie hotel india november echo ? tango hotel alpha tango india sierra india november sierra alpha november echo!

Humans adapt a whole hell of a lot easier than machines.

Sure, it would be nice to have clean high bandwidth, low latency voice channels to everywhere so you could drop pins and expect the other side to hear it. Unfortunately, high bandwidth never really happened, and some places never ran land lines to everyone's home, and nobody wants to pay the high price of circuit switched voice when packet switched voice mostly works good enough and is enormously cheaper.

But is Lyra a significant improvement over modern Opus at 8Kbps? You can buy a Grandstream HT802 for ~$30 and its DSP can decode Opus today, whereas Lyra will require orders of magnitude more power to decode while providing much worse reproduction accuracy.

| perl -pe 's/(\w)\w+/\1/g'

I don’t know if it’s improved over the last 6 months, but Zoom sucks for Native Spanish speakers speaking English. Like zoom would not pick up the J/H sound at all on English words.

This one too:

https://petapixel.com/2020/08/17/gigapixel-ai-accidentally-a...

Thats not a compression algorithm

A supersampling algorithm is a (de)compression algorithm. You give it an image and it gives you an "decompressed" image. It's not a very good one though.

The OCR issue was the first thing I thought about. Machine learning is probabilistic, not deterministic, so in the case of S being converted to 5 (or 6 to 8, etc.), which definitely impacts numerical data in the case of the OCR stuff, we can expect similar voice mis-classifications. Perhaps "You're fine" might get misclassified as "you're fired".

>Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers?

For those who don't remember: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...

>photocopier that worked by OCR

The interesting bit was that it wasn't supposed to work by OCR...that had been deliberately turned off. The compression was too clever.

Back when Lyra was announced [0], I listened to the released samples and it changed an "m" sound to an "l" sound.

[0]: https://news.ycombinator.com/item?id=26309553

IMO: the output of machine learning is correlated garbage. This is confusing to most people who are used to programs that implement an algorithm (reminder that "correctness" is part of the definition of an algorithm.)

> Remember the photocopier that worked by OCR and would occasionally mis-transcribe numbers?

That was perfectly ordinary compression?

The phenomenon is all over the place, most visible in autocorrect.

It was ordinary compression, something called JBIG2. It did not mistranscribe, but mark slightly different number or character blocks as same, resulting replaced parts in images.

In other words, its match tolerance is a bit too lax, so it get poisoned by blocks in its own dictionary, thinking it already has the blocks for things it had just scanned.

More details can be found in [0] and [1].

[0]: https://www.theregister.com/2013/08/06/xerox_copier_flaw_mea...

[1]: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_...?

Yes! This is why I always turn off autocorrect! It’s true that I absolutely make more typos without it, but at least they’re obvious as typos, and not different words that potentially change the meaning of the sentence.

One day, voice cloning may become so powerful that only word data and intonations will become part of the datastream. There could be various 'layers' in which encodes/decodes can occur. Voice Cloning would be at the very top of the stack.

You mean like: "Buttle" vs. "Tuttle" ?

The problem with JBIG2 and why it mistranscribed is that it worked by average error, instead of something sensible like maximum error.

Reply on news.ycombinator.com