similar to: PATCH for rice_parameter calculation

Or, I was originally thinking: rice_parameter = 0; k = partition_samples; if (k < mean) { int n = mean - k; rice_parameter += n; k <<= n; } (sorry for the hasty post) On Oct 11, 2013, at 10:34, Brian Willoughby wrote: > Hmm, maybe I'm missing something, but what about this: > > rice_parameter = 0; k = partition_samples; > int n = mean - k; > if (n >

Hi Erik, I've found a middleground for the problem of setting default CFLAGS. I've gone back to setting them if {C,CXX,CPP,LD}FLAGS are unset at the onset of the configure script (i.e., the user hasn't specified anything) and then proceed to set them to the defaults as before. This has been suggested before: https://lists.gnu.org/archive/html/autoconf/2006-04/msg00022.html In

Dear FLAC devs, I would like to get some of our patches merged into master. Most of them deal with adhering to GNU conventions, respectively not overriding flags/variables that are up to the user to set. For instance, honoring $(htmldir) is important, as we have installation paths for the documentation that differ from what is currently coded in the various Makefile.am's. Regards David

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ technically not pessimistic enough, should be more like > if( (FLAC__uint64)order * ((((FLAC__uint64)1)<<bps)-1) * ((1<<subframe->qlp_coeff_precision)-1) < (((FLAC__uint64)-1)

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 19 +------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124 ++++++++++++++++++++++++++++++++++++++++++

* Furthermore, use NDEBUG globally to detect the presence of building with more debug output information. AX_CHECK_ENABLE_DEBUG is easier to use, and nowadays Gnome has also switched to it from its own custom solution. --- configure.ac | 52 ++++++++++++------ include/FLAC/assert.h | 2 +- m4/ax_check_enable_debug.m4 | 124

On Thu, Jun 19, 2014 at 03:30:06PM +0200, Miroslav Lichvar wrote: > But, as we have seen with unusual data the residual signal can be > wider than bps. The FLAC format specification doesn't seem to mention > this. Should it be treated as a valid FLAC stream? I think it would be interesting to know how common are such streams. I patched flac to print a warning on decoding or testing

Recently I was trying some new approaches to improve FLAC compression, when I stumbled on a possible overflow. The reason this has not come up earlier is because the encoder only hits this point when the estimate of the rice_parameter is very much off. To trigger this overflow, one has to force rice_parameter to 0 in for example the function evaluate_lpc_subframe in libFLAC/stream_encoder.c. When

On Thu, 2007-04-05 at 02:27 -0700, Brian Willoughby wrote: > Josh (Green), > > Seems like the longest example in your list is a 15-second file. I > would like to see the same problem exhibited in a file that is of a > normal length. I have been recording full performances lasting > hours, and flac always compresses the files below 70% of the original > size. >

On Thu, Apr 05, 2007 at 06:48:06PM +0200, Josh Green wrote: > It seems that generally Wavpack does a little better than FLAC at > compressing audio. But that is generally within a rather small margin. > 20% margin seems a little large to me though. There may indeed be no > problem with the FLAC reference implementation in regards to 24 bit and > its just having trouble compressing

- INCLUDES is deprecated, and CPPFLAGS is an user-defined variable, use the proper AM_CPPFLAGS instead - Remove FLAC__INLINE definition, providing proper replacement for MSVC compilers. - Detect if we have C99 's lround and provide a replacement for windows... --- configure.ac | 32 ++++++++-------------------- examples/c/decode/file/Makefile.am

----- Forwarded message from Don Armstrong <don@donarmstrong.com> ----- Date: Thu, 30 Sep 2004 16:19:41 -0700 From: Don Armstrong <don@donarmstrong.com> Resent-From: Don Armstrong <don@donarmstrong.com> To: submit@bugs.debian.org Subject: Bug#274301: libflac4 segfaults on corrupt flac files Severity: normal Package: libflac4 Version: 1.1.0-11 Running ogg123 on

Miroslav Lichvar wrote: > I'm trying to figure out how this one works. It seems the problem is > integer underflow in the "frame.header.blocksize-order" expression > used in read_subframe_fixed_() and read_subframe_lpc_() to get the > number of encoded samples, which causes a buffer overflow in the > LPC/fixed subframe decoding. > > The fix prevents that by

lvqcl wrote: > 1) > Current MSVC solution (FLAC.sln and numerous .vcproj files) was made with > VC2005 Express and doesn't allow to build 64-bit files/libraries. > > IMHO it's time to add 64-bit support for MSVC builds, but AFAIK only Visual Studio > 2012/2013 Express are free and allow to build 64-bit files. > > VS 2005/2008 use .vcproj files, and VS

Op ma 6 jul. 2020 om 10:22 schreef Erik de Castro Lopo <mle+la at mega-nerd.com>: > > Martijn van Beurden wrote: > > > To trigger this overflow, one has to force rice_parameter to 0 > > Ok, that sounds dodgy. Yes, well, it is. It could very well be that without patching, nobody ever has a problem with this, but as the rice code is based on an estimate, it might,

On 25.11.2014 12:14, Miroslav Lichvar wrote: > I think the case with non-zero partition order may need to be fixed > too. For example, with partition order of 1, predictor order of 16 and > blocksize of 4, the function would return true and blocksize-order in > the caller would still underflow. > > --- a/src/libFLAC/stream_decoder.c > +++ b/src/libFLAC/stream_decoder.c > @@

Hi all, Google Security Team member, Michele Spagnuolo, recently found two potential problems in the FLAC code base. They are : CVE-2014-9028 : Heap buffer write overflow CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the

Hello, Apologies if this has been done before. I just joined the list as this has bugged me for a while. I can compile FLAC 1.1.2 using Visual C++ 6.0 with no problems. However, when I try to compile the CVS source I get: Linking... utils.obj : error LNK2001: unresolved external symbol _snprintf grabbag_static.lib(stream_decoder.obj) : error LNK2001: unresolved external symbol

To avoid crash caused by an unbound LPC decoding when predictor order is larger than blocksize, the sanity check needs to be moved to the subframe decoding functions. --- src/libFLAC/stream_decoder.c | 30 ++++++++++++------------------ 1 file changed, 12 insertions(+), 18 deletions(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index d13b23b..211b4db 100644 ---