Cool how you CAN compress 47 minutes of audio down to 1.6MB if you're willing to accept awful sound quality, sure. Why though? I mean, why thank the OP for their service? I don't get it.
Because processing power,bandwidth, storage space, battery capacity are not limitless resources. Computing power has been massively increased over the last few decades and yet we don't often see the 1000x increase in performance that we really should as developers have often squandered that performance.
The closer we get to pushing the limits of physics, while still expecting computing to be faster, higher resolution, etc. We should commend any efforts to make computing more efficient and less resource intensive.
Speex is cool technology from what I can tell, but it's not exactly designed to run on a Commodore 64. E.g. it's used for the voice compression of commands sent to Siri.
What it saves in bandwidth, it pays in processing power.
But anyway, that still doesn't explain why posting these files is so cool that the post shot to the top of HN.
These sound terrible. The lowest-quality audio from Youtube is about 10x the size (which is still small), but at least it doesn't sound like a rescued wax cylinder recording from the turn of last century.
I had hoped from the title that this would be a summarized or edited cut of the salient points from these lectures. My limited resource these days is not bandwidth or disk space, but time.
I store these in an archive in my syncthing directory. I don't have to think about running out of space on mobile or too much cost for the cellular downlink.
These are encoded with Speex, the precursor to opus. If you actually want to download the audio, you can use youtube-dl to get opus encoded audio-only recordings directly:
> youtube-dl -F "https://www.youtube.com/watch?v=AD4b-52jtos1"
[youtube] AD4b-52jtos: Downloading webpage
[youtube] AD4b-52jtos: Downloading video info webpage
[info] Available formats for AD4b-52jtos:
format code extension resolution note
249 webm audio only DASH audio 51k , opus @ 50k, 16.97MiB
250 webm audio only DASH audio 57k , opus @ 70k, 17.50MiB
171 webm audio only DASH audio 99k , vorbis@128k, 31.57MiB
251 webm audio only DASH audio 106k , opus @160k, 32.55MiB
140 m4a audio only DASH audio 132k , m4a_dash container, mp
4a.40.2@128k, 43.56MiB
160 mp4 194x144 144p 69k , avc1.4d400c, 30fps, video on
ly, 10.50MiB
278 webm 194x144 144p 86k , webm container, vp9, 30fps,
video only, 22.85MiB
133 mp4 322x240 240p 121k , avc1.4d400d, 30fps, video on
ly, 17.77MiB
242 webm 322x240 240p 153k , vp9, 30fps, video only, 26.6
1MiB
18 mp4 352x262 small , avc1.42001E, mp4a.40.2@ 96k, 114.
86MiB
43 webm 640x360 medium , vp8.0, vorbis@128k, 136.89MiB (b
est)
The lowest quality version (opus @ 50k) is around 17mb compared with this author's 1.5mb speex version.
I really like the idea, but I find Speex distorts the audio way too much in a way that makes it hard to understand afterwards. I'm willing to sacrifice as much quality as I can as long as the speech remains easy to understand, but after that, any space savings aren't worth it.
24 comments
[ 3.8 ms ] story [ 77.3 ms ] thread> you can save some bandwidth in exchange for recording quality by using high compression of Speex algo
how about using opus[0], the comparison chart[1] shows that opus is supposedly significantly better even at a lower bitrate.
[0]: https://www.opus-codec.org/
[1]: https://www.opus-codec.org/comparison/
Cool how you CAN compress 47 minutes of audio down to 1.6MB if you're willing to accept awful sound quality, sure. Why though? I mean, why thank the OP for their service? I don't get it.
The closer we get to pushing the limits of physics, while still expecting computing to be faster, higher resolution, etc. We should commend any efforts to make computing more efficient and less resource intensive.
It's like patting someone on the back for knowing how to use ffmpeg.
What it saves in bandwidth, it pays in processing power.
But anyway, that still doesn't explain why posting these files is so cool that the post shot to the top of HN.
This article shot to the top because of at least three things:
1. It was well written.
2. It had to do with cool tech in a complicated problem space.
I only know those two.
I had hoped from the title that this would be a summarized or edited cut of the salient points from these lectures. My limited resource these days is not bandwidth or disk space, but time.
https://www.youtube.com/watch?v=a1zDuOPkMSw