similar to: [PATCH] Optionally, allow distros to use openssl for MD5 verification

op 29-06-14 15:31, Erik de Castro Lopo schreef: > I would appreciate it if people could kick this around, test on other > platforms/architectures and test for performance regressions. These patches indeed fix the -Wcast-align warnings, but the new MD5 tests fail > +++ libFLAC unit test: md5 > > testing FLAC__MD5Init ... OK > testing that FLAC__MD5Final clears the MD5Context

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

Hi all, If you take a look at the service.rb file in the win32-service repository (the new one in the toplevel repository path), I''ve got this bit of code, which succeeds, but I can''t seem to unpack the data structure properly. Did I pack it wrong to begin with? I should know this but I''m spacing out. proc_status =

This lpc_restore_order was partially inspired by Miroslav's affd, though my (not very great) ARM asm version resembled this, as well. The other two reduce CPU array indexing overhead in loops a little. Additionally, a request for help: My not very optimized lpc_restore_signal is at the below URL, I couldn't get the ldm* instructions to work as advertised, even though I've talked

When I was trying to find yesterday's xmms-plugin bug, i have noticed that seeking in stream without seek-table isn't very good. With attached patch it is much better. -- Miroslav Lichvar -------------- next part -------------- --- src/libFLAC/seekable_stream_decoder.c.orig 2003-02-26 19:41:51.000000000 +0100 +++ src/libFLAC/seekable_stream_decoder.c 2003-07-09 23:49:35.000000000 +0200

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

--- configure.ac | 7 +++++ src/libFLAC/bitreader.c | 12 ++------- src/libFLAC/bitwriter.c | 8 ++---- src/libFLAC/fixed.c | 18 +++++-------- src/libFLAC/format.c | 8 ++---- src/libFLAC/include/private/macros.h | 29 ++++++++++++++++++++ src/libFLAC/metadata_iterators.c | 17 +++---------

Ok, the patch from 2003 about improving seeking still didn't make it to CVS, so here is another try. I made some benchmarking with the test_seeking utility from flac sources to show how bad the current seeking is, especially without seektable. Track used for the experiment had about 50 minutes. In the following table is average number of seeks and number of decoded frames required for one

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

Hi all, In commit 3eb4094b859 I think I have fixed all the cast-align warnings. I have tested this in amd64/Linux (little endian) and powerpc64/Linux (big endian) and it passed all tests (including the new MD5 tests). I also did a little performance testing on amd64/Linux with a one hour long stereo WAV file and could not find any mesasurable difference between the old and the new code. I

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

And here is another one. It allows fast seeking in streams without total_samples information. There is a check for such streams in flac, so flac --skip doesn't work. If the check is removed, it will work with --force-raw-format only, there is an issue with wav and aiff header handling. -- Miroslav Lichvar -------------- next part -------------- ---

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 Thu, Jun 19, 2014 at 06:25:57PM +0400, lvqcl wrote: > Now I wonder why evaluate_lpc_subframe_() function in stream_encoder.c contains > almost the same code, but without any comments that it's not enough pessimistic: > evaluate_lpc_subframe_(): > > if(subframe_bps + qlp_coeff_precision + FLAC__bitmath_ilog2(order) <= 32) > if(subframe_bps <= 16 &&

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

Dear list, i'm doing a bit of analisys on flac's source code and i've run into something i can't quite grasp. flac version 1.2.1 flaclib C stream_encoder.c function "process_subframes_" line 2999 ++++++++++++++++++++++ if(do_mid_side) { FLAC__ASSERT(encoder->protected_->channels == 2); for(channel = 0; channel < 2; channel++) {

On Wed, Dec 10, 2014 at 10:54:15PM -0800, Erik de Castro Lopo wrote: > Erik de Castro Lopo wrote: > > > I think I have an alternative fix for the CVE which should not break > > seeking. I'm working on getting an copy of the file with which to test. > > Patch applied and pushed. I think this revives the CVE, at least in some configurations. The patch seems to cover

Here's a patch to allow flac and metaflac handle files with malformed vorbiscomment metadata block. -------------- next part -------------- diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index d50df39..39cb276 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -78,7 +78,7 @@ static FLAC__Metadata_SimpleIteratorStatus