Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Quite OK Audio Format for Fast, Lossy Compression

qoaformat.org

Post reply on HN
Print view View original

61–65 of 65 posts

Re: The Quite OK Audio Format for Fast, Lossy Compression

#61

Post by speedgoose »

IshKebab wrote: post #59
speedgoose wrote: post #51

Earlier quoted context omitted.

From my understanding you can patent things supported by software, but not the software itself. A physical digital music player with a fancy software audio compression is patentable, but not the algorithm on its own.

No you can definitely patent software. It seems to be a confusing mess as to exactly how you do it and what is patentable, but you can. https://www.novagraaf.com/en/insights/patentability-software... > As a result, the widespread belief in the non-patentability of software is simply a misconception, partly as a result of insufficient training of innovators and the lobbying activities of certain interested parties. ht…

Yes I find the EPO to be a bit shady by accepting software patents, and the fees, when the patents aren’t enforceable by law. I’m not a lawyer but I known how to read and I would ignore the patents trolls and I consider the risk to lose in court very low. The day something like the VideoLan association loses a trial, I may reconsider my position.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#62

Post by mips_r4300i »

Comparing against 4bit ADPCM, which is already able to give quite good performance as long as your sample rates are relatively modern, this only improves it to 3.2 bits. It is fast, but ADPCM is also fast.

Would be nice to see joint stereo support. If you were to take ADPCM or this OK format and try to encode any stereo music with it, you will need 2 channels. However, there is an extremely advantageous optimization that can be made here - most music is largely center panned, so both channels are almost the same. With joint stereo you record one channel (either by picking one or mixing to an average) and then you can store the difference for the other channel which will occupy a lot fewer bits, assuming you are able to quantize away the increased entropy.

For example, instead of using two 4bit ADPCM channels for stereo, which would only be a 50% savings over uncompressed, you could probably use an average of 5 bits per sample.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#63

Post by anotherhue »

mips_r4300i wrote: post #62

Comparing against 4bit ADPCM, which is already able to give quite good performance as long as your sample rates are relatively modern, this only improves it to 3.2 bits. It is fast, but ADPCM is also fast. Would be nice to see joint stereo support. If you were to take ADPCM or this OK format and try to encode any stereo music with it, you will need 2 channels. However, there is an extremely advantageous optimization…

> Would be nice to see joint stereo support

This was/is available in MP3 since forever, so seems a reasonable request.

https://wiki.hydrogenaud.io/index.php?title=Intensity_stereo

Re: The Quite OK Audio Format for Fast, Lossy Compression

#64

Post by gaazoh »

I like the philosophy of QOA (and other similar projects, including QOI and TinyVG), but unlike others, it seems like it's not ready to use yet, see https://github.com/phoboslab/qoa/issues/25

> I have just pushed a workaround to master. [...]

> This still introduces audible artifacts when the weights reset. It prevents the LMS from exploding, but is far from perfect :/

This, combined with the fact that that issue is still open mean that a breaking change is still to be expected.

Re: The Quite OK Audio Format for Fast, Lossy Compression

#65

Post by crumpled »

kenferry wrote: post #37
crumpled wrote: post #34

Earlier quoted context omitted.

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

Cairo’s a couple layers down from what you’re talking about. It’s the actual glyph rendering.

Yeah. It's just a clue indicating they didn't use a word processor.
Post reply on HN