Live data from Hacker News

Codec2: A Whole Podcast on a Floppy Disk

auphonic.com

51–60 of 137 posts

Re: Codec2: A Whole Podcast on a Floppy Disk

#51
post #8

Earlier quoted context omitted.

As far as I know, enough podcast apps require MP3 (and not even VBR!) that you have to use MP3, and you can't have multiple s, so how would you do this? A separate RSS feed for Opus, linked only on the website and not submitted to aggregators?

> As far as I know, enough podcast apps require MP3 (and not even VBR!) that you have to use MP3… Nope! Podcast episodes can be encoded using AAC (which is as ubiquitous as MP3) without issue. That won't realistically possible with Opus until Opus hardware decoding has available in mobile devices for 5-10 years.

Distribute podcast as HTML file with WASM based decoder, whole file, self contained with either a byte stream out or play/pause

Re: Codec2: A Whole Podcast on a Floppy Disk

#52
post #40
post #21

Codec2 is also fully open source and patent-free, in contrast to virtually every other ultra-low-bitrate voice codec (which are proprietary and have expensive patent licensing attached). He has a Patreon if you want to support him in the ongoing development of Codec2 and his SDR modems to enable use of it in amateur radio: https://www.patreon.com/drowe67

Is Speex also in that category?

Speex and Opus bottom out around 6000-8000 bps. Codec2 starts at 3200 bps and goes down to 700 bps. The original target use for Codec2 is real-time transmission in the HF (shortwave) and VHF/UHF amateur radio bands where those are about as much as you can transmit within the same bandwidth as analog voice modes once you factor in error correction.

Re: Codec2: A Whole Podcast on a Floppy Disk

#53
post #39

Earlier quoted context omitted.

> t's the lossy jbig2 compression in Xerox copiers: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_... . My understanding of this fault was that it was a bug in their implementation of JBIG2, not the actual compression? Linked article seems to support this.

I think it was just overly aggressive settings of compression parameters. I don't see any evidence that the jbig2 compressor was implemented incorrectly. Source: [1] [1]: https://www.xerox.com/assets/pdf/ScanningQAincludingAppendix...

Right. Jbig2 supports lossless compression. I'm not very familiar with the bug, but it could have been a setting somewhere in the scanner/copier that it was changed to lossy compression instead. Or they had lossy compression on by default or misconfigured some other way (probably a bad idea for text documents).

Re: Codec2: A Whole Podcast on a Floppy Disk

#54

Earlier quoted context omitted.

Yes, and "certificates" sounds like "certiticates". Reminds me of a story about a copying machine that had a image compression algorithm for scans which changed some numbers on the scanned page to make the compressed image smaller. (Can't remember where I read about that, must have been a couple years ago on HN)

It's the lossy jbig2 compression in Xerox copiers: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_... And yes, I think this is a relevant comparison. As the entropy model becomes more sophisticated, errors are more likely to be plausible texts with different meaning, and less likely to be degraded in ways that human processing can intuitively detect and compensate for.

The algorithm detected similar patterns and replaced these with references. This lead to characters being changed into similar looking characters that also appeared on the page.

Re: Codec2: A Whole Podcast on a Floppy Disk

#56
post #39

Earlier quoted context omitted.

It's the lossy jbig2 compression in Xerox copiers: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_... And yes, I think this is a relevant comparison. As the entropy model becomes more sophisticated, errors are more likely to be plausible texts with different meaning, and less likely to be degraded in ways that human processing can intuitively detect and compensate for.

> t's the lossy jbig2 compression in Xerox copiers: http://www.dkriesel.com/en/blog/2013/0802_xerox-workcentres_... . My understanding of this fault was that it was a bug in their implementation of JBIG2, not the actual compression? Linked article seems to support this.

No compression system in the world forces you to share parts of the image that shouldn't be shared. So that's true in a vacuous sense.

But the nature of the algorithm means that you have this danger by default. So it's fair to put some blame there.

Re: Codec2: A Whole Podcast on a Floppy Disk

#58

Earlier quoted context omitted.

I think it was just overly aggressive settings of compression parameters. I don't see any evidence that the jbig2 compressor was implemented incorrectly. Source: [1] [1]: https://www.xerox.com/assets/pdf/ScanningQAincludingAppendix...

Right. Jbig2 supports lossless compression. I'm not very familiar with the bug, but it could have been a setting somewhere in the scanner/copier that it was changed to lossy compression instead. Or they had lossy compression on by default or misconfigured some other way (probably a bad idea for text documents).

The bad thing was that it used lossy compression when copying. That was the problem.

Re: Codec2: A Whole Podcast on a Floppy Disk

#59

Earlier quoted context omitted.

Actually if you're lucky and make a phone call with HDVoice, or whatever they're calling it, the quality is excellent. It makes a huge difference. Unfortunately the place where you really want good quality is call centres - it's often hard to hear people and half of the reason is the shitty POTS quality - and call centres will probably get HDVoice in about 40-50 years. Maybe. Edit: nm should have read all of your com…

>Actually if you're lucky and make a phone call with HDVoice, or whatever they're calling it, the quality is excellent Can confirm. I spend a lot of time in fringe reception areas, but every now and then I get a good, strong signal and the HD Voice kicks in between my iPhone and my wife's and it sounds like she's standing right next to me. It really is something to experience, especially if the previous phone call wa…

Also why no one really appreciated ISDN over here in central Europe. Yes, there are ways to do better _now_, and it would have been trivial to support channels with better codecs by negotiating something different than u-law 8kHz PCM, but back then that resulted in rather good quality. The issue was that few people got ISDN phones, which resulted in them using analog outputs on an adapter device, which got later incorporated into the internet router, which at one point switched from ISDN to VoIP. And people plug a phone via an analog jacket into the router, instead of using a VoIP capable phone or even anything digital. While many do use DECT cordless phones, those rarely use the DECT hardware inside the router, and instead use the one in the charging dock, which itself connects via an analog, POTS-bandpass-filtered, phone jacket to the VoIP router.

Oh well, we will probably never get that kind of quality, which is only possible with QoS on the whole path, if there is any congestion. That is the one thing something like rocket.chat and discord can't provide.

Edit: the way to do this is to force quality upon people, wherever you won't drive them away with the cost this incurs. That way people will associate your brand as a whole with the quality, i.e., in that case, people will associate AT&T with quality, not AT&T premium. Normal people do not even know what kind of plan they are on, except for about one hour before and after they sign the contract.

Re: Codec2: A Whole Podcast on a Floppy Disk

#60
post #58

Earlier quoted context omitted.

Right. Jbig2 supports lossless compression. I'm not very familiar with the bug, but it could have been a setting somewhere in the scanner/copier that it was changed to lossy compression instead. Or they had lossy compression on by default or misconfigured some other way (probably a bad idea for text documents).

The bad thing was that it used lossy compression when copying. That was the problem.

No. The bug was when using the "Scan to PDF" function. It happened on all quality settings. Copying (scanning+printing in one step, no PDF) was not effected.
Post reply on HN