similar to: [PATCH 2] remove unnecessary code

The test is rather simple, and only compares the computed output values for a 1kHz signal at the known filter table sampling frequencies with previously obained golden values. As such, the test only verifies that the performance of the replay gain analyser has not changed. A better test would be to compare the computed value with an independently obtain theorectical value. This is possible by

Move FLAC__STRCASECMP to share/compat.h and remove it from src/flac/main.c and src/share/grabbag/cuesheet.c -------------- next part -------------- A non-text attachment was scrubbed... Name: strcasecmp.patch Type: application/octet-stream Size: 1596 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140310/f2bd3db3/attachment.obj

This commit will break OS/2's EMX 0.9d library (GCC 2.8.1) which has been been replaced by klibc. Considering the age of EMX and lack of testing and that klibc contains so many improvements I think this is exceptable. --- include/FLAC/ordinals.h | 17 +++++++++-------- src/flac/main.c | 2 +- src/libFLAC/metadata_iterators.c | 2 +-

test_metaflac.sh wasn't aborting when replaygain values were incorrect because the die() function was embedded in a pipe. set -x was added so the script exits with a non-zero exit code when die is called in a pipe. --- test/test_metaflac.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/test/test_metaflac.sh b/test/test_metaflac.sh index 9a13291..2ea2251 100755 ---

Martijn van Beurden wrote: > Yes, indeed. I removed the 17-bits part because I just matched > the code in evaluate_lpc_subframe_ with the process_subframe_ > code. It appears it only makes sense that those two pieces code > are the same. A bit of history: 1) The conditional "if(subframe_bps <= 16)" was added to evaluate_lpc_subframe_() in the commit

Erik de Castro Lopo wrote: > lvqcl, > > Would you be able to have alook at this one? I think its > Windows related: > > https://sourceforge.net/p/flac/feature-requests/114/ > The relevant changes are <http://git.xiph.org/?p=flac.git;a=commitdiff;h=6a6207b52a86b1d7980a5233e297c0fc948bed7d> and

On 12/10/2015 5:58 PM, lvqcl wrote: > Erik de Castro Lopo wrote: >> lvqcl, >> >> Would you be able to have alook at this one? I think its >> Windows related: >> >> https://sourceforge.net/p/flac/feature-requests/114/ >> > > The relevant changes are >

On Thu, 19 Jun 2014 05:00:39 +0400 lvqcl <lvqcl.mail at gmail.com> wrote: >Erik de Castro Lopo wrote: > >> It sees that the most serious bug in the flac bug tracker: >> >> https://sourceforge.net/p/flac/bugs/413/ >> >> has been fixed in git. This fix alone is worth a new release so its >> time to work towards one. >> >> Things I need

The patch <https://git.xiph.org/?p=flac.git;a=commitdiff;h=b3c3e2ac4fcac9d9b178ad240976634d52d5eece> removed Makefile.am files from subdirs of src/share, but for some reasom didn't remove src/share/utf8/Makefile.am. This file is not included into release tarballs, so I think it's indeed unnecessary. It's better to remove it than let it bit-rot. -------------- next part

Fixes are similar to parts of the following commits: <https://git.xiph.org/?p=flac.git;a=commitdiff;h=2199d086921eb37d249cae0731f334556ec6209d#patch7> <https://git.xiph.org/?p=flac.git;a=commitdiff;h=b9574fe58950d38c96399161421484935249822a#patch3> -------------- next part -------------- A non-text attachment was scrubbed... Name: flacdiff.patch Type: application/octet-stream Size: 569

There are preprocessor definitions in bitreader.c and bitwriter.c: /* Things should be fastest when this matches the machine word size */ /* WATCHOUT: if you change this you must also change the following #defines down to SWAP_BE_WORD_TO_HOST below to match */ /* WATCHOUT: there are a few places where the code will not work unless uint32_t is >= 32 bits wide */ #define

The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=0a0a10f358345f749e4a05021301461994f1ffc5 (from 31 Mar 2007) adds the following conditional: if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) And the commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=f081524c19eeafd08f4db6ee5d52a9634c60f475 has this: if(FLAC__bitmath_ilog2(default_partition_samples) +

About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense

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

Anybody knows the reason for the following code (you can see it in flac/decode.c, flac/encode.c, libFLAC/fixed.c and libFLAC/stream_decoder.c) ? #if defined _MSC_VER || defined __MINGW32__ /* with MSVC you have to spoon feed it the casting */ residual_bits_per_sample[0] = (FLAC__float)((total_error_0 > 0) ? log(M_LN2 * (FLAC__double)(FLAC__int64)total_error_0 /

lvqcl wrote: > 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: why libFLAC compares > 'order' and 8 in C code and not in asm. ...more about PPC ASM:

More specifically, about this patch: http://git.xiph.org/?p=flac.git;a=commitdiff;h=70b078cfd5f9d4b0692c33f018cac3c652b14f90 I downloaded the latest code from git (flac-70b078c), disabled all SSE optimizations in the code and compiled it (GCC 4.8.2). This patch doesn't change FLAC output. Either gcc is too smart and optimizes this new code back to the old, or this fix is MSVS-specific. Or

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

The patch http://git.xiph.org/?p=flac.git;a=commitdiff;h=0bea5fb96436588b4e78c5be79bf174b9be7a202 changes the type of t value from FLAC__int32 to uint32_t, but only for 24-bit signed input samples. 24-bit *un*signed input still uses FLAC__int32 t. So I wonder - does it makes sense to change this type too? The patch is attached. -------------- next part -------------- A non-text attachment was

src/libFLAC/memory.c cannot be compiled with MSVS 2005 (and probably VS2008 too) after this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=7cbecbae9f70be770f7651d09531fec0de6f9cf5 because MSVS2005 doesn't provide stdint.h. According to MSDN, uintptr_t is defined in "STDDEF.H and other include files".