similar to: No subject

On Dec 3, 2014, at 8:30 AM, Martijn van Beurden <mvanb1 at gmail.com> wrote: > Op 03-12-14 om 16:48 schreef Olivier Tristan: >> 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.

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

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

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

Op 03-12-14 om 18:14 schreef Brian Willoughby: > I would like to point out that 'quiet' material is common when making original recordings. This is probably a misunderstanding: I said that the material that suffers is usually quiet, not that all quiet material suffers. > I do a great deal of live recording, and the levels are always quiet in order to guard against clipping. These

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)

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 >

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

On Nov 12, 2009, at 16:32, Fernando Alberto Marengo Rodriguez wrote: > I' m studying FLAC performance, and I'd like to know how much > compression can be achieved for different audio files. > > 1) It seems that for nontonal sound (wideband noise), the > compression factor is better than for compound sound (tones + > nontonal components), which is typically 2. 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 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,

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

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

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

Op 03-12-14 om 16:48 schreef Olivier Tristan: > Looks like I've missed the talk about this regression introduced in 1.3.1.

FLAC 1.1.4 is released; the Sourceforge shell server is down so I can't update the web page, but downloads are here: http://sourceforge.net/project/showfiles.php?group_id=13478 The windows installer for 1.1.4 is not ready yet but should be along soon. If needed you can replace the binaries from the current (1.1.3) installer with the ones in the 1.1.4 .zip on sourceforge. The main

Begin forwarded message: Date: Sat, 26 Sep 2015 13:46:13 -0700 From: John La Grou <jl at jps.net> To: Erik de Castro Lopo <erikd at mega-nerd.com> Subject: 32 bit data Erik, could you please post this to the FLAC mailing list. I've tried a couple times, but nothing happens. Tks. ......................... There are reasons to support 32-bit data. The emerging network standard

Lots of comments throughout this one... On Jan 7, 2011, at 15:28, Declan Kelly wrote: > On Fri, Jan 07, 2011 at 02:22:51PM -0800, brianw at sounds.wa.com wrote: >> However, you should be aware that many modern producers use software >> to create their music, and when the software stores sound clips in >> MP3 format, what you end up with is music that sometimes looks like