[HN Gopher] The Quite OK Audio Format for Fast, Lossy Compression
___________________________________________________________________
The Quite OK Audio Format for Fast, Lossy Compression
Author : smlckz
Score : 76 points
Date : 2023-08-08 11:27 UTC (1 days ago)
(HTM) web link (qoaformat.org)
(TXT) w3m dump (qoaformat.org)
| marcoc wrote:
| How can one create a professional looking pdf like the QOAF
| specification one?
| [deleted]
| GraemeMeyer wrote:
| Two-column layout in Microsoft Word, large header, smaller
| footer, with appropriate font choices would get you basically
| all the way there.
| jfk13 wrote:
| HTML+CSS, converted to PDF via the Save As PDF feature in
| Firefox. (Or the same could be done with other browsers, but
| this one apparently comes from FF.)
| crumpled wrote:
| I looked at the PDF, and can confidently say I could typeset
| that in a word processor, using a stylesheet to sustain it.
|
| That's not what they did, apparently.
|
| The document properties call out https://cairographics.org
| kenferry wrote:
| Cairo's a couple layers down from what you're talking about.
| It's the actual glyph rendering.
| codeflo wrote:
| It's interesting that this works in the time domain (instead of
| frequency domain), and I wonder what the resulting quality
| limitations are, if any. The sound samples on the demo page, at
| the least the dozen I clicked on, didn't seem all that
| challenging. Few, mostly synthesized instruments, low dynamic
| range. My ears aren't good enough to evaluate audio codecs
| anyway, however.
| MobiusHorizons wrote:
| Seems to have similar design criteria as opus but I don't see any
| comparison.
| rockstarflo wrote:
| What is the tradeoff there?
| daneel_w wrote:
| That in terms of quality per any bitrate it comes nowhere near
| ubiquitous formats like AAC or MP3 when produced with good
| encoders. But it's good to have (possibly) patent-free
| solutions available.
| DamonHD wrote:
| > QOA is slower than ADPCM, doesn't compress as much as MP3 and
| sounds worse than FLAC (duh). But I believe it fills a gap that
| was worth filling.
| jandrese wrote:
| MP3 compression is very fast on modern hardware. This may
| have a niche for low power devices, especially if they are
| battery constrained.
| kragen wrote:
| "very fast" could mean many different things that vary by
| orders of magnitude
| dale_glass wrote:
| It's probably something we (https://overte.org/) can use.
|
| We have a 3D environment with spatial audio. Audio is
| encoded server-side, and since it's spatial everyone needs
| their own mix. We're using Opus, and audio encoding turns
| out to be the usual limiting factor on small servers.
|
| So this kind of thing is exactly up our alley: an alternate
| option that uses less CPU than Opus, but consumes less
| bandwidth than raw audio.
|
| But adding supporting for FLAC is also on our list. It
| seems nicely performant when compared to Opus.
| brnt wrote:
| Doesnt Opus (speex?) have some low CPU settings?
| dale_glass wrote:
| It does, and I've tried tweaking that, but the
| performance difference isn't very significant.
|
| I appear to be able to get maybe 30% better performance
| -- pretty nice, but not nearly big enough especially on
| low end servers.
| doublepg23 wrote:
| I'm not sure much gets better latency than Opus but
| LyraV2 seemed interesting https://opensource.googleblog.c
| om/2022/09/lyra-v2-a-better-f...
| dale_glass wrote:
| Could be an option, but we take high audio quality as a
| point of pride and encode in Opus 128k by default. Audio
| doesn't only include speech but also any sound effects,
| media present in-world, etc.
|
| But that might be an interesting experiment. Right now
| the low cpu usage/high quality/faily high bandwidth usage
| category is something we're looking to have an option
| for.
| Aldipower wrote:
| An _audio_ format which is _quite_ ok? Not sure, if I need that.
| Pet_Ant wrote:
| What is the LFE channel?
|
| It should be spelled out explicitly, but I figured out the rest
|
| L-Left,R-Right,C-Center,FL-Front Left,FR-FrontRight,SL-
| SideLeft,SR-SideRight,BL-BackLeft,BR-BackRight
|
| ---
|
| Edit: LFE-LowFrequencyEffects... so subwoofer?
|
| https://www.dolby.com/uploadedFiles/Assets/US/Doc/Profession...
| entropicdrifter wrote:
| LFE is an industry standard term for the subwoofer channel.
| It's the ".1" in "5.1","6.1","7.1" etc
| bravura wrote:
| Low frequency energy, I assume. Ie bass. Your subwoofer or
| ,,bottoms" if you have several.
| ok_dad wrote:
| LFE is usually a bass shaker which is a subwoofer but it moves
| a weight instead of a cone, so you get vibrations in your seat.
| It stimulates movement to your body somewhat, I use two for my
| sim racing rig, one under my seat to inform me of the car
| dynamics and immersive feeling, one under my pedals to inform
| me when ABS is active and when my tires are spinning.
| ape4 wrote:
| What's going to be the next Quite OK thing?
| p1mrx wrote:
| Quite OK Food. It tastes like sand but the shelf life is above
| average.
| m463 wrote:
| Sounds like soylent. (except my direct experience with
| soylent leads me to think super-processed isn't that OK
| foodwise)
| bartwe wrote:
| Hopefully a movie format
| WithinReason wrote:
| MPEG1 is actually quite OK
| kragen wrote:
| has anyone benchmarked qoa to see roughly how many instructions
| per sample it needs? all i see here is that it's more than adpcm
| and less than mp3, but those differ by orders of magnitude
|
| like, can you reasonably qoa-compress real-time 16ksps audio on a
| 16 megahertz atmega328?
|
| hmm, https://phoboslab.org/log/2023/04/qoa-specification has some
| benchmark results, let's see... seems like he encoded 9807
| seconds of 44.1ksps stereo in 25.8 seconds and decoded it in 3.00
| seconds on an i7-6700k running singlethreaded. what does that
| imply for other machines?
|
| it seems to be integer code (because reproducibility between the
| predictor in encoding and decoding is important, and a
| significant part of it is 16-bit.
| https://ark.intel.com/content/www/xl/es/ark/products/88195/i...
| says it's a 4.2 gigahertz skylake. agner says skylake can do 4-6
| ipc (well, mops/cycle)
| https://www.agner.org/optimize/blog/read.php?i=628,
| coincidentally testing on an i7-6700k himself, but let's assume
| it's 3 ipc, because it's usually hard to reach even that level of
| ilp in useful code
|
| so that's about 380 mops per sample if i'm doing my math right;
| that might be on the order of 400 32-bit _integer_ instructions
| per sample on an in-order processor. if (handwaving wildly now!)
| that 's 600 8-bit instructions, the atmega328 should be able to
| encode somewhere in the range of 16-32 kilosamples per second
|
| so, quite plausibly
|
| for decoding the same math gives 43 mops per sample rather than
| 380
|
| i'm very interested to hear anyone else's benchmarks or
| calculations
| Turing_Machine wrote:
| I looked around, but didn't see any mention of potential patent
| issues. I assume that this has been considered? The Ogg Vorbis
| people spent a lot of time on that back when they were developing
| their format.
|
| Other than that, looks great!
| speedgoose wrote:
| The website says it's made in Hesse. No software patents to
| care about there.
|
| https://en.m.wikipedia.org/wiki/Software_patents_under_the_E...
| morelisp wrote:
| Probably the most infamous audio format patent ever was owned
| by a German research institute.
| speedgoose wrote:
| I guess you mean this one:
| https://patents.google.com/patent/US5812672
|
| That was an USA patent from Fraunhofer, who made quite some
| cash from mp3 license fees (100 000 000EUR according to
| Wikipedia).
| nullc wrote:
| No. The claim that there are no patents in Germany on
| this stuff is common internet misinformation(*). There
| are a great many coding patents from Fraunhofer all
| around the world, including in Europe.
|
| Presumably because it's much easier to get injunctive
| relief in Germany I've seen more codec related litigation
| there than anywhere else.
|
| (*) Like many pieces of misinformation it has its roots
| in a seed of truth: Particularly between 1998 (State
| Street) and 2014 (CLS v Alice) the case law in the US
| supported software patents.
|
| The real confusion is that "Software patents" is an
| obscure term of art which refers to patents specifically
| on software methods without any reference to a physical
| machine or good.
|
| When non-patent-attorneys say "software patents" they
| mean something more like "something I could infringe by
| writing software". But clever drafting allows people to
| write patents that software causes an infringement of
| without it technically being a "software patent": The
| patent's claims language will say something like "A
| recorded media containing instructions..." or "A
| microprocessor programmed to...". And this has been true
| in the US and Europe through the whole span.
|
| Which is why there is an awful lot of patent action
| impacting software in places where "software patents"
| don't exist, such as the US (as of right now) and Europe.
| IshKebab wrote:
| You can absolutely patent software in Europe. Sorry. It's a
| common misconception that you can't. There's a stupid dance
| you have to do so it isn't technically "software" that you're
| patenting... but really it is.
| Turing_Machine wrote:
| Maybe not, but that doesn't help people who aren't using it
| in the EU.
| speedgoose wrote:
| True, it hasn't stopped hobbyists from using x264, ffmpeg
| or VLC in the past but that would probably prevent
| companies in some markets to use this audio format.
| ericls wrote:
| The smaple page preloads all the files before playing... Which
| wastes lots of bandwidth.
| g0xA52A2A wrote:
| Some previous discussions.
|
| 3 months ago - https://news.ycombinator.com/item?id=35738817
|
| 6 months ago - https://news.ycombinator.com/item?id=34625573
___________________________________________________________________
(page generated 2023-08-09 23:00 UTC)