[HN Gopher] QOA, the Quite OK Audio Format
___________________________________________________________________
QOA, the Quite OK Audio Format
Author : Mizza
Score : 133 points
Date : 2023-02-02 12:22 UTC (10 hours ago)
(HTM) web link (phoboslab.org)
(TXT) w3m dump (phoboslab.org)
| Jam-O wrote:
| Great! Excellent fit for DAWs where lots of samples stay in
| memory and decode concurrently.
| munificent wrote:
| A DAW is definitely not going to want to use a lossy format.
|
| Most DAWs store audio internally as uncompressed 32-bit floats.
| That gives them plenty of headroom (which is important for gain
| staging).
| bartwe wrote:
| Very interesting, when better formats like vorbis were too cpu
| intensive for my game I ended up with striped and delta encoded
| wav compressed using lz4hc for something that was somewhat
| compressed, streamable and light on the cpu, this seems somewhat
| close to that.
| distantsounds wrote:
| "There still remains a huge gap between lossless codecs at
| ~800kb/s and MP3 at 128kb/s with seemingly little interest to
| fill it."
|
| Not only does mp3 go to 320kbps, 192kbps was considered the
| 'standard' for ripping audio CDs, with the V0 variable bit rate
| being another common choice. if this only does 277, what am I
| getting aside from. another audio codec?
| skrebbel wrote:
| Simplicity and low cpu requirements.
| distantsounds wrote:
| the only time I ever had issues playing MP3s was on an old
| overclocked 486
| skrebbel wrote:
| Then maybe you're not the target audience
| distantsounds wrote:
| the target audience is practically non-existent. nobody
| with 40 year old hardware is clamoring for a new audio
| codec.
| usefulcat wrote:
| The target audience is games, not your music collection.
| skrebbel wrote:
| You underestimate the kind of people that use 40 year old
| hardware
| rogerhoward wrote:
| "The first lossless audio format to gain widespread adoption
| (FLAC) was released 6 years after MP3."
|
| AIFF and WAV say what?
| jefftk wrote:
| From context they mean lossless _compression_ audio format, and
| standard AIFF and WAV are uncompressed PCM.
|
| On the other hand, AIFF does have a compressed variant
| ("AIFF-C") spec'd in 1991 [1], which I suspect the author
| wasn't aware of.
|
| [1]
| https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/A...
| [deleted]
| Computeiful wrote:
| QOI caused a huge burst in interest for image formats. Audio is a
| little harder to work with and understanding so I can imagine
| less impact for QOA (still good though). What I'm really looking
| forward to is QOV (video).
| actionfromafar wrote:
| QOI is only 8-bit depth (per channel) so it's a no-go for me.
| But interesting, yes.
| stefncb wrote:
| Out of curiosity, what for?
| [deleted]
| actionfromafar wrote:
| I have a pipeline for scanning of analog sources like film.
| Since these are meant to be edited after scanning, 8-bit
| range is _much_ to limited.
| [deleted]
| dylan604 wrote:
| Not the OP but as an example, the difference between 8-bit
| and 10-bit on visual complexities like gradients are very
| noticeable.
| thanatos519 wrote:
| I render accumulation fractals like the Buddhabrot at 32
| bits per channel. So far I have only used about 27 bits but
| it's nice to have a bit of headroom.
| creshal wrote:
| I wonder how much complexity it would add to support 10 or 16
| bit per channel in the file format.
| adgjlsfhk1 wrote:
| you'd have to totally redesign the format. QOI is very
| specialized on 8 bits per channel (and RGBA)
| creshal wrote:
| The physical layout, sure, but would it conceptually
| involve more than just defining twice as large chunk
| types for 16 bit channels? Unless I'm missing something,
| it should be fairly uncomplicated code-wise?
| skrebbel wrote:
| Back in the day I made a few GameBoy Advance demos and we
| generally stored ADPCM encoded audio streams for the music, at
| like 4x the space of an equivalent MP3. Thing is, cartridge space
| was effectively uncapped but CPU speed (4MHz iirc) was very
| limited. If we had gone for MP3 (or even a reasonably complex
| tracker module), we'd hardly have had any CPU left for the
| visuals.
|
| QOA would have likely been the perfect alternative! We'd have
| better sound quality with no downsides, I think.
| ant6n wrote:
| GBA has a 16MHz 32-Bit Arm. The Game Boy original had a 4Mhz
| 8-bit cpu (but it really only ran at 1Mhz, since all
| instructions took a multiple of 4 clock cycles).
|
| But yes, not quite fast enough for mp3.
| srott2 wrote:
| Quite OK article :)
|
| A few years ago, a guy made his own video compression format, but
| I can't find it anymore, is it still available online?
| gkbrk wrote:
| Are you looking for this series of articles? The author makes
| his own video codec for a video chat app, and has a lot of test
| videos of faces.
|
| https://bengarney.com/2016/06/25/video-conference-part-1-the...
| lifthrasiir wrote:
| Are you looking for this? https://blog.tempus-ex.com/hello-
| video-codec/
| srott2 wrote:
| I think the style is similar, but it was more complex. He was
| also showing off the codec on his face, probably this is a
| newer version.
|
| Anyway, I'm grateful.
| metadaemon wrote:
| I remember this post, so probably right.
| hcs wrote:
| > Most GameCube games used their own 8-bit ADPCM format
|
| Minor quibble but, at least for music, most GC games used a
| native 4-bit ADPCM ("DSP", decoded by the DSP, or the ADP/DTK
| format, like CD-XA ADPCM and also handled in hardware), and the
| most common cross-console audio middleware (CRI) also generally
| used 4-bit ADX ADPCM. In this old list, everything marked ADP,
| ADX, DSP is using 4-bit (and others are usually just different
| containers for DSP):
| http://web.archive.org/web/20080420105759/https://hcs64.com/...
|
| PS1 and PS2 were similar. I've usually only encountered 8-bit
| DPCM on PC, though the 3DO had a version in hardware.
|
| The old table-driven style of ADPCM might be the poor quality the
| author has in mind, all of these consoles get much better quality
| at 4 bits, using the same kind of linear predictor (usually with
| 2 samples of history) with scales per frame as QOA.
|
| Edit: I hadn't read carefully enough, QOA is doing something more
| complicated by updating the weights rather than using a fixed set
| of filters chosen per frame (ADX has only one per sample rate, GC
| DSP uses 8, XA/PS uses 4 or 5). That seems a little
| overcomplicated, but maybe needed at 3 bits per sample?
| Jasper_ wrote:
| Yeah, I don't understand the disparaging of 4-bit ADPCM as
| being terrible quality when this is effectively a 3-bit ADPCM.
| Most ADPCM codecs I've seen shipped have a similar table based
| system with a frame header with coefficients for your two
| history samples rather than the weight update scheme here, and
| it works quite well.
| hcs wrote:
| This bit
|
| > What makes QOA work is 1) a reasonably good predictor and
| 2) storing the scalefactor for a bunch of samples explicitly
| instead of guessing the right one from context, like ADPCM
| does.
|
| suggests a comparison with DVI/IMA ADPCM [1] or derivatives,
| which go out of their way not to have too much state or use
| multiplies, and they also tend to be used at really low
| bitrates, so they have a somewhat deserved bad reputation.
| "Guessing" the scalefactor is overstating it, the scale does
| dynamically adjust but that's all considered from the
| encoder.
|
| The 2-history-samples style ADPCMs in the BRR [2] family
| usually have very short frames (at most dozens of samples)
| and headers specifying scale and predictor/filter index.
|
| I know a lot more about what's used on consoles than about
| the math of audio encoding, though, so I can't say whether
| QOA is making the wrong tradeoffs.
|
| [1] https://wiki.multimedia.cx/index.php/IMA_ADPCM [2]
| https://en.wikipedia.org/wiki/Bit_Rate_Reduction
| phoboslab wrote:
| Traditional ADPCM is not terrible, it's just "meh". Compare:
|
| - Original, 4039kb: https://phoboslab.org/files/qoa-
| samples/adpcm_comp/orig.wav
|
| - MS ADPCM, 1022kb: https://phoboslab.org/files/qoa-
| samples/adpcm_comp/ms_adpcm....
|
| - QOA, 812kb: https://phoboslab.org/files/qoa-
| samples/adpcm_comp/qoa.wav
|
| IMA ADPCM is in the same ballpark as MS ADPCM. ADX (not
| listed) comes close to QOA, but at 1136kb is also larger than
| those traditional ADPCM flavors.
| stephc_int13 wrote:
| I have a fairly decent audio system with a good dac and
| reasonable headphone.
|
| MS ADPCM sounds horrible, a lot of unpleasant high-pitched
| noise. QOA is much better but still audibly degraded from
| the source.
|
| Not sure I would ship content at this quality.
| sprash wrote:
| IMA ADPCM sounds consistently better to me than MS ADPCM.
| It has probably better tuned parameters. This shows that
| block based adjustable translation tables could vastly
| improve ADPCM quality at the cost of somewhat more encoding
| complexity while retaining the same decoding complexity.
| Maybe worth a look.
| ogurechny wrote:
| Nice, but if 24_tuba_arpegio_melodious_phrase_stereo on the
| samples page is not a conversion error, it might explain why at
| least basic psychoacoustic model and/or post-processing filter
| are expected. That static beat is noticeable precisely because of
| its repetition.
| phoboslab wrote:
| Good catch! That's likely an artifact of the LMS state being
| quantized[1] at every frame border. I will look for ways to
| improve this.
|
| [1]
| https://github.com/phoboslab/qoa/blob/master/qoa.h#L324-L336
| PaulHoule wrote:
| Lately I have been collecting MiniDisc hardware, one of those
| things that progresses from "I'll buy a deck from Japan" to
| seeing a deck at the thrift store and taking it home right away.
|
| The ATRAC codec used in Minidisc is similar in bitrate to the QOA
| although it is transform-based. I had a music technology prof ask
| me "How do you stand listening to something compressed?" I also
| have a monster CD changer
|
| https://www.crutchfield.com/S-sTSOm8D5jfj/p_158CDPX355/Sony-...
|
| which I am filling up with 5.1 DTS disks that play on my home
| theater. I told my son that I find it hard to listen to 2-channel
| minidiscs next to really good 5.1 recordings with good bass
| management, but this weekend I did some heads-up listening
| testing between 2-channel CDs and minidiscs I made from the CDs
| and I could not tell the difference on my stereo. I am somewhat
| picky, I think "128 kbps MP3 suck" and can prove it. More careful
| A/B testing through headphones might reveal more weaknesses in
| ATRAC and any codec has some files that will stress it, but I am
| impressed with the quality of ATRAC and also with the low
| complexity. I have a portable player that plays for hours that
| runs off a single AA battery, mechanical parts and all.
| mouse_ wrote:
| I was reading that article, and geez, as a non-programmer I have
| to ask, why does libflac look like such a nightmare compared to
| flacloader? It's like night and day. Is this a "WireGuard makes
| OpenVPN look quite silly" moment?
|
| https://github.com/xiph/flac/tree/master/src/libFLAC
|
| https://github.com/SerenityOS/serenity/blob/master/Userland/...
| lifthrasiir wrote:
| Because a shorter code is not necessarily performant, readable,
| or correct. Also the Serenity version delegates most
| dependencies like bit readers to its built-in library, while
| libflac implements all of them by itself.
| stephc_int13 wrote:
| This is more frequent than you think.
|
| It does not mean that the code is bad or inefficient, but the
| style and architecture is not the simplest to read.
|
| Pretty much in the same way that published scientific papers
| are quite unpleasant to read.
| jefftk wrote:
| It's not clear to me why Opus doesn't meet their needs. They
| write it off for not being simple, but is the problem that it's
| too slow for their application? Are they doing something where
| they need a very small compiled size [1]? Aesthetically prefer
| things that are simpler?
|
| [1] I ship an Opus encoder and decoder to the browser to support
| https://www.jefftk.com/p/bucket-brigade-singing and it's just
| 310KB for compression and 470KB for decompression, which are
| small enough that I don't even minify them.
| nyanpasu64 wrote:
| * * *
| mattdesl wrote:
| I'm interested this for JS. Most codecs are either patent-heavy
| or hugely complex (requiring hundreds of kilobytes of
| WebAssembly), and a lot of the native APIs builtin to browsers
| have a tendency to shift every few years. It would be nice to
| have a pure JS alternative to WAV that provides some file
| reduction.
| jefftk wrote:
| _> the native APIs builtin to browsers have a tendency to
| shift every few years_
|
| The web platform is incredibly backwards compatible; I'm
| having trouble thinking of any cases where they've dropped a
| format (which doesn't mean there aren't any!)
|
| On the other hand, while the browsers generally ship with
| many codecs [1] the APIs for interacting with them are pretty
| terrible.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/Media/Formats/A...
| Turing_Machine wrote:
| > I'm having trouble thinking of any cases where they've
| dropped a format
|
| Flash?
| jefftk wrote:
| Flash was a plugin, not a "native API built into
| browsers".
| adgjlsfhk1 wrote:
| One fairly significant advantage is seek-ability. I can see it
| being really useful for a game to just dump all of their audio
| into a single file and specify which clip with just a start and
| end frame.
| creshal wrote:
| That is indeed commonly done in games. Egosoft's X series had
| (has?) just one massive 8+ hour, 128kbps MP3 file with all
| voice clips in the game, and just seeks to the needed
| position.
|
| The games also used DirectAudio or some other horrible mess
| that relied on registering codecs to the OS, so one of the
| most common tech support complaints was that the game didn't
| play any voices (regular SFX were uncompressed WAV), because
| the user only used media players that bypassed Windows'
| central codec registry.
|
| Re-encoding everything to WMA (guaranteed to be a registered
| codec) was suggested several times to management, but since
| they all used Windows Media Player with properly registered
| codecs, they never really got the severity of the problem,
| and didn't care that the fix would cost them nothing (the
| community had already done all the re-encoding work). I
| imagine it got changed later, when the games were ported to
| other OSes, but I had left by that point. (And my NDA expired
| a long time ago, too.)
|
| So, yes, something like QOA that you can just drop into any
| C(++) codebase, as games tend to be, without licensing
| problems or run-time overhead, would have been really, really
| useful 20 years ago. The file size differences might have
| been a headache in the CD games era, but by the time DVDs
| became standard it wouldn't have been a problem.
| super256 wrote:
| This looks interesting! Do you have a link to the source code
| of the opus encoder and decoder? The code in the github repo
| (html/opusjs/decoder.js) looks generated and is hard to
| understand.
| jefftk wrote:
| Pretty sure it was https://github.com/Rillke/opusenc.js
|
| (Normally this would be in the commit description but it
| looks like we forgot to include that
| https://github.com/jeffkaufman/bucket-
| brigade/commit/d96b6f3...)
| phoboslab wrote:
| Curiosity mostly. As stated in the article, Opus is excellent
| and better than QOA in every way except in complexity (and as a
| result, performance). A possible application for QOA is games,
| where you need to play dozens of audio files immediately.
|
| I haven't done any formal benchmarks, but with a simple `time`
| on the command line QOA encodes 10x faster and decodes 7x
| faster than Opus.
|
| QOA should be quite suitable for SIMD optimizations, which
| would improve performance even more. Still on my todo list.
| jll29 wrote:
| Aesthetically, intellectually and scientifically (Occam's
| razor), a simpler method is a better method, because one shows
| to have understood the essence of the problem or natural
| phenomenon that has been modelled.
|
| From a software point of view, more complex methods are also
| more prone to implementation error. Dominic's post is not
| opposed to Opus or the other formats, but argues (to me,
| convincingly) there is a valid spot on the map of audio formats
| for very simple format that still has more decent audio quality
| than other very simple formats. The result has compact file
| sizes, rapid decode times and still sounds well.
|
| EDIT: The post is a good educational read (as any good software
| developer IMHO should aspire to creating simple code),
| initially and/or eventually. His other posts (e.g. the one on
| his Pagenode CMS) also show this simplicity-seeking mind set.
| peterbmarks wrote:
| I'd like to see a comparison with codec2
| https://www.rowetel.com/wordpress/?page_id=452
___________________________________________________________________
(page generated 2023-02-02 23:01 UTC)