similar to: [PATCH 8] fix for stream_decoder.c

1) changelog.html "Add ability to handle utf8 filenames on Windows (large set of patches from Janne Hyv?rinen)" AFAIK Windows internally uses UTF-16LE, not UTF-8. IMHO it's better to use a general word 'Unicode' instead of 'utf8'. 2) documentation_bugs.html "The following are major known bugs in the current (1.2.1) release:" 1.2.1 is not the current

Fix for padding with --replay-gain option. Ported from flac 1.2.1 maintenance branch: http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/encode.c?r1=1.194&r2=1.194.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/main.c?r1=1.169&r2=1.169.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH -------------- next part

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

I don't understand the comment in src/libFLAC/stream_decoder.c: /*@@@@@@ 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) << 32) ) */ if(bps + subframe->qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) see

On Mon, Apr 20, 2015 at 08:00:20PM +0300, lvqcl wrote: > I don't understand the comment in src/libFLAC/stream_decoder.c: > > /*@@@@@@ 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) << 32) ) > */ > if(bps +

lvqcl wrote: > Fix for padding with --replay-gain option. Ported from flac 1.2.1 > maintenance branch: > > http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/encode.c?r1=1.194&r2=1.194.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH > >

There are 2 comments in stream_decoder.c that mention FLAC__lpc_restore_signal_asm_ia32_mmx() requirement for the output array. The text is updated to include intrinsic functions too. -------------- next part -------------- A non-text attachment was scrubbed... Name: 06_decoder_comment.patch Type: application/octet-stream Size: 1673 bytes Desc: not available URL:

lvqcl wrote: > When I compile flac project with MSYS/MinGW-w64, I can see two files: > libFLAC.a and libFLAC-static.a. The only difference between them > is that libFLAC.a contains functions from win_utf8_io. > But 'make install' adds libFLAC.a into /local/lib, not libFLAC-static.a. Thank you for checking this. I've always had trouble with Autotools on Windows, even when

Hi all, Sorry for bringing this up this short before the release, but I noticed something rather strange. I was doing some more exotic checks on the last pre-release when I tried test_streams.sh with FLAC 1.3.0 encoding and an older version (1.1.0 or something like that) decoding. This failed for 24-bit samples and I wondered why. After quite some tests and hex-editors, I found out this is

hello! Today I tried to compile the new FLAC 0.8 sourcecode on my SuSE Linux 7.1 machine and failed. Below is the output of "make" and "configure". I hope the information is enough that somebody can help me to compile the source. Thanks a lot. PS: A lot of thanks to all developers of FLAC. Its very useful to me!! ------------------------------------------------------ This

In function read_metadata_vorbiscomment_ from stream_decoder.c, at various locations where we short circuit the computation, we also set `obj->num_comments` accordingly. For example: https://git.xiph.org/?p=flac.git;a=blob;f=src/libFLAC/stream_decoder.c;h=e0f1b14d30dd548268a88e4341af3f38290816e3;hb=HEAD#l1736

I have noticed lpc slowdown both in encoding and decoding, not related to new config.h stuff. It seems there is wrong choosing of fastest possible version of lpc function. Patch is attached. -- Miroslav Lichvar -------------- next part -------------- Index: src/libFLAC/stream_decoder.c =================================================================== RCS file:

The underscores are wrong. The comment is also correct. Also remove the configure.ac option. Otherwise it tries to compile the windows unicode stuff which POSIX(cygwin) does not understand. --- configure.ac | 2 +- include/share/compat.h | 2 +- src/libFLAC/stream_decoder.c | 3 --- src/libFLAC/stream_encoder.c | 3 --- src/share/grabbag/file.c | 8 +------- 5 files

thanks for the feedback, but it would really help if you supply a patch (diff -c), I didn't understand all the changes you described. someone reported a problem with src/libFLAC/include/private/lpc.h that was fixed in CVS and may fix the problem building with asm disabled http://cvs.sourceforge.net/viewcvs.py/*checkout*/flac/flac/src/libFLAC/include/private/lpc.h?rev=1.24 Josh --- Luca

This set of patches removes PPC/Altivec code from FLAC. I decided to split the patch into 5 parts to make it more simple: 1) removes FLAC__lpc_restore_signal_asm_ppc_altivec_16* from lpc.h and stream_decoder.c 2) removes PPC-specific code from cpu.c and cpu.h 3) removes PPC stuff from libFLAC/Makefile.lite and build/*.mk 4) removes as/gas/PPC-specific stuff from configure.ac and

Don't use the assembly function since it seems to be slower than the current version of FLAC__bitreader_read_rice_signed_block. --- src/libFLAC/stream_decoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libFLAC/stream_decoder.c b/src/libFLAC/stream_decoder.c index f987c27..37934de 100644 --- a/src/libFLAC/stream_decoder.c +++ b/src/libFLAC/stream_decoder.c @@

> OK, that worked. > > I checked in your patch to make a static libFLAC-asm.a and > I moved @XMMS_LIBS@ to the end of ...LIBADD. Matt and Ben, > can you try the latest CVS to see if it works for you now? It doesn't work for me. Looks like libtool decided not to link libFLAC-asm.a into libFLAC. Here's the output: Making all in src gmake[1]: Entering directory

On Wed, May 23, 2001 at 03:18:16PM -0700, Josh Coalson wrote: > but since I'm not too saavy with autoconf/automake I'll ask for a little bit > more help. I think the only non-functional part left is that automake > doesn't support source files that are in subdirectories, relative to > Makefile.am(?) the layout in src/libFLAC/ is that all asm sources will go > under a

Erik de Castro Lopo wrote: >> There's the following code in stream_decoder.c: > > Like you, I don't see a lot of value in these. I think I'll decline > these. FLAC__lpc_restore_signal_asm_ia32_mmx compares 'order' argument with 4 and if it's greater then it jumps to FLAC__lpc_restore_signal_asm_ia32. I wonder why the same wasn't done for PPC/Altivec:

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