On Sun, Nov 23, 2014 at 02:44:00AM -0800, Erik de Castro Lopo wrote:
lvqcl wrote:
I have a couple of questions:
1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any
pre-releases?
I had not planned to do a pre-release.
FWIW, considering how much code has changed
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
lvqcl wrote:
So I think that flac-1.3.1-win.zip should contain:
* doc/html/ folder with documentation
* win32/ folder with 32-bit flac.exe and metaflac.exe
* win64/ folder with 64-bit flac.exe and metaflac.exe
* AUTHORS, COPYING.* and README files in the root.
Thanks, that is what I will
On 24 Nov 2014, at 10:13, Erik de Castro Lopo mle...@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
MauritsVB wrote:
Looking good, clearly a couple of things I’d forgotten all about! Two things:
1) Shouldn’t we give Martijn van Beurden a mention for his great work on the
bartlett, bartlett_hann and triangle functions” and New apodization
functions
partial_tukey and punchout_tukey” code?
I agree with Miroslav. It is a good practice to make a security release on a
branch of the stable, shipped code, so that people can obtain the security
fix with minimal risk to other changes. Even if the new code passes all tests
fairly soon, it wouldn't hurt to have a couple of releases - one
Miroslav Lichvar wrote:
FWIW, considering how much code has changed since 1.3.0,
I don't think very much has changed. The biggest changes are Martin's
new apodization window changes.
I'd rather
see the security bug fixed in a new 1.3.0 release,
Err, no, rolling a new release with the same
Brian Willoughby wrote:
I agree with Miroslav. It is a good practice to make a security release
on a branch of the stable, shipped code, so that people can obtain the
security fix with minimal risk to other changes. Even if the new code
passes all tests fairly soon, it wouldn't hurt to have a
On Sun, Nov 23, 2014 at 03:19:53PM +, maurit...@xs4all.nl 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
Declan Kelly wrote:
Is anyone from the Rockbox project on this list?
If the CVE issue affects playback (on architectures that can run
Rockbox) then a new Rockbox release should have the new FLAC code.
IIRC Rockbox uses ffmpeg decoder.
___
flac-dev
On Tue, Nov 25, 2014 at 12:44:10AM +0300, lvqcl.m...@gmail.com wrote:
Is anyone from the Rockbox project on this list?
IIRC Rockbox uses ffmpeg decoder.
It does!
http://www.rockbox.org/wiki/SoundCodecs
--
-Dec.
---
(no microsoft products were used to create this message)
Mosaic is
Declan Kelly wrote:
IIRC Rockbox uses ffmpeg decoder.
It does!
http://www.rockbox.org/wiki/SoundCodecs
Thanks for the link.
OTOH, Seeking is implemented using routines adapted from libFLAC,
so who knows.
___
flac-dev mailing list
flac-dev@xiph.org
12 matches
Mail list logo
