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: brute-force encoding (Read 5537 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

brute-force encoding

I was wondering, with processing power ever increasing, while it seems audio encoders have plateaued for a while now, is anyone doing or considered doing brute-force encoding? What I mean is the encoder simply tries every encoding permutation for a particular chunk/frame/etc and picks the smallest one, then moves to the next segment and repeats this process.

brute-force encoding

Reply #1 –
But it is a question whether you like to listen to that - small is not a problem but it is a matter of a decent quality.

-Chris

brute-force encoding

Reply #2 –
Quote from: hellokeith on
I was wondering, with processing power ever increasing, while it seems audio encoders have plateaued for a while now, is anyone doing or considered doing brute-force encoding? What I mean is the encoder simply tries every encoding permutation for a particular chunk/frame/etc and picks the smallest one, then moves to the next segment and repeats this process.



Well any encoder worth its salt will have quite a bit of history in terms of filterbank overlap, or predictors, noise shapers, etc.

Stopping one set and starting another will entail a great big pile of bits that you didn't want to spend.

I'm not saying something like this can't work at all,it does in mini-form in MPEG-2 AAC, with the codebook structure and the sectioning algorithm, but that's still inside the filterbank and quantizers.
-----
J. D. (jj) Johnston

brute-force encoding

Reply #3 –
Ok let's assume we're talking about lossless, and the current set/chunk/frame has no carry-over from the previous.  What is the max time the encoder need to go through every lossless compression permutation to find the smallest one?

brute-force encoding

Reply #4 –
My bet is that the resulting compression will not be significantly better than if we just used the one codec that provides better average compression rate.
CUETools 2.1.6

brute-force encoding

Reply #5 –
Quote from: hellokeith on
Ok let's assume we're talking about lossless, and the current set/chunk/frame has no carry-over from the previous.  What is the max time the encoder need to go through every lossless compression permutation to find the smallest one?

I am sure it would exceed the expected lifetime of your PC...

Let's for example try any possible combination of predictor values in TAK 1.1.2.  A predictor has 14 bits. That's 2^14 = 16384 possible values. For 12 predictors you have 2^(12 * 14) = 2^168 variations. And TAK 1.1.2 is using up to 160 predictors...

But no need to worry. From my experience i wouldn't expect a brute force approach to gain more than about 0.15 percent on average. Ok, for particular files it can be significantly more.

brute-force encoding

Reply #6 –
If you have a good auditory model, then you might throw N random bits into a file, decode it using a reference decoder, then compare the "perseptual degradation".

Do this for as many iterations as you can afford to, then keep the best candidate.

Challenges:
1. Perfect auditory models does not exist, and current encoders already (?) use the smartest models that the developers can think of and make room for.
2. The number of possible permutations of a 3 MB file is quite large. You need a really fast reference decoder/psy model in order to check all of them out - most are going to be really bad

Now, some kind of partial brute-force search might be to only search within the legal spec, and to only perturb from one or two known "good" starting-points. If the search algorithm "understands" the spec, then it might be possible to search in the "direction" of best quality, searching for some kind of maximum (be it local or global).

brute-force encoding

Reply #7 –
Quote from: TBeck on
Let's for example try any possible combination of predictor values in TAK 1.1.2.  A predictor has 14 bits.

I'm curious. Is that fixed or just an upper bound for your file format? Is it only fixed in the encoder as "a good choice" or do you use different precisions depending on the expected residual?

Quote from: TBeck on
And TAK 1.1.2 is using up to 160 predictors...

What does this mean? Linear prediction up to the 160th order?

As for the noiseless coding part in AAC you don't have to test every combination of code books. I believe you can pick the optimal combination with the Viterbi algorithm. It's basically a path finding algorithm for trellis graphs. I'm not sure 100% but I think it is applicable.

Cheers,
SG

brute-force encoding

Reply #8 –
Quote from: Gregory S. Chudov on
My bet is that the resulting compression will not be significantly better than if we just used the one codec that provides better average compression rate.

Agreed. I think nobody does it because the speed-to-compression ratio will be much much worse. Maybe it's feasible for certain low-complexity parts of the encoding process, though.

Chris
If I don't reply to your reply, it means I agree with you.

brute-force encoding

Reply #9 –
Quote from: SebastianG on
Quote from: TBeck on
Let's for example try any possible combination of predictor values in TAK 1.1.2.  A predictor has 14 bits.

I'm curious. Is that fixed or just an upper bound for your file format? Is it only fixed in the encoder as "a good choice" or do you use different precisions depending on the expected residual?

In TAK 1.1.2 it's the upper bound of the file format. The fractional part of the coefficients can be reduced by up to 7 bits. The resolution is fixed for the faster presets and is beeing optimized for the higher presets and evaluation levels. Furthermore the resolution will always be reduced, if the absolute sum of all coefficients could theoretically cause an overflow in the accumulator of the filter.

Quote from: SebastianG on
Quote from: TBeck on
And TAK 1.1.2 is using up to 160 predictors...

What does this mean? Linear prediction up to the 160th order?

Exactly. Up to version 1.0.4 the strongest preset was using 256 predictors, then i reduced it to 160. TAK 2.0 may use up to 320 predictors, but here it's getting quite insane efficiencywise.

brute-force encoding

Reply #10 –
Quote from: hellokeith on
I was wondering, with processing power ever increasing, while it seems audio encoders have plateaued for a while now, is anyone doing or considered doing brute-force encoding?

Partially reason could be that developers decided to spend their limited time to increase efficiency (speed vs quality) of encoders because each time there are more people who decided to buy moderate cost (not that fast) notebook or netbook instead of high performance desktop.