similar to: [PATCH 2/2] V2: Use a single definition of MIN and MAX in sources

I have optimized FLAC__fixed_compute_best_predictor_asm_ia32_mmx_cmov function and fixed bug when data_len == 0. Now the function is about 50% faster and flac -5 is about 5% faster on my box. I have tested it thoroughly, I think it can go to flac 1.0.4. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/ia32/fixed_asm.nasm.orig 2002-01-26 19:05:12.000000000 +0100 +++

On Sat, May 19, 2001 at 06:42:22PM -0400, Matt Zimmerman wrote: > I think this could be fixed by changing the (data_len > 0) test to be > (data_len > 0 && total_error_X > 0). Yes, this appears to have worked. I can now correctly encode and decode both my 8kHz/8-bit/mono sample, and a 44.1kHz/16-bit/stereo sample on Debian/alpha. Attached is a patch which combines this fix

Hi! Thanks for maintaining FLAC! I recently started a project to compile parts of the FLAC reference distribution to JavaScript using emscripten. https://github.com/gagern/emflac#readme I'm using the 1.3.1 release and the Makefile.lite build process. I'm including the FLAC reference implementation as a submodule, and so far I managed to compile everything without modifying its

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

Hi all, I was investigating the behaviour of the -p switch of flac. This switch should enable exhaustive search for the optimal qlp coefficient precision, but the resulting files are usually 0.5% larger then when not using the switch. I stumbled upon this code in stream_encoder > if(encoder->protected_->do_qlp_coeff_prec_search) { > min_qlp_coeff_precision =

When using the -p switch during encoding, the encoder should try different qlp predictor precision steps. However, some faulty code was too severely restricting the possible steps. This patch lifts the restriction to match a restriction coded a little further in the process. This doesn't make using -p worth your while, but at least it doesn't create larger files now ---

Hi all, Anyone know anything about Windows Universal Platform? Someone raised an issue on github: https://github.com/xiph/flac/issues/32 The `flac_max`/`flac_min` issue is resolved, but the WUP one is not. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Matt Zimmerman <mdz@debian.org> wrote: > 0.9. As I said, I was using an 8-bit sample, Ah, that didn't quite register with me. I'm using a CD-style 44.1kHz/stereo/16-bit test file. > to avoid dealing with endian issues in the file format. I don't > know whether any of those exist or not. I don't think so. 0.9 works fine on i386 (little) and sparc (big), and

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

>> Ok I will give it a try and see what I can come up with. > Is the most interesting data the [frame] and [subframe] info? > Is the qlp_coeff[], warmpup[] and parameter[] data for each frame/subframe important? Yes, it would be nice if MetaFLAC will show minimum and maximum values of parameters (if are not constant/fixed) for the stream. And it would be VERY NICE if you implement

On Mon, Nov 06, 2006 at 08:50:44AM -0800, Josh Coalson wrote: > ok, tried it out... passes test/test_seeking.sh and my > "xmms twitch" test, checked in to CVS. thanks! Thanks! I see you have changed the channels and bps setting, this doesn't work when the decoder hasn't decoded a frame. There should be a fallback for this case. -- Miroslav Lichvar -------------- next

On Mon, Oct 30, 2006 at 11:13:25AM -0800, Josh Coalson wrote: > my apologies for not doing this before Miroslav... I will definitely > integrate it this time. Thanks. Sending latest version of the patch. Now it can seek in files that have large id3 tag (or any random data) at the end and it won't loop on streams with shuffled frames. -- Miroslav Lichvar -------------- next part

In the precompute_partition_info_sums_ function, instead of selecting 64-bit accumulator when the signal bps is larger than 16, revert to the original approach based on partition size, but make room for few extra bits to not overflow with unusual signals where the average residual magnitude may be larger than bps. It slightly improves the performance with standard encoding levels and 16-bit files

Hi, I couldn't figure out how to file a bug in the bugtracker at sourceforge. So I send a report this way. Building FLAC from git for Android fails with the following message: utils.c: In function 'get_console_width': utils.c:181:17: error: storage size of 'w' isn't known utils.c:181:17: warning: unused variable 'w' [-Wunused-variable] make[3]: *** [utils.o]

On Sat, May 19, 2001 at 12:55:08AM -0400, Matt Zimmerman wrote: > On Sat, May 19, 2001 at 02:05:14AM +0000, Christian Weisgerber wrote: > > > Problems in FLAC 0.9: > > > > - On alpha, flac immediately dumps core for both encoding and > > decoding (FreeBSD/alpha). > > I have reproduced this on Debian/alpha as well. I will spend some time > debugging it

Please help me understand what values of FFMPEG's "compression_level" preset generate subset FLAC stream and what not-subset? Default value of compression_level for FFMPEG's FLAC encoder is 5. FLAC specific encoder parameters: Encoder flac [FLAC (Free Lossless Audio Codec)]: Threading capabilities: no Supported sample formats: s16 s32 FLAC encoder AVOptions:

Matt Zimmerman <mdz@debian.org> wrote: > Aha. In FLAC__fixed_restore_signal, the index variable 'i' is declared > unsigned, then used like so: [...] With the following trivial patch applied, > everything works on Alpha, at least with my test sample. Against 0.9 or CVS? While this clearly fixes a bug, 0.9 still dies for me. #0 0x1600692a8 in

Here's what I listed in that email. Merging doesn't appear to be necessary. If you have any build problems, let me know. Note that my detection code is Darwin-specific. It's a BSD call (sysctl()), so a change to the platform-detection macros should enable it to work on other BSDs. However, I don't know what that would be, and I couldn't determine any safe way to do the check

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:

On Mon, Jan 24, 2005 at 06:31:21PM -0800, Josh Coalson wrote: > yes, a mere 2 years later it is checked in! > > speed improvement for me is roughly 17% testing flac files on > linux-i386. Thanks! In case you would like to check another old patch, I have attached updated patch for seekable stream decoder, originally posted on 09/07/2003. -- Miroslav Lichvar -------------- next