similar to: [PATCH] apodization for struct CompressionLevels

Hi all, This patch adds two new apodization functions that I developed. From my own test results (on quite a diverse dataset) they outperform the current best apodizations by 0.05% - 0.1% (depending on the specifics) on compression. Here's a selection of the test results *Apodization functions* ,Compres, Speed partial_tukey(2) tukey(0.5) , 56.50 , 37.2x partial_tukey(3)

On 24 Nov 2014, at 10:13, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > MauritsVB wrote: > >> As we?re talking 1.3.1 release, I?ve been keeping track of a couple of >> changes that I feel should be included in the changelog and that I might >> as well share here. The things between brackets are just to refresh >> memories, I?d leave them out of the

As we?re talking 1.3.1 release, I?ve been keeping track of a couple of changes that I feel should be included in the changelog and that I might as well share here. The things between brackets are just to refresh memories, I?d leave them out of the actual changelog. * Improved efficiency of 24 bit decoding. (https://git.xiph.org/?p=flac.git;a=commit;h=ea0d5ddadc6902e873983c89f473130b3bb6625f) *

Hi all, With the patch I mailed earlier today, I found out a few adjustments could be made to the compression level settings.This retuning speeds up the encoding and improves compression, while not changing anything decoding-wise. Currently, compression settings are as follows -5, -l 8 -b 4096 -m -r 5 -A tukey(0.5) -6, -l 8 -b 4096 -m -r 6-A tukey(0.5) -7, -l 8 -b 4096 -m -e -r 6-A

Martijn van Beurden wrote: > This patch changes the settings associated with compression > levels 6, 7 and 8. With this patch, -e is no longer used, but > instead apodization functions are added. This should improve > compression with at least 95% of all material. Independent tests > show that this is probably the case. But your patch changes only two last presets (-7 and -8) so

Martijn van Beurden wrote: Hi Marijn, Sorry for the lack of response on this. I didn't understand it when it came in and I needed time to properly review it. Sunday morning after a really good night's sleep seems like a good time for that :-). I've currently got this patch in an un-published branch. > This patch adds two new apodization functions that I developed. > From my

--- doc/html/documentation_tools_flac.html | 6 ++--- include/FLAC/stream_encoder.h | 42 +++++++++++++++++----------------- src/flac/main.c | 20 ++++++++-------- 3 files changed, 34 insertions(+), 34 deletions(-) diff --git a/doc/html/documentation_tools_flac.html b/doc/html/documentation_tools_flac.html index 9f85a25..0964cd2 100644 ---

Op 22-09-14 om 21:56 schreef Erik de Castro Lopo: > Wouldn't "tukey(1/2)" be better? > > Erik 5e-1 is directly parsed by strtod, while 1/2 isn't AFAIK.

On 22.9.2014 23:22, lvqcl wrote: > Martijn van Beurden wrote: > >>> Wouldn't "tukey(1/2)" be better? >>> >>> Erik >> 5e-1 is directly parsed by strtod, while 1/2 isn't AFAIK. > Another idea is to write flac_strtod() (and probably local_strtod() too) > function that is able to parse both "0.5" and "0,5" strings

Erik de Castro Lopo wrote: >> Currently, compression settings are as follows >> >> -6, -l 8 -b 4096 -m -r 6-A tukey(0.5) >> -7, -l 8 -b 4096 -m -e -r 6-A tukey(0.5) >> -8, -l 12 -b 4096 -m -e -r 6-A tukey(0.5) >> >> I suggest the following, in case my previous patch is accepted >> >> -6, -l 8 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2)

Hi, I was doing some speed and compression comparisons with various apodization/windowing functions, and found out that the definitions for the bartlett and bartlett_hann window in the FLAC codebase have been wrong since their introduction. The attached patch fixes that. Furthermore, I found some peculiar behaviour of the gauss apodization that seems to expose bug. Using different windows

Hi Guys, Does having multiple apodization functions change something to the decoding process or does it only apply to the encoding process ? I have been able to gain almost 10% by using several apodization functions (it takes way more time to encode but this is quite a non issue in my use case) but I don't want to sacrifice any decoding speed as this is the bottleneck for me. Thanks,

Martijn van Beurden wrote: >> And I also suggested to consider a different setting for -7 preset: >> -7 == -l 12 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2) >> see <http://www.hydrogenaud.io/forums/index.php?s=&showtopic=106545&view=findpost&p=871797> >> >> But it will decrease decoding speed for this preset. > > Yes, that is another thing

Op 20-10-14 om 16:36 schreef Martijn van Beurden: > Op 20-10-14 om 16:31 schreef lvqcl: >> But your patch changes only two last presets (-7 and -8) so >> -6 stays unchanged. ( IIRC it should have >> "tukey(5e-1);partial_tukey(2)" as its apodization string >> instead of current "tukey(5e-1)" ). > > .... okay, I really don't know how it is

Hi, > If I understand this correctly, these new apodization functions only > affect compression and that files compressed with these new functions > will still decode correctly with older versions of the FLAC decoder. > > Is that right? Yes, that is correct. These functions are used to window the audiodata, but only for the predictor stage. What these new function enable,

Martijn van Beurden wrote: > With the patch I mailed earlier today, I found out a few > adjustments could be made to the compression level settings.This > retuning speeds up the encoding and improves compression, while > not changing anything decoding-wise. > > Currently, compression settings are as follows > > -5, -l 8 -b 4096 -m -r 5 -A tukey(0.5) > -6, -l 8 -b

Martijn van Beurden wrote: > Hi, > > I was doing some speed and compression comparisons with various > apodization/windowing functions, and found out that the > definitions for the bartlett and bartlett_hann window in the > FLAC codebase have been wrong since their introduction. The > attached patch fixes that. How it affects compression ratio? > Furthermore, I found

Hi, Apparently the new presets are triggering an invalid free in some code. I was running the test suite on ARM, and it gets stuck with small blocksizes. > Testing blocksize variations... > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 0 --lax > --blocksize=16 ): encode...decode...compare...OK > noise8m32 (--channels=1 --bps=8 -8 -p -e -l 1 --lax > --blocksize=16 ): encode...***

Martijn van Beurden wrote: > Hi, > > > If I understand this correctly, these new apodization functions only > > affect compression and that files compressed with these new functions > > will still decode correctly with older versions of the FLAC decoder. > > > > Is that right? > > Yes, that is correct. These functions are used to window the >

Op 13-11-14 om 17:45 schreef lvqcl: > FLAC__window_partial_tukey(): > > Np = (FLAC__int32)(p / 2.0f * N) - 1; > > and Np can be equal to -1. So later in the code > > for (; n < (end_n-Np); n++) > window[n] = 1.0f; > > libFLAC writes outside of window[] memory. That does the trick indeed. I still wonder how it is possible that this didn't trigger anything