similar to: How is the MD5 hash calculated?

>> I'm jumping in on this thread to make a few remarks about the spec. I >> implemented a FLAC decoder by only looking at the spec, and I have a few >> notes that would have saved me a lot of time if the spec had mentioned >> them. They are obvious in hindsight, of course. >> >> * If the channel assignment includes a difference channel, then the >>

Hi all, I'm jumping in on this thread to make a few remarks about the spec. I implemented a FLAC decoder by only looking at the spec, and I have a few notes that would have saved me a lot of time if the spec had mentioned them. They are obvious in hindsight, of course. * If the channel assignment includes a difference channel, then the subframe for that channel has one extra bit per sample

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, 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 CVE-2014-8962 : Heap buffer read overflow For Linux distributions, the specific fixes for these two CVEs are available from Git here:

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

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

Erik de Castro Lopo wrote: >> It slightly improves the performance with standard encoding levels and >> 16-bit files as the 17-bit side channel can still be processed with the >> 32-bit accumulator and correctly selects the 64-bit accumulator with >> very large 16-bit partitions. >> >> This is related to commits 6f7ec60c and 187e596e. > > Sorry I

On Thu, Jun 19, 2014 at 03:30:22PM +0400, lvqcl wrote: > BTW, what can you say about the following place in stream_decoder.c > in read_subframe_lpc_() function: > > /*@@@@@@ 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)

I would like to know if my vision of things is correct about frame structure. -------------------------------------------------------- Frame header -------------------------------------------------------- Subframe1 header|Subframe1 content| -------------------------------------------------------- Subframe2 header|Subframe2 content| --------------------------------------------------------

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. commit b4b2910bdca010808ccf2799f55562fa91f4347b Author: Erik de Castro Lopo <erikd at mega-nerd.com> Date: Wed Dec 10 18:54:16 2014 +1100

> -----Ursprungliche Nachricht----- > Von: Josh Coalson > > yes, I will probably get to it soon after the release. > the encoding side is pretty convoluted but for decoding, > src/libFLAC/stream_decoder.c:read_residual_partitioned_rice_() > should be pretty straightforward once you ignore the > FLAC__SYMMETRIC_RICE stuff (which is not used). feel free to > ask

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

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

Jean-Marc, >> > It's odd that it "almost" works with the fixed_generic.h. The easiest >> > thing would be to gradually replace routines and see which one causes >> > problem. It's most likely (though I'm not 100% sure) that somewhere in >> > the code, I have a 16-bit value that gets sent to a function/macro that >> > expects a

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

I'm study FLAC decode problem, but can't figure out how to get FLAC frame length. Please help.https://xiph.org/flac/format.html I docoded METADATA_BLOCK_STREAMINFO, and get below data: mMinBlock: 4096 mMaxBlock: 4096 mMinFrame: 1201 mMaxFrame: 12804 mSampleRate: 44100 mBitPerSample: 16 mTotalSample: 14170212 Then I start to analyse first Frame, below is the info from first Frame header:

I changed the condition in *_precompute_partition_info_sums_*() functions from if(bps <= 16) to if(FLAC__bitmath_ilog2(default_partition_samples) + bps < 32) and then changed the 'subframe_bps' argument of find_best_partition_order_() in evaluate_fixed_subframe_() and evaluate_lpc_subframe_() as follows: evaluate_fixed_subframe_(): evaluate_lpc_subframe_(): 1)

Hi all, We (WebRTC/Google) would like to extend Opus to natively support 120 ms encoding instead of relying on repacketization as a post processing step. This is to ensure that a valid 120 ms packet is always available. I've attached a couple of patches to add this to opus_encoder(), based on the internal repacketization process carried out by 60 ms CELT. We intend to extend this later for

On Mon, Dec 1, 2014 at 10:40 PM, ???? ?????? <bart.gopnik at gmail.com> wrote: > Please help me solve the following problem: > > FLAC tools have a lots of warnings about non-subset files during > encoding, but unfortunately don't have easy way to check/test existing > FLAC stream for subset compliance. > > "flac -a" generates the big text file that has

Hi all, Thanks for the really great help I've received on this board in the past. I have a very particular graph that I'm trying to plot, and I'm not really sure how to do it. I think I should be able to use ggplot for this, but I'm not really sure how. I have a data.frame which contains fifty sub frames containing one hundred data points each. I can do a histogram of each of