search for: partial_tukey

..., -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 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 -5, -l 8 -b 4096 -m -r 5 -A tukey(0.5) -6, -l 8 -b 4096 -m -r 6-A tukey(0.5);partial_tukey(2) -7, -l 8 -b 4096 -m -r 6-A tukey(0.5);partial_tukey(2);punchout_tukey(3) -8, -l 12 -b 4096 -m -r 6-A tukey(0.5);partial_tukey(2);punchout_tukey(3) See this graph for comparison: http://www.audiograaf.nl/misc_stuff/setting-visualisation.pdf This data was acquired with a reasonably large data...

...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) , 56.51 , 37.0x tukey(0.75) gauss(0.2) tukey(0.25), 56.54 , 35.8x partial_tukey(2) , 56.55 , 50.5x tukey(0.25) gauss(0.2) , 56.57 , 49.6x tukey(0.5) , 56.69 , 79.3x Speed is in...

...lows >> >> -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) >> -7, -l 8 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2);punchout_tukey(3) >> -8, -l 12 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2);punchout_tukey(3) >> > This all sounds great! And I also suggested to consider a different setting for -7 preset: -7 == -l 12 -b 4096 -m...

...> 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) , 56.51 , 37.0x > tukey(0.75) gauss(0.2) tukey(0.25), 56.54 , 35.8x > partial_tukey(2) , 56.55 , 50.5x > tukey(0.25) gauss(0.2) , 56.57 , 49.6x > tukey(0.5) , 56...

..., <span class="argument">--compression-level-6</span> </td> <td> - Synonymous with <span class="argument">-l 8 -b 4096 -m -r 6</span> + Synonymous with <span class="argument">-l 8 -b 4096 -m -r 6 -A tukey(0.5);partial_tukey(2)</span> </td> </tr> <tr> @@ -807,7 +807,7 @@ <span class="argument">-7</span>, <span class="argument">--compression-level-7</span> </td> <td> - Synonymous with <span class="arg...

...; -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 > > -5, -l 8 -b 4096 -m -r 5 -A tukey(0.5) > -6, -l 8 -b 4096 -m -r 6-A tukey(0.5);partial_tukey(2) > -7, -l 8 -b 4096 -m -r 6-A > tukey(0.5);partial_tukey(2);punchout_tukey(3) > -8, -l 12 -b 4096 -m -r 6-A > tukey(0.5);partial_tukey(2);punchout_tukey(3) > > See this graph for comparison: > > http://www.audiograaf.nl/misc_stuff/setting-visualisation.pdf > > T...

...> 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 -6 stays unchanged. ( IIRC it should have "tukey(5e-1);partial_tukey(2)" as its apodization string instead of current "tukey(5e-1)" ).

...th decimal comma. But "tukey(5e-1)" should be locale-independent so it is possible to re-add 'const char *apodization' member into CompressionLevels struct. The patch is attached. This will allow to easily change preset settings from "tukey(5e-1)" to "tukey(5e-1);partial_tukey(2);punchout_tukey(3)" or something like this. -------------- next part -------------- A non-text attachment was scrubbed... Name: apodization.patch Type: application/octet-stream Size: 2457 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140922/69feda2a/a...

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 to consider. My proposal keeps the > decoding speed for all preset...

...missed? > > Cheers, > Erik > -- > Looking good, clearly a couple of things I?d forgotten all about! Two things: 1) Shouldn?t we give Martijn van Beurden a mention for his great work on the "bartlett, bartlett_hann and triangle functions? and "New apodization functions partial_tukey and punchout_tukey? code? 2) There is a typo under ?Build system?: "buiuld systems? Maurits

...t.xiph.org/?p=flac.git;a=commit;h=ea0d5ddadc6902e873983c89f473130b3bb6625f) * Faster encoding using SSE and AVX. (many separate patches by lvqcl) * Fixed bartlett, bartlett_hann and triangle functions. (http://lists.xiph.org/pipermail/flac-dev/2014-August/004983.html) * New apodization functions partial_tukey and punchout_tukey for improved compression. (http://lists.xiph.org/pipermail/flac-dev/2014-August/005000.html) * Retuned compression presets to incorporate new apodization functions. (http://lists.xiph.org/pipermail/flac-dev/2014-August/005001.html) Obviously a lot more changes have landed that...

> 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 to consider. My proposal keeps the decoding speed for all presets the same, but I don'...

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 possible I missed > that. Sorry. Here's the patch again. Sadly, it turns out this patch requires another patch to fix the test_compression.sh t...

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...***

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...

> I don't know, its your build system and I haven't seen it, nor do > I have the time and motivation to look at it (unless of course you > were paying me for my time). I willing give my time to maintain > FLAC. I have not signed up to spend my time on your project. And I am willing to looking at FLAC and spent my time to fix compiler warnings to make it more portable and