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: Improved FLAC encoder (Read 65430 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Improved FLAC encoder

Reply #75 –
Quote from: Synthetic Soul on
Adding a window or two will benefit all users more than just a few kilobytes though, which is great news.  However, tweaking default windows will be of little benefit comparatively.


Yes, that makes a lot of sense. Maybe it's best to just have a -9 encoding preset with whatever turns out to be the best overall combination of windows for all types of music. I do agree with Josh though, that the -A switch should be left out altogether in that case, as it will just confuse people. And then when casual users do find out that it exists, they'll get all confused and will end up on this forum asking what is going on.

I really can't wait to hear from Josh again...

edit: oops too  late

Improved FLAC encoder

Reply #76 –
you guys are reading my mind... I really don't want to slow down -0 .. -8 so these will probably be 1 -A.  I might add a -9 that does 2 -A's.

for the 1-window presets I plan on picking from among the top windows one with the least variation to avoid having genre-specific ones.  I also thought replaygain would be a good hint as to which to use but it's too complicated to implement.  I thought of inferring the window from any -T 'genre=XXX' tag passed but that also seems like too much of a pain.  from one pass over all the data, it looks like I can find a window that is within 0.02% of the best and with <0.1% variation over the aggregated results here.

Josh

Improved FLAC encoder

Reply #77 –
-9 sounds like a good idea.

Quote from: jcoalson on
I thought of inferring the window from any -T 'genre=XXX' tag passed but that also seems like too much of a pain.
I almost suggested this following Cartman_Sr's suggestion of presets.  I thought it may be too much hassle though.

Quote from: jcoalson on
from one pass over all the data, it looks like I can find a window that is within 0.02% of the best and with <0.1% variation over the aggregated results here.
That sounds really promising. 
I'm on a horse.

Improved FLAC encoder

Reply #78 –
ok, after poring over all the results, here are the general things I noticed:

best overall: tukey(0.5)    (explained below)
best for classical -5: tukey(0.125)
best for non-classical -5: hamming
best second window for extra compression: flattop or gauss(0.125)

the overall result was a little hard to come by, especially at -5 where the audio characteristics seems to matter more.  tukey(0.5) is within a fraction of a percent from the best window for all samples I could see in all of these results and also has a low variation across genres.  but if you know in advance the kind of music you're encoding, you can probably squeeze out a teensy bit extra with the alternate.

Josh

Improved FLAC encoder

Reply #79 –
Quote
...tukey(0.5) is within a fraction of a percent from the best window for all samples I could see in all of these results and also has a low variation across genres. but if you know in advance the kind of music you're encoding, you can probably squeeze out a teensy bit extra with the alternate.


Yeah. I don't know if you're soliciting opinions, but I would say to just leave out the -A switch in the next version altogether. For the marginal compression increase, it won't be worth all the extra support that people will need (I mean people like me, who don't know what they're talking about, but try to make it sound like they do anyway...  ). Having the overall improvement in compression due to the new window functions will be good, I'm sure.

Improved FLAC encoder

Reply #80 –
I agree -9 option is the best. Let's not overcomplicate things.

Triza
 

Improved FLAC encoder

Reply #81 –
Hm, i may be a bit too late...

But possibly i can contribute something useful.

Some of you may know, that my Yalac compressor uses windowing too. And it needed some tuning in the past to make it work well. Now i came back to this issue and examined, which theoretical benefit is possible for yalac if i try an exhaustive variation of my window parameters. Result: Only about 0.05 percent! Far less than in your evaluations of FLAC.

How can this be?

Not really a surprise for me. Yalac looks for variations of the signal characteristics within a frame. If they change, the frame is beeing divided into two or more subframes for which individual predictors are beeing calculated.

To my knowledge the current implementation of FLAC always uses a fixed frame size (although varying frame sizes are supported). If so, then one frame often will contain parts with different signal characteristics, which better should be predicted seperately. But this does not happen.

This is my hypothese, why windowing helps FLAC that much: It surpresses the contribution of of one or two (potential) subframes  at the frame borders to the predictor calculation and hence improves the quality of the (potential) subframe within the center. At least this one now gets "cleaner" (not polluted by the other subframes) or better adapted predictor coefficients and overall the compression increases.

I would not be surprised, if the most important difference between the various window types is the amount of samples at the borders, that are beeing attenuated. I would predict, that files with fast changes of the signal characteristics would benefit more from window types, which attenuate more border samples.

If i am right, what is it worth?

Possibility A: Instead of trying various window types use the triangle window and vary the rise (gradient, slope?) and hence the count of affected samples at the borders. And look what happens, if you apply the window to only one border.

Possibility B: Try to split the frame into 2 subframes or better, use a 100 ms frame and try all possible variations for 1 to 3 subframes. This should not take longer than the exhaustive evaluation of various window types but possibly would help far more! Well, i don't know if the various current FLAC decoder implementations are able to handle varying frame sizes.

I know, my explaination is lousy (my english is to bad), but possibly it is of some use.

Improved FLAC encoder

Reply #82 –
Quote
Possibility A: Instead of trying various window types use the triangle window and vary the rise (gradient, slope?) and hence the count of affected samples at the borders. And look what happens, if you apply the window to only one border.

Possibility B: Try to split the frame into 2 subframes or better, use a 100 ms frame and try all possible variations for 1 to 3 subframes. This should not take longer than the exhaustive evaluation of various window types but possibly would help far more! Well, I don't know if the various current FLAC decoder implementations are able to handle varying frame sizes.


That's actually an interesting idea. I have only heard of window functions being used with lossless encoders once in a Research paper prior to this. 
budding I.T professional

Improved FLAC encoder

Reply #83 –
Quote from: HotshotGG on
Quote
Possibility A: Instead of trying various window types use the triangle window and vary the rise (gradient, slope?) and hence the count of affected samples at the borders. And look what happens, if you apply the window to only one border.


That's actually an interesting idea. I have only heard of window functions being used with lossless encoders once in a Research paper prior to this. 

MPEG4Als has an option to select a window function (although i guess, that the available window types are not too optimal).

But possibly my idea to vary the rise of the triangular window is new. On the other hand it would not be the first time that i did some reinvention...

Improved FLAC encoder

Reply #84 –
Quote
MPEG4Als has an option to select a window function (although i guess, that the available window types are not too optimal).


interesting... I will have to look into that.
budding I.T professional

Improved FLAC encoder

Reply #85 –
Thomas, you may be right.  the reference encoder uses a fixed blocksize mostly because I knew of no practical algorithm for finding the optimal block size.  I think whatever you came up with for Yalac is a real improvement.

Josh

Improved FLAC encoder

Reply #86 –
Quote from: jcoalson on
Thomas, you may be right.  the reference encoder uses a fixed blocksize mostly because I knew of no practical algorithm for finding the optimal block size.  I think whatever you came up with for Yalac is a real improvement.

Just for safety purposes: I did not want to propagate Yalac's methods! I only was looking for a way to improve FLAC without breaking the existing file format.