similar to: 1.3.2 News announcement

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,

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

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

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

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

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

> 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

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

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

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.

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

Erik de Castro Lopo wrote: > MauritsVB wrote: > > > 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. > > I changed the link to point to: > > http://downloads.xiph.org/releases/flac/ >

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

> On 1 Jan 2017, at 07:54, lvqcl.mail <lvqcl.mail at gmail.com> wrote: > > 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

Hi, Back in 2003 the developer of JSch, a Java SSH2 implementation, posted a thread regarding support for sending signals to remote processes here: http://marc.info/?l=openssh-unix-dev&m=104295745607575&w=2 The thread culminated in a patch provided by Markus Friedl, which Atsuhiko Yamanaka tested and reported as working (unofficially), which added support for this capability in the

On 23 Nov 2014, at 15:06, MauritsVB <mauritsvb at xs4all.nl> wrote: > > On 23 Nov 2014, at 14:49, Martijn van Beurden <mvanb1 at gmail.com> wrote: > >> Considering Windows binaries: in case no new binaries are provided, please at least remove the old ones from sourceforge. As can be gleaned from some bug reports, support requests etc. on sourceforge, people are still

I can confirm git head builds and passes /make fullcheck/ (skipping the noise part of test_streams.sh) on - armv6-linux (Raspbian), GCC 4.6 & GCC 4.8 - i686-pc-mingw32, GCC 4.8.1 - MSVC 2005 Express 32-bit (make fullcheck with MinGW) - MSVC 2013 Express 32-bit (make fullcheck with MinGW) Furthermore, I've also ran the test_streams.sh of FLAC 1.2.1 with FLAC 1.2.1 as encoder and git as

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

I see someone has noticed my lack of suggestions or recommendations for placement of virtual host source files... Since there are many places to put virtual host source files, I had intentionally avoided the discussion due to the complexities and to keep the document restricted to a single topic. I had planned to create a separate document devoted to the discussion. Specifically, there

I think I've hit the same problem that Predrag reported in http://comments.gmane.org/gmane.comp.emulators.libvirt.user/8825. With libvirt-1.3.2-1.fc23.x86_64 on Fedora 23, when I try uploading an image with vol-upload to a user libvirtd (qemu:///session): virsh vol-upload --pool default volume.qcow /path/to/file.qcow2 I am getting: error: Disconnected from qemu:///session due to