search for: snippet6

...; The patch still applies, and the test suite passes. If there is a > problem with this patch that the test suite doesn't catch, we should > write a test that does catch it. > > If there is no problem with the patch I'll push it. As I see it: 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[]) function. And indeed, max. possible residual value is 16 time...

Erik de Castro Lopo wrote: > > http://wootangent.net/~lsd/blah/snippet6.wav > > Great, thanks! Confirmed the problem here. Will look at it ASAP. Same problem with flac 1.2.1. Interesting! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

...The first time I tried, the resulting file encoded just fine, but after trying a few more times, cutting at slightly different points, I was able to get a snippet of that section that exhibits the problem. This is short enough that I think I can link to it here: http://wootangent.net/~lsd/blah/snippet6.wav This results in a 4.1GB file when encoded with -7. Thanks Leigh

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)

...test suite passes. If there is a >> problem with this patch that the test suite doesn't catch, we should >> write a test that does catch it. >> >> If there is no problem with the patch I'll push it. > > As I see it: > > 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[]) function. > > And indeed, max. possible r...

...;s the reason why FLAC__MAX_EXTRA_RESIDUAL_BPS is equal to 4? Not really, it's just a guess. With LPC the maximum possible residual could be much larger than with the fixed predictor if the coefficients were chosen randomly, but the autocorrelation routine should keep them more reasonable. The snippet6.wav file needed 2, so I made it slightly larger to have some extra room. As overflow in the accumulator won't result in a data loss, I think this is good enough until someone can figure out a better approach. -- Miroslav Lichvar

...blem in my (small) > music collection. > > If someone has a large collection and some cycles to spare, can you please > consider compiling flac from git with the attached patch and see if > you have any files that fail with "flac -t" ? > > With the known problem file (snippet6.wav) encoded by 1.3.0 it prints > this: > > WARNING: residual -11025151 wider than bps 24 > WARNING: residual 41873263 wider than bps 24 > WARNING: residual -67175215 wider than bps 24 > WARNING: residual 69950995 wider than bps 24 > WARNING: residual -67108864 wider than bps 2...

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[]) function. Interestingly, -8 -l...

...9;t find any files with this problem in my (small) music collection. If someone has a large collection and some cycles to spare, can you please consider compiling flac from git with the attached patch and see if you have any files that fail with "flac -t" ? With the known problem file (snippet6.wav) encoded by 1.3.0 it prints this: WARNING: residual -11025151 wider than bps 24 WARNING: residual 41873263 wider than bps 24 WARNING: residual -67175215 wider than bps 24 WARNING: residual 69950995 wider than bps 24 WARNING: residual -67108864 wider than bps 24...

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

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

...ed, the resulting file encoded just fine, but after > trying a few more times, cutting at slightly different points, I was > able to get a snippet of that section that exhibits the problem. This is > short enough that I think I can link to it here: > > http://wootangent.net/~lsd/blah/snippet6.wav > > This results in a 4.1GB file when encoded with -7. Have you notices that there are a few damaged areas in this file? For example at 4.854 seconds, 6.700s, 6.828s, 7.618s. It looks to me like damage accumulated during some process after mastering, somewhere in the process of transf...

On 16/07/13 6:31 PM, Martijn van Beurden wrote: > On 16-07-13 09:07, Leigh Dyer wrote: >> Hi, >> >> On a particular input file, FLAC (testing with current git) greatly >> inflates its output if I encode at level 7, which enables >> --exhaustive-model-search. The source is a 24-bit WAV file of about >> 60MB; flac -6 encodes this to a 43MB FLAC file, but flac