Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Let's see:

- Wavpack [1], which is a rough contemporary but offers three tiers of presets (normal scale, high scale, extra high scale) and an innovative (and optional) lossy/hybrid mode

- TAK [2] which compressed better and decoded faster than either, but was initially closed-source until the dev was persuaded to open it up

- LossyWAV [3] which isn't lossless but chops off least-significant-bits while using noise shaping to pre-process audio and make it compress better when fed to a lossless compressor

Most of these developments were first publicized on Hydrogenaudio. But as for innovations in the last two years, not that I'm aware.

[1] http://wiki.hydrogenaud.io/index.php?title=WavPack [2] http://wiki.hydrogenaud.io/index.php?title=TAK [3] http://wiki.hydrogenaud.io/index.php?title=LossyWAV

EDIT (for some more background): generally in lossless audio compression you want to use linear prediction to predict an approximate signal for the next few samples, then encode the difference between your predicted guess and the actual signal in some entropy coder, like Golomb-Rice codes or Huffman or Arithmetic coding. Although most of Zstandard's improvements are algorithmic or implementation-related and not related to data theory, the part that could show promise is the tANS entropy coder [4] used in Zstandard; but Golomb-Rice codes perform well for data that comes from linear predictors; so I'm not sure what to expect [5].

[4] https://github.com/Cyan4973/FiniteStateEntropy

[5] 'Benchmarks' section under [4]



Golomb-Rice with base M is prefix code optimal for approximately geometric probability distribution Pr(x) ~ sqrt(2)^(-Mx). Arithmetic coding or FSE/tANS would allow to use the actual probability distribution. The question is how large the gain could be - how far from Shannon is Golomb-Rice for this specific type of data? If this probability distribution varies, maybe it's worth thinking about adaptive rANS, like in Oodle LZNA and BitKnit: https://fgiesen.wordpress.com/2015/12/21/rans-in-practice/ ps. Is M fixed or adapting?


Sadly my enthusiasm for compression greatly exceeds my math knowledge.

The linked resources from the RAD Game Tools people are really interesting; they've been pushing the state-of-the-art for many years but mostly avoid the limelight.

I found one paper [1] that muses about switching from CABAC to Golomb-Rice in video compression, and by doing so they reduce decoding complexity while achieving comparable compression efficiency. So I'm not sure if it'd be worth going the other way, and whether adaptive codes are a good fit (for LPC residuals).

[1] http://iphome.hhi.de/wiegand/assets/pdfs/2011_09_ICIP_entrop...

But I almost want to cook up some interactive 'build-your-own lossless codec' testbench where you could pick your transform, pick your linear predictor, and pick your entropy coder, and tinker until you're satisfied with the result.


Would lossless and/or lossy compression algorithms perform better if each element of an audio track was compressed and stored separately (similar to the MP4-based STEM audio format [1], but without any limitations on the maximum number of elements and the stereo master which increases the file size)? The constituent parts of the track would then be merged together during playback by the audio player.

[1] http://www.stems-music.com/stems-faq/


We had these a long time ago; 'module files' made with music trackers [1]. And yes, they compress very well.

Unfortunately, the transformations that make up 'mastering' can be pretty elaborate, and for professionally-produced music there is little incentive to let the general public see their project files -- although they are occasionally made available for remixers.

[1] https://en.wikipedia.org/wiki/Module_file


There is also ALAC (Apple Lossless Audio Codec), which has been open source and royalty-free since 2011:

https://en.wikipedia.org/wiki/Apple_Lossless


In all fairness ALAC is very similar to FLAC in its inner workings, but differs in arbitrary, minor ways that result in more complexity over FLAC (and of course, incompatibility) for little gain.

I'm paraphrasing from a post from the FLAC developer himself [1], after someone released an ALAC decoder created through reverse-engineering the format, back in 2005.

[1] https://hydrogenaud.io/index.php/topic,32111.msg279843.html#...


Judging a codec by a reverse-engineered implementation may be very misleading. For example, the original codec may have been written to satisfy a different set of goals, e.g. optimised for energy consumption on a particular ARM CPU.


Doesn't WavPack predate FLAC? Anecdotally, I first came into contact with Shorten (.shn), then a couple of years later, Monkey's Audio (.ape) and WavPack at around the same time, and that was a couple of years before I even heard of FLAC.


WavPack pre-dates FLAC by two years, but it reached popularity after FLAC did. There were many codecs that came out right around 2000; Monkey's Audio, LA, OptimFROG; they all compressed really well but were expensive to encode and/or decode. This was a huge drawback with the hardware at the time.

FLAC achieved some popularity early on because it was cheap to encode and decode, and produced acceptable compression ratios. But its mindshare shot up in 2003 when Xiph.Org announced FLAC was joining their banner of codecs as their preferred lossless offering.

Mainstream interest in FLAC resulted in WMA Lossless and ALAC; that's what people were using. But in enthusiast circles, WavPack became an alternative competitor to FLAC, because it had better compression in high (but not normal), it was also open-source (which was rare in those days), and its dev was a participant in compression enthusiast communities.

After the FLAC/Wavpack duopoly, TTA was a good effort from a Russian team but it fizzled because it had no compelling differentiator against codecs with better share. The next big news was TAK, albeit the dev was relentlessly pressured to open-source.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: