similar to: FLAC 1.3.1 changelog?

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

I am working on creating a set of FLAC files for a ?decoder compliance test corpus? and am looking for examples of things that are part of the standard but not supported in the reference decoder. I am not looking for things missing from the reference encoder (such as variable block sizes). I seem to recall someone on this list (most likely lvqcl or Martijn van Beurden) mentioning something about

On 12/6/16, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > MauritsVB wrote: > >> I noticed you’ve started compiling the changelog for 1.3.2. > > I had sort of hoped I'd finished :). Seems I was wrong! > >> I have kept track of some of the bigger changes since 1.3.1 although >> admittedly haven’t been on top of it this year. Perhaps some of 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)

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 actual changelog. Thanks Maurits, that was very useful. I added a few other things I found in the git commit log

> MauritsVB wrote: > >> Ars Technica reports of ?abandoned projects? on SourceForge being taken >> over by SourceForge with adware installers added to executables. >> >> This might be something to be wary of with FLAC considering the main focus >> for FLAC has moved from SourceForge to Xiph.org. Perhaps consider to remove >> the downloads from

In this topic on Hydrogen Audio(http://www.hydrogenaud.io/forums/index.php?showtopic=105586) someone asked a question about the sample rates that FLAC supports for ReplayGain. The outcome was that the current documentation of MetaFLAC is outdated since Commit http://git.xiph.org/?p=flac.git;a=commit;h=0554a4aee6966bc5b251364753ef85de72dfab19 because as of 1.3.0 FLAC supports Replaygain with many

Ars Technica reports of ?abandoned projects? on SourceForge being taken over by SourceForge with adware installers added to executables. arstechnica.com/information-technology/2015/05/sourceforge-grabs-gimp-for-windows-account-wraps-installer-in-bundle-pushing-adware/ This might be something to be wary of with FLAC considering the main focus for FLAC has moved from SourceForge to Xiph.org.

Hi Erik, I noticed you’ve started compiling the changelog for 1.3.2. I have kept track of some of the bigger changes since 1.3.1 although admittedly haven’t been on top of it this year. Perhaps some of these older ones are useful to consider including: Fixed a segmentation fault in libFLAC http://sourceforge.net/p/flac/bugs/425/ Changed the LPC order guess for a slight compression improvement,

I'd definately recommend binaries for download as suggested by lvqcl and Janne Hyv?rinen. All the fabolous work on the code base is of little use to me if I can not find binaries at the official site. Olav Sunde At 12:01 23.11.2014, Janne Hyv?rinen wrote: >On 23.11.2014 12:44, Erik de Castro Lopo wrote: >> lvqcl wrote: >>> 2) Do you plan to release any official binaries

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

Erik de Castro Lopo wrote: > I also notice that on sourceforge: > > https://sourceforge.net/projects/flac/files/flac-win/ > > there are still 1000+ downloads per week 1.2.1 windows binaries > with know security holes. What do people think of the idea of > disabling downloads of old, known buggy Windows binary downlaods? FLAC 1.2.1 is the last version that works on

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

Nice work on getting flac 1.3.1 out! Is there an ETA for any non-Windows binaries in the pipeline? The page https://www.xiph.org/flac/download.html still points to the 1.2.1 downloads on Sourceforge and could use updating to the new binaries. However, if for instance the OS X binary is just around the corner it would makes sense to wait for that. Will the 1.3.1 binaries also be uploaded to the

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

On 28 May 2015, at 12:27, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > MauritsVB wrote: > >> The response from SF suggests that it?s non-responsiveness from the >> original project owner. Hopefully it?s limited to that. > > Well for flac, thats Josh who has been non-responsive since 2009 > or so. > > Erik I meant who is registered as project

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

If I recall correctly, with the release of 1.3.1 there were a few days between the version being released and the News and Changelog appearing on the site. This caused a number of sites to report the release without mentioning all the improvements in the update. Can I suggest that this time we publish the Changelog and News update immediately after uploading the final version? The Changelog is

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)

> Post the exact command and the error message. [root at Test1 ocfs2-1.3.9]# ./configure checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu ... [root at Test1 ocfs2-1.3.9]# make .... make[2]: Leaving directory `/usr/src/kernels/2.6.18-92.1.6.el5-x86_64' make[1]: Leaving directory `/config/ocfs2-1.3.9/fs' make -C vendor make[1]: