similar to: Retuning compression levels

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)

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

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

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)

Currently apodization function is hardcoded, see commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=4e8fe85bceb245dfce07d1956b144e1cb6587c9f> FLAC is locale-dependent so "tukey(0.5)" doesn't work for locales with decimal comma. But "tukey(5e-1)" should be locale-independent so it is possible to re-add 'const char *apodization' member into

> 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

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

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

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

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

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

> 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

On Mon, Sep 22, 2014 at 06:39:43PM +1000, mle+la at mega-nerd.com wrote: > Martijn van Beurden wrote: > > > I dropped -e because > > it's compression improvement isn't worth the slowdown, but it is > > easy for the user to add this anyway. > > I think we should keep -e but may print a warning. The reason to keep it > is so that we do not break some

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

As I haven't heard any complaints concerning the proposal for retuning compression levels which I posted a few months ago, here's the patch that enables them, with the change proposed by lvqcl. 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

Hi all, The compression levels in FLAC have been kept the same for a long time, only preset 6, 7 and 8 got a slight change years ago. However, as some parts of FLAC got much faster, I felt it was time to retune the presets, to better use the now much faster parts. There is a proposal at github here: https://github.com/xiph/flac/pull/576 I think there might be strong opinions on this matter.

Op 02-02-16 om 16:54 schreef lvqcl: > BTW, 64-bit flac can benefit from 64-bit words in > bitreader/bitwriter routines. Currently it requires > --enable-64-bit-words switch in ./configure parameters. It > would be interesting to test its effect, especially on ARM. Okay, I might test that as well. I've checked performance with the brand new laptop my employer gave me, which is

Hi Martijn, I don?t know if it?s just my Firefox or whether something breaks during the parsing of the email but none of your links seem to work for me. I feel it might have something to do with the spaces in the file names of the PDFs, which doesn?t translate well to URLs. Thanks, Lennard > On 3 Feb 2016, at 18:04, Martijn van Beurden <mvanb1 at gmail.com> wrote: > > Op