similar to: FLAC 1.1.4 released

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

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

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

On Thursday 04 October 2007 04:27:47 you wrote: > Sir, you need to provide more information. What kind of errors? What > is not working? What exactly are you trying to do? What compiler are > you using? H IV0, we are using a lot of different cross-compiler (mainly based on GCC 3.4.x) When I tried to cross-compile FLAC for non-i386 platforms (such as ARM), I use use

On Tue, Jun 11, 2002 at 12:07:38AM -0700, Josh Coalson wrote: > I have just released a source distribution which is the > candidate for the 1.0.3 release. At this time I would > ask anyone who is willing to help test it to do the > following: > > 1. download the tarball and unzip it: > http://prdownloads.sourceforge.net/flac/flac-1.0.3_beta-src.tar.gz?download > > 2.

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

Eric, I finally got around to your patches after Miroslav's. the first one (the memcpy/memset replacement) I had problems with, one because the buffers can overlap so I had to use memmove (is this usually assembly in libc too?) and also the endpoints looked wrong, for my full patch see below. speedup for me was around 3% the second patch got another 2%. a question though, why do you have: +

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

On Sun, Jun 24, 2001 at 02:30:56PM -0700, Josh Coalson wrote: > There have been reports of -9 using huge amounts of memory. -9 is really > theoretical, but people always seem to want to try the max setting. Anyway, > that's not an excuse but figuring out why -9 is using so much memory is lower > on my list than other stuff. -8 should get within 0.01% of -9 and is pretty >

hello! Today I tried to compile the new FLAC 0.8 sourcecode on my SuSE Linux 7.1 machine and failed. Below is the output of "make" and "configure". I hope the information is enough that somebody can help me to compile the source. Thanks a lot. PS: A lot of thanks to all developers of FLAC. Its very useful to me!! ------------------------------------------------------ This

thanks for the patch. also, if you have miroslav's patch again a more updated version of bitbuffer.c that would be great. I have been meaning to get around to applying it for a long time. btw how are you playing it on the ipod? not sure how to help out with lpc_restore_signal(). there are x86 and PPC versions of the routines in CVS that might be good references. it is basically a

Josh Coalson <xflac@yahoo.com> wrote: > thanks for the patch. No prob :) > also, if you have miroslav's patch again a more updated version > of bitbuffer.c that would be great. I have been meaning to get > around to applying it for a long time. This is Miroslav's patch, from the mailing list post I dug up in the archives: --- orig/src/libFLAC/bitbuffer.c +++

hy, recording and playback without speex is working perfectly Lp, Tim +--------------------------+ | email: rico at gama.us | | www: http://gama.us | |--------------------------| | tel: 00386 31 457 627 | +--------------------------+ 2009/9/2 Tim Rijavec <rico at gama.us> > hy, > > here is my speex encoder/decoder .. the sampleRate i use is 16000 and >

hy, recording and playback is working perfectly without speex. i have try to set samplerat from 6000 to 441000 and quality from 1 to 10 sam with complexy, but the best i can get is with 16000 samplerate, 5quality and 3complexy .. but still, the voice that came out is annoying, artificial, robot ,... Lp, Tim +--------------------------+ | email: rico at gama.us | | www: http://gama.us

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 >

On Sun, Jul 22, 2001 at 12:28:52AM -0700, Josh Coalson wrote: > 2. Applied Matt's last cleanup patch of 8 files. I did not apply the patch > to src/test_unit/main.c since it looks wrong. main.c is supposed to include > the local bitbuffer.h, not src/libFLAC/private/bitbuffer.h; I think the > current version is correct. Ah, I missed that there was a local bitbuffer.h. In that

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,

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