<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Generative Speech Coding with Predictive Variance Regularization · HackerPapers discussions</title><link>https://hackerpaper.kaipfister.de/p/2102.09660/</link><description>Collected HN comments and submissions linking this paper.</description><language>en</language><lastBuildDate>Mon, 02 Nov 2026 11:16:22 GMT</lastBuildDate><atom:link href="https://hackerpaper.kaipfister.de/p/2102.09660/feed.xml" rel="self" type="application/rss+xml" /><item><title>Generative Speech Coding with Predictive Variance Regularization — mentioned by cbhl</title><link>https://news.ycombinator.com/item?id=37153300</link><guid isPermaLink="false">urn:hackerpapers:mention:2102.09660:37153300</guid><pubDate>Wed, 16 Aug 2023 20:27:51 GMT</pubDate><description>&lt;p&gt;The author, Fabrice Bellard, is well-known for his work on QEMU (among other things), but I&amp;#x27;d treat the rest of the posts as &amp;quot;idea sharing&amp;quot; at an early stage. For example, while BPG (Better Portable Graphics) didn&amp;#x27;t take off, the core idea (image formats based on video codecs) can be found in WebP (VP8, VP9) and AVIF (AV1) and HEIF (HEVC/H.265). For this, I&amp;#x27;d look at comparable work in the audio codec space, including Lyra (https://arxiv.org/abs/2102.09660) and SoundStream (https://arxiv.org/abs/2107.03312). For text compression, I think it would be novel if you could get a lossy but…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2102.09660/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>eess.AS</category></item><item><title>Generative Speech Coding with Predictive Variance Regularization — mentioned by bscphil</title><link>https://news.ycombinator.com/item?id=26311028</link><guid isPermaLink="false">urn:hackerpapers:mention:2102.09660:26311028</guid><pubDate>Tue, 02 Mar 2021 01:58:00 GMT</pubDate><description>&lt;p&gt;Worth noting that the paper itself explicitly says 90ms algorithmic delay. Seems plausible to me that there might be additional processing required on top of that, and then you have to add network transit time... suffice it to say that the vast majority of use cases are going to be better served by Opus, for the time being. &amp;gt; The overall algorithmic delay is 90 ms https://arxiv.org/pdf/2102.09660.pdf&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2102.09660/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>eess.AS</category></item><item><title>Generative Speech Coding with Predictive Variance Regularization — mentioned by adrianmonk</title><link>https://news.ycombinator.com/item?id=26310548</link><guid isPermaLink="false">urn:hackerpapers:mention:2102.09660:26310548</guid><pubDate>Tue, 02 Mar 2021 00:48:38 GMT</pubDate><description>&lt;p&gt;Definitely a real effect, but it seems like Google accounted for that in their listening tests. The Google blog post links to the Lyra paper[1], and Section 5.2 of the paper says: &amp;gt; To evaluate the absolute quality of the different systems on different SNRs a Mean Opinion Score (MOS) listening test was performed. Except for data collection, we followed the ITU-T P.800 (ACR) recommendation. You can download those ITU test procedures[2], and skimming through that, it does mention making &amp;quot;the necessary gain adjustments, so as to bring each group of sentences to the standardized active speech…&lt;/p&gt;&lt;p&gt;&lt;a href="https://hackerpaper.kaipfister.de/p/2102.09660/"&gt;Paper and discussion history&lt;/a&gt;. A mention is not an endorsement.&lt;/p&gt;</description><category>eess.AS</category></item></channel></rss>
