Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Sac: state-of-the.-art lossless audio compression (Read 31317 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Sac: state-of-the.-art lossless audio compression

Reply #25 –
Quote from: genuine on
Unfortunately, the speed increase in processors is not the same as before. Core speeds do not change much, core numbers increase. And there are minor speed increases from other things. Intel's situation is a serious symptom of this.

Sac already has some multi-core optimizations in stereo-mode and I plan to increase this efforts. Running Sac with small framesizes on a 32-core machine is nearly practical :D

As a side note. It is trivial to increase speed.
Why use a base order of 1280 for the --normal profile? We can use 256 (as in earlier version), that would be a lot faster and only hurts on some files.
Why try to model bits after the MSB in the residual encoding stage? There is nearly to no benefit.
Why update the OLS stage every sample instead of every second or third? Gains are abysmal
Why use pow-function within the OLS stage to model one rate parameter?
LMS-Mixer uses a sub-gradient method using inverse square root for every sample.

The list of impractical design decisions is endless :)


Quote
If speed is not an issue, as in SAC, paq8px is now a better option. It gives better results. It is also an open source study. I think if you support him, a better work can be done.

Paq8px has worse compression on music than Sac (https://github.com/slmdev/sac) and 5 times slower decompression.

I wrote the (first) OLS core for Paq8px :) - but it can never be as good as Sac because of design limitations.

Re: Sac: state-of-the.-art lossless audio compression

Reply #26 –
Quote from: SebastianL on
Quote from: Porcus on
Don't whine over your own scope.

Maybe its a language problem - instead of "useless" maybe describe it as "impractical".

Yes, and point taken. But "utterly useless but for this kind of benchmarking" is not the same as "utterly useless", period - at least not if you want to come across as honest.

Now, let's put that aside. What are we looking for? A phrase for "don't use it for anything but ...", and in a world where we warn end-users that "-8" is not the "best" FLAC compression, but selected to be the slowest useful one.


Quote from: SebastianL on
Quote
It doesn't look very good to quote so far out of context, when that very context is what justifies that Sac is even invoked.

So i state "i have the best lossless audio codec" und you answer with "nah on this weird sample it got beaten by run length encoding"

*sighs* No, and again you should know better than playing the abused.
When oddly good compression results show up from a codec that isn't the heaviest, what then? It might be that it has caught something more than a spurious coincidence, that there is something going on in a non-negligible amount of audio around. Only after turning the pages you will have a chance to tell whether it has a chance to pay off taking it on board in a hypothetical codec improvement that aims at doing everything the others do.
One such phenomenon might very well be the cases referred to above, where long patterns are overwhelmed by rapid variations (and in "real distributed music").
That doesn't mean that FLAC compresses generally better than e.g. TAK, because it doesn't - but it can help explain why it outcompresses TAK on e.g. the Merzbow track: there is a trick FLAC employs, that is as cheap as two bytes per channel
per frame even when it is worthless, which in my test corpus is the case for around half the 4096-sample subframes. But the cost (around 0.05 percent of compressed size I think) does pay off for the vast majority of the music I use for testing - not with Bruckner's motets, but OTOH > 2 percent smaller size on music like John Cage (percussion), Laibach and Kraftwerk. And it has been noted before that it might matter in a way that makes FLAC less sensitive to block size optimization (click spoiler text at https://hydrogenaud.io/index.php/topic,123248.msg1020384.html#msg1020384 ).
That is one of those instances of what I call "engineering craft" - writing the residual encoder in a way that picks up compression for cheap - and it could very well be that it is a phenomenon that those codecs (/developers) with focus on looong range redundancy, might have missed. It isn't about which one is generally the "best" by whatever metric, it is about whether there are still semi-low hanging fruit around.

On the other side of the coin, and not to be taken as ranking Sac vs OptimFROG overall, but I find this track to be an illuminating example: That noise music has - by ear! - texture patterns you would expect to be exploitable for compression. The frog can compress away ten percent ... my gut feeling says more should be possible, then what?
Sac could take another quarter off, " Proving that it is possible". Wasn't that the aim? Proving possibilities? But then, when FLAC also can get quite low ... what more is possible on such music? 

A different example, there are situations where WavPack does exceptional. And there is an explanation: https://hydrogenaud.io/index.php/topic,121770.msg1024715.html#msg1024715
When there is an explanation, there is room to look for improvement (for codecs that don't see compatibility as an issue). This is a signal property that by gut feeling "should not exist in well-mastered music" - but we don't really know how much is around. If some particular DAW software might produce it ... what then? As far as I understand: when we get to those high sampling rates, we do not really know what are "corner cases" and what are not, because the top octave(s) are not made for musical value.


Quote from: SebastianL on
At least provide version numbers when you publish tests. I have no idea what you tested.
You are right about that - at least, if the purpose is more than showing "we know that it is possible because something did it", and even then it doesn't cost much.
0.5.1 off github is most certainly the one I have used in anything from 2022 . Until this thread, where I used the current one.


Quote from: SebastianL on
Although, I don't think it is useful to test compression by benchmarking whole albums.
I would be rather surprised if a codec that is the best on a 1min sample of a particular album, is suddenly far behind on a 30min sample.
Yes, after testing I am leaning to the same - except there are surprises around. For example, one of the albums in my test corpus is essentially mono, except part of it has "mono except channel-independent dither". Oh. Then who knows how much of that is around on CD presses of historical mono recordings?

Re: Sac: state-of-the.-art lossless audio compression

Reply #27 –
Quote from: Porcus on
When oddly good compression results show up from a codec that isn't the heaviest, what then? It might be that it has caught something more than a spurious coincidence, that there is something going on in a non-negligible amount of audio around. Only after turning the pages you will have a chance to tell whether it has a chance to pay off taking it on board in a hypothetical codec improvement that aims at doing everything the others do.
That is one of those instances of what I call "engineering craft" - writing the residual encoder in a way that picks up compression for cheap - and it could very well be that it is a phenomenon that those codecs (/developers) with focus on looong range redundancy, might have missed. It isn't about which one is generally the "best" by whatever metric, it is about whether there are still semi-low hanging fruit around.

Maybe we just have some kind of technical misunderstanding here ;)
I am always interested in strange samples that get me new ideas for possible improvement

It would be amazing if you could provide direct links to the wav-files (e.g. merzbow, pseudo-mono)
E.g. i was surprised that Sac performs quite good on https://content.neuralink.com/compression-challenge/README.html
in comparison to other audio codecs, but

you can save almost everything in wavefiles :)
a simple zip-method on the previous or some of your examples is already twice as good as flac

And that's a general issue with "audio compression" and its history

Using LPC in "some form" originates from the idea that you can model the vocal tract via a finite impulse response filter
That's one reason why it works so good on speech

and also why most of the scientific literature about lossless audio compression uses this small corpus of 16 files (originated from HA)
although I have to admit that the target is harder than you think = it takes a lot of work to shave of 5kb from a 27mb encoded file

Sac is basically MP4ALS on crack - there is no magic involved and the general predictor topology is similar
I just tried A LOT to tune the basic idea - although the end result is simple to unterstand
in contrast to my experimental approaches (e.g. neural networks, wavelet filterbanks, advanced optimization methods)

Your idea to tune the residual coder (for cheap) is great but i am usually looking for generalizable methods
e.g. Sac sparse-pcm model is a generalization of the "wasted bits" feature

The symptom you are describing relies in the fact, that we are not able to model strict repeating patterns
LPC is not designed for that, but LZ (+ optional masking) can help here, although it seems to be difficult to combine LZ+LPC directly
Fun fact: the sources of MP4ALS includes a file with some LZ-code, no idea if it is used at some point

One way to work around this issues is not to encode the source X as a residual E from a prediction Y, E = X - Y
but to model the probability distribution P of the source with the prediction as context P(X|Y), like paq8px does
The optimal way to weight cascaded predictions is still a bit black magic in this context

Until now I did not came up with a good solution for this = better than my approach of residual coding
let alone the fact, that things start to get really costly in terms of compute at this point

Things on my bucket-list
- implement mentioned P(X|Y) modelling
- predictor is used as sparse domain in a compressive sensing framework
 there is a paper on that used in lossless audio, although i am too lazy to implement all that L1-optimization stuff in plain C++
- MLP-Res network as substitute for the LMS-Cascade
  gradient descent doesn't converge fast enough in our setting so it will get ugly
  as i have the code for neural nets already lying around, i am just forcing myself at this point to use it somehow  :>

Cheers



Re: Sac: state-of-the.-art lossless audio compression

Reply #28 –
Quote from: SebastianL on
Sac is basically MP4ALS on crack - there is no magic involved and the general predictor topology is similar
So, the forward-predicting? (TAK also has a lot in common with that.)
There is the -z switch too, but it seems even fewer cared about that one.

I'll send you stuff, when I get to it. This year, but maybe not before that famous birthday.

Re: Sac: state-of-the.-art lossless audio compression

Reply #29 –
Quote from: Porcus on
So, the forward-predicting? (TAK also has a lot in common with that.)
There is the -z switch too, but it seems even fewer cared about that one.

I am usually using the terms "static" vs "adaptive" here

In linear regression you model the input y as y=w*x, where w is the vector of weights
all boils down to the question of how to calculate the weights

"static" calculates w for the whole frame, so decoding is obviously faster but you have to encode w too
there are improvements in MP4ALS and OFR to use high orders up to 2^10 by a sparse approach
otherwise you would waste too much data on irrelevant weights

"adaptive" is used in MP4ALS -z mode, OFR, MAC and Sac
you adapt the weights after each sample to reflect the current input, its slower but gives usually better prediction

all of the above codecs use a low-order predictor followed by high-order filter(s)
it's similar to "gradient boosting" in nn-speak

MP4ALS -z uses DPCM+RLS+LMS
Sac uses OLS+NLMS

OFR also has "aca" and "acm" modes
I suspect something similar to Sac --sparse-model and the other one to be bias correction

Sac uses no m/s-mode or similar pre-processing for stereo-files
all stereo-decorrelation is done within the OLS core,
where on channel can have a flexible lag and use samples from the past+future

Quote
I'll send you stuff, when I get to it. This year, but maybe not before that famous birthday.

Thanks in advance
Merry Christmas

Re: Sac: state-of-the.-art lossless audio compression

Reply #31 –
0.7.13 was released one month ago, and I let it loose on a part of them 38 CDs: Only the first ten and a half minutes of each.
That means there are track transitions in it - but those who choose one "image" files per CD will have such. The signals have been altered a bit, capping the difference left minus right at 16 bits maximum. See comment at the end on why - anyway, these signals are the same for all codecs in the table, it just means that there are less very big amplitudes in a corpus that likely is louder than the average.

Obviously I could not go beyond the "very high" setting in only one month on this CPU  O:)
So, 38 signals, each the same length (meaning, https://jordanrudess.bandcamp.com/album/sunflower in full and the first 10:26.797 of each of the others).
14 classical, 10 heavier (including heavy synth based as Laibach) and 14 "others". Summary compression figures together with some familiar codecs and settings, in order of total size:
codecmaterialtotalclassicalheavier others
flac -552.4642.3369.8150.19
OptimFROG default50.1240.2967.8747.26
Monkey's Extra High49.9739.8267.5247.59
OptimFROG 1048.3737.6366.7245.99
Sac "normal"48.3337.8566.6145.75
OptimFROG "max"48.3237.6066.6845.92
Sac "high"48.0737.4766.4045.58
Sac "very high"48.0037.4066.3545.50
Material matters. It is only classical music that makes OptimFROG touch Sac --normal. Starting by "Sac's best performances":
  • Sac --veryhigh wins 37 of 38 signals, losing out to OptimFROG --preset max at the Jan Johansson clip (three and a half piano jazz tunes)
  • Sac --high ranks #2 (after --veryhigh) at 34 of the 38 signals, and scores at worst fourth among these. it loses only to Sac --normal: Psycroptic and Miles Davis (that's strange, I'll get back to it). The two others are the Mahler symphony and Jan Johansson, two quite different signals. Also OptimFROG --preset 10 beats --high at Jan Johansson.
  • Sac --normal at the heavier corpus: 8 of 10 it beats the frogs. The last two (In The Woods and Laibach) it loses to both frogs. It could be that the capping of the side channel (see the end) happens to fit Sac's algorithm better - but given how Sac can outcompress the frog on noise music, I'm inclined to believe that this kind of dense material is where it can find patterns others cannot.
  • Sac --normal at the "other" bunch: There's one more signal where it doesn't score #3: Sopor Aeternus, beaten by both frogs.
  • Sac --normal at the classical: Frog territory! OptimFROG --preset 10 beats Sac --normal at 12 of 14 signals. The exceptions where Sac --normal beats the frog: John Cage's percussion works; and then it beats --preset 10 but not --preset max at this chorus sampler: https://www.discogs.com/release/4640362-Various-High-Tech-Choruses - again, only the first few minutes, none of the test signals are in there.)
  • Then further down the ranks, Monkey's Extra High beats the default frog as expected, but not at the "other" section. Indeed, for the Miles Davis it is outcompressed by FLAC -5 by nearly four percent.

Some more comments on genre:
  • It is the classical music section where the heavier compressors score. Sac --normal makes ten percent smaller files than flac -5 (that's percent, not percentage points - ranging from 6 percent on the choruses to 22 on the flute). It is also the genre where it makes the biggest gains over OptimFROG's default and Monkey's Extra High, gains up to 12 percent over the frog (harpsichord) and 15 over the ape (harp). Yet, that is the genre where it gets outfrogged.
  • On the opposite end, the funeral doom/dirges of Colosseum ( https://open.spotify.com/album/3Jb62I7kf6d9Hb3Qthpb8V ) - not even a track transition here in  ten and a half minutes do not cover the first song - here Sac --normal beats FLAC/default-frog/ape by only 2.0/0.6/0.7 percent.
  • For the "other" genres, the savings of Sac --normal range from Tori Amos: 4.9/2.1/1.1 percent over FLAC/default-frog/ape, to James Brown: 17/4/11 percent.


A note on the Miles Davis CD. Although we shouldn't read too much out of one signal, this one is near-mono; the channels are independently dithered but otherwise identical.
Sac --normal beats --high at the stereo. But if I isolate the average channel and the difference channel and compress them separately, --high wins as it should.
It isn't so strange that something like this happens on some signal out there, but I wouldn't expect it to be this one.
The low-level noise in the difference channel is also what makes Monkey's lose out on this particular track.


Why alter the signals - and how?
What I really wanted to test, is how the codecs benefit from stereo decorrelation. So I separated out the side channel, the difference left minus right. That could take 17 bits - and on music like Gojira, it very often does - but I capped those to stay within the 16-bit range -32768 to 32767. The reason is I cannot get codecs to process a "17 bit" signal without it being embedded in 24 - and some codecs actually make a big difference.
Anyway, the stereo signals here are merged from this capped side, and the mid. And as goes the oddity on Miles Davis, the side was within 3 bits range or so.
Since it took a month to process the Sac, I thought, why not post the compression results. It just isn't realistic to put that --veryhigh setting through any comprehensive selection.

Re: Sac: state-of-the.-art lossless audio compression

Reply #32 –
It seems to offer an average of 4% or 5% better compression than FLAC -5. However, the computation times are horrendous. So in this case, it means abnormal energy and processing time loss for the sake of a ridiculous return on data savings.
SAC is not something i can test as i am not as patient as Porcus. But SAC is still an good experimental work that can be used as a reference.

Re: Sac: state-of-the.-art lossless audio compression

Reply #33 –
Thanks @Porcus for the extensive tests! I am happy to see Sac at the front :)

Just some notes:
--normal uses a max order of 1280 and is not tweaked in any way (default params), that's one reason why it sometimes looses to OFR on classical
--high is more or less "random sampling", it try's 100 Parameter sets in a ~50 dim problem :> - it also only uses less than 10% of the samples to test the params -> high probability of failure

Sac has extensive stereo modelling - reference channel switching, dynamic lags etc
but you have to use at least "--veryhigh" for it to be successful because it has to test a lot of possibilities

The default cost function is "entropy"
if you use something like "--optimize=0.1,100,bpn" (~2x slower than --high)
or "--optimize=0.2,250,bpn" (30% slower than --veryhigh) the results should be more stable
I think it makes sense to establish a mode between --veryhigh and --best, like --optimize=0.25,300,bpn or similar
even --insane does not show the full potential of Sac

Sac v0.7.13 has issues with adaptive blocking, i advice to use --adapt-block=0 until i fix this
Sac v0.7.15 --high is twice as fast on AVX2 capable cpus :)
Sac v0.7.15 --normal is ~50% slower than MP4ALS

Can you send me the one sample for OFR is better than --veryhigh?

Re: Sac: state-of-the.-art lossless audio compression

Reply #34 –
Does that mean that 0.7.13 just disabled the offending routine from 0.7.12 rather than "getting it back up doing the right thing"? 
Potential speed impact then? If some subsequent version will fix and re-enable a "lots of extra effort" to slow it down, I'm not sure if I'll do another month plus-plus for --veryhigh. --high might be doable for a test, and a couple of oddball signals might get the --veryhigh treatment ... but since you got the Jan Johansson CD by now, I guess you will get --veryhigh ahead of the frog on every known signal, so its value as an "out-of-sample" test is kinda out of the window.
 
@genuine: back-of-envelope calculations say my CPU didn't burn off much more than fifty cents/eurocents/swisscents/pennies of electricity. And it is winter, so the heat wasn't outright wasted.

Re: Sac: state-of-the.-art lossless audio compression

Reply #35 –
Quote from: Porcus on
Does that mean that 0.7.13 just disabled the offending routine from 0.7.12 rather than "getting it back up doing the right thing"? 

no
- Sac has an adaptive framesplitting method, which was invented for exactly one file in my benchmark corpus :)
- The bug you found is fixed! The splitting is cheap.
- it's just not as good as intended and often gives worse results (like the examples you sent me)
- it's still active but i advice to disable it using --adapt-block=0

currently Sac works by "analyse -> split -> predict -> encode" and it has to be changed to "predict -> analyse -> split -> encode" to avoid false positives

Quote
Potential speed impact then? If some subsequent version will fix and re-enable a "lots of extra effort" to slow it down, I'm not sure if I'll do another month plus-plus for --veryhigh. --high might be doable for a test, and a couple of oddball signals might get the --veryhigh treatment ... but since you got the Jan Johansson CD by now, I guess you will get --veryhigh ahead of the frog on every known signal, so its value as an "out-of-sample" test is kinda out of the window.

Speed is an issue. I personally never tested samples longer than 1-2min. You're brave to encode a whole album
Next release will have the following features
- 24-bit support (working already in master, but i have to fix --sparse-pcm first)
- 30-50% faster --normal, more than 2 times faster --high using AVX2 (already done)
- encode multiple frames at once
- fix --adapt-block as depicted above

Re: Sac: state-of-the.-art lossless audio compression

Reply #36 –
The album "Jan Johansson: "Folkvisor" is an interesting case.
The sparse-pcm model goes full force here saving 30-50kb per 20s frame - I thought such files do not exist in the wild.
I know OFR has some better modelling methods if the pcm spectrum has certain characteristics, which Sac can not model by design limitations. Optimization is not the key for better performance here.

Re: Sac: state-of-the.-art lossless audio compression

Reply #37 –
From the release it says that it was through analog and digital restoration. It is a compilation of two albums, so if it is the same for the last part as the first, then a pretty good bet is that it happened in that process.
Not to knock the two gentlemen who did so, but earlier on they had mainly seen studios as musicians. It's Johansson's son Anders (by then best known from Yngwie Malmsteen's Rising Big Ego Force) and a bandmate of his. So they might have been self-taught with whatever digital tools were availabe to them in 1994.

Look at the file folder, I uploaded a different mastering of the second album there. It is apparently more recent and less compressible.

Re: Sac: state-of-the.-art lossless audio compression

Reply #38 –
Quote from: Porcus on
From the release it says that it was through analog and digital restoration. It is a compilation of two albums, so if it is the same for the last part as the first, then a pretty good bet is that it happened in that process.
Not to knock the two gentlemen who did so, but earlier on they had mainly seen studios as musicians. It's Johansson's son Anders (by then best known from Yngwie Malmsteen's Rising Big Ego Force) and a bandmate of his. So they might have been self-taught with whatever digital tools were availabe to them in 1994.

Look at the file folder, I uploaded a different mastering of the second album there. It is apparently more recent and less compressible.

Thanks - the file is interesting, i did some more benches and even --adapt-block is useful here - maybe it just needs some tuning

Code: [Select]
--adapt-block=1 --sparse-pcm=auto --framelen=5
222.930.721
--adapt-block=0 --sparse-pcm=auto
222.654.784
--adapt-block=0 --sparse-pcm=force
222.636.923
--adapt-block=1 --sparse-pcm=auto --framelen=10
222.030.102
--adapt-block=1 --sparse-pcm=auto --framelen=20
221.747.925
--adapt-block=1 --sparse-pcm=auto --framelen=30
221.676.664
OFR --preset max 
219.757.973
 

Re: Sac: state-of-the.-art lossless audio compression

Reply #39 –
I published a new release
https://github.com/slmdev/sac/releases/tag/v0.7.18

Highlights
30-100% faster encoding using AVX2
better compression

use multi-threading when optimizing, e.g.

sac --high --opt-cfg=dds,4 input.wav output.sac
uses --high profile but 4 times faster dds

sac --verbose --optimize=0.05,2000 --opt-cfg=de,20 input.wav output.sac
uses 5% of the frame-samples, 2000 steps, optimization method differential evolution with 20 threads and verbose output