similar to: FLAC frame boundaries and protocol

Hello, I've set up and have been reading through the FLAC reference implementation source code on Windows and stepping through it in the debugger.   I've been trying to understand how the protocol knows where the subframe and frame boundaries are. Is there a good tutorial that discusses the ins and outs of the flac protocol? Also, is there a piece of the reference code that shows how

Hello Dave. Frames start with a 14-bit sync code, which is 13 “one" bits and 1 “zero" bit. Subframes start with a 1-bit padding of “zero." Keep in mind that FLAC is a bit stream, not a byte stream, so that 14-bit frame sync can happen anywhere in a pair of bytes. You can’t simply scan memory bytes for a frame sync, at least not unless you allow for 8 variations, apply bit masks,

I agree with Miroslav. It is a good practice to make a security release on a "branch" of the stable, shipped code, so that people can obtain the security fix with minimal risk to other changes. Even if the new code passes all tests fairly soon, it wouldn't hurt to have a couple of releases - one purely for security, the next with new changes in other areas. Brian Willoughby On Nov

2014-12-11 14:34 GMT+01:00 Miroslav Lichvar <mlichvar at redhat.com>: > > On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > > >> but I'd rather see the real seeking bug fixed instead > > > > > > I think I might

On Thu, Dec 11, 2014 at 11:12:25AM +0100, Martijn van Beurden wrote: > Op 11-12-14 om 10:53 schreef Martijn van Beurden: > > Op 11-12-14 om 10:05 schreef Miroslav Lichvar: > >> but I'd rather see the real seeking bug fixed instead > > > > I think I might have a fix [...] So the problem is that FLAC__stream_decoder_process_single returns error before it finds a

On 04-05-13 12:41, Erik de Castro Lopo wrote: > Miroslav Lichvar wrote: > >> On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: >>> I don't know why this isn't on the changelog, but it is probably still a >>> good idea to add it. This only breaks compatibility for 24-bit streams. >>> (So: decoders older than 1.2.0 might not be able

On Mon, Jun 30, 2014 at 03:27:18AM +0400, lvqcl wrote: > lvqcl wrote: > > FLAC 1.2.1 and 1.3.0 cannot encode snippet6.wav with -7 and -8 encoding modes. > > But they are able to do this with --disable-fixed-subframes option. This > > implies that snippet6.wav triggers a problem somewthere inside > > FLAC__fixed_compute_residual(data[], data_len, order, residual[])

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

On Mon, 4 Jun 2018 17:45:20 +0200 Miroslav Lichvar <mlichvar at redhat.com> wrote: > On Mon, Jun 04, 2018 at 04:54:36PM +0200, Andreas Schneider wrote: > > On Monday, 4 June 2018 14:52:34 CEST Rowland Penny wrote: > > > In ntp.conf you set a line like this: > > > > > > restrict default kod nomodify notrap nopeer mssntp > > > > > > I

On Fri, May 04, 2012 at 05:53:23PM +0200, Miroslav Lichvar wrote: > The most interesting part of the patch is the rewrite of the > FLAC__bitreader_read_rice_signed_block function, which in the git repo > seems to have only couple lines changed since 1.2.1. Here is that part of the patch rebased against current git. In a quick test it gives a 10% speedup in decoding. -- Miroslav Lichvar

On Thu, Sep 12, 2002 at 10:54:04PM +0200, Miroslav Lichvar wrote: > I tried tagging using metaflac with some iso-8859-2 chars, but these > chars were replaced by '#' chars, something wrong is here. Ok, here is simple patch, it works for me, but I'm not familiar with this stuff. BTW, metaflac --list prints comments in raw utf8, it can screw terminal easily. -- Miroslav Lichvar

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

On Sat, Apr 12, 2003 at 05:49:06PM -0500, David W. Tamkin wrote: > Early this past week, Miroslav Lichvar suggested for me: > > >Ok, you need 0.04% improvement, that should not be a problem. Try > >flac --lax -e -p -l 32 -r 10 --no-padding > > Thank you again, Miroslav. I tried that, and it took almost two full > days (surprisingly, Windows ME stayed up that long

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

Miroslav Lichvar wrote: > On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: > > I don't know why this isn't on the changelog, but it is probably still a > > good idea to add it. This only breaks compatibility for 24-bit streams. > > (So: decoders older than 1.2.0 might not be able to decode 24-bit FLAC > > files made by libFLAC 1.2.0 or

Miroslav Lichvar wrote: > On Wed, Jul 17, 2013 at 07:45:53PM +1000, Erik de Castro Lopo wrote: > > The fix was changing one local variable from FLAC_uint32 to FLAC_uint64 > > in function precompute_partition_info_sums_(). > > > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b > > I don't like this fix. It will

On Tue, Nov 25, 2014 at 12:29:33AM -0800, Erik de Castro Lopo wrote: > 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 > https://git.xiph.org/?p=flac.git;a=commit;h=fcf0ba06ae12ccd7c67cee3c8d948df15f946b85 I'm trying to figure out how this one

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

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:

Torsdag, 23 januar 2003, skrev Miroslav Lichvar <lichvarm@phoenix. inf.upol.cz>: >If input is 16 bit, side channel will be 17 bit (16bit - 16bit is >17bit number). And warmup samples will be (17 - wasted_bits) bit. Voila, this was the source of all my frustration, sync problems and who knows what. My decoder now works correctly for files encoded with the default settings. Are