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: Order of apodization functions (Read 548 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Order of apodization functions

Documentation says about apodization functions:
Quote
When more than one function is specified, then for every subframe the encoder will try each of them separately and choose the window that results in the smallest compressed subframe.
So, from manual it is not clear at all if order of functions does matter or not. But it does matter.
For example
Code: [Select]
flac.exe -l 12 -b 4096 -m -r 6 -A tukey(0,5);partial_tukey(2);punchout_tukey(3) input.wav -o output.flac
input.wav: wrote 178263 bytes, ratio=0,306
and
Code: [Select]
flac.exe -l 12 -b 4096 -m -r 6 -A partial_tukey(2);punchout_tukey(3);tukey(0,5) input.wav -o output.flac
output.wav: wrote 175430 bytes, ratio=0,305
result in different compression despite the same apodization functions are used, just order is different. FLAC version is 1.3.3, wav file - https://www.dropbox.com/s/q4p1fmaqewxltdg/2_5357505388570740373.wav?dl=1

So, how this actually works? Is documentation not clear or this is bug?

Re: Order of apodization functions

Reply #1
BTW: your system uses comma as a decimal separator, so you should use it too: "tukey(0,5)", not "tukey(0.5)"

 

Re: Order of apodization functions

Reply #2
OK, changed dot to comma, edited my post. Anyway compression is not exactly the same.

Re: Order of apodization functions

Reply #3
I was intrigued by this post and tried to replicate. I found that indeed the order matters. However, in my tests, the difference was much smaller than in yours. I have a (untested) hypothesis that this is because of the way FLAC decides which frames to use.

FLAC calculates a pretty accurate guesstimate of which apodization will result in the smallest framesize, but it doesn't calculate the exact size the frame will be during the evaluation stage. If the guesstimates of the sizes of two different attempts are exactly the same, the frame that was evaluated first is taken. While the guesstimates are the same, this doesn't necessarily result in the exact same framesize. This framesize is only calculated as the selected frame is actually output by the FLAC process.

The chance that two guesstimates are the same is fairly small, and if it happens, usually the frame size difference is pretty small too. In my case, usually about 2-5 parts per million. However, in your case, this 1,6% difference is somehow 'lucky', or something else is at work here.
Music: sounds arranged such that they construct feelings.

 
SimplePortal 1.0.0 RC1 © 2008-2021