lvqcl wrote:
> If the least significant bit in all samples of a 24-bit WAV file is set to 0,
> the encoder sets 'bps' variable to 23 and the description of this patch -
>
> "This fix [...] restores the use of a FLAC_uint32 accumulator for 16 (and
> less) bit files"
>
> - is not correct: this fi
On Sun, Jul 21, 2013 at 09:19:46PM +1000, Erik de Castro Lopo wrote:
> Miroslav Lichvar wrote:
> > >
> > > https://git.xiph.org/?p=flac.git;a=commit;h=6f7ec60c7e7f05f5ab0b1cf6b7b0945e44afcd4b
> >
> > I don't like this fix. It will probably hurt performance with 16-bit
> > data and it won't fi
Erik de Castro Lopo wrote:
> I have committed an improvement on the above fix.
>
>
> https://git.xiph.org/?p=flac.git;a=commit;h=f34f31dac0032887887b5bbcb0944de055b757d0
>
> that reverts to the use of a FLAC_uint32 accumulator for files of less
> than 24 bits per sample.
>
> I still have no p
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=6f7ec60c7e7f05
Erik de Castro Lopo wrote:
> I like to make it correct before I make it fast.
Just to 100% sure we know exactly how much I did some tests.
Test machine was Dell laptop with an Intel(R) Core(TM) i7-3537U
CPU @ 2.00GHz running Debian testing. The results for i386 below
are the same machine but run
On 17/07/13 19:45, Erik de Castro Lopo wrote:
> Martijn van Beurden wrote:
>
>> You've exposed at least two very serious FLAC bugs,
>> namely a malfunctioning RICE2-partition encoder and a bug concerning
>> choosing verbatim frames over fixed/lpc frames.
>
> The second, not choosing verbatim frames
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=6f7ec60c7e7f05
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 l
Martijn van Beurden wrote:
> You've exposed at least two very serious FLAC bugs,
> namely a malfunctioning RICE2-partition encoder and a bug concerning
> choosing verbatim frames over fixed/lpc frames.
The second, not choosing verbatim frames over fixed/lpc frames is almost
certainly a direct r
On 16-07-13 12:32, Leigh Dyer wrote:
> 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
Erik de Castro Lopo wrote:
> 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!
I'm currently testing a fix for this.
The problem was an arithme
On 07/16/2013 09:26 AM, Bastiaan Timmer wrote:
> Some more possibly interesting information:
>
> 1. With me, both flac 1.2.1 and 1.3.0 fail to produce a flac file at all.
> They both end with:
>
>
> snippet6.wav: 35% complete, ratio=0,781
> snippet6.wav: ERROR during encoding
> st
Some more possibly interesting information:
1. With me, both flac 1.2.1 and 1.3.0 fail to produce a flac file at all. They
both end with:
snippet6.wav: 35% complete, ratio=0,781
snippet6.wav: ERROR during encoding
state = FLAC__STREAM_ENCODER_FRAMING_ERROR
This is after my entire
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://
Leigh Dyer wrote:
> 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:
>
> h
On 16/07/13 8:10 PM, Erik de Castro Lopo wrote:
> Leigh Dyer wrote:
>
>> Certainly -- I've uploaded the analysis files for both the -6 and -7
>> encodes, in case you wanted to compare:
>>
>> http://wootangent.net/~lsd/blah/6.ana
>> http://wootangent.net/~lsd/blah/7.ana
>>
>> The encode seems to pro
Leigh Dyer wrote:
> Certainly -- I've uploaded the analysis files for both the -6 and -7
> encodes, in case you wanted to compare:
>
> http://wootangent.net/~lsd/blah/6.ana
> http://wootangent.net/~lsd/blah/7.ana
>
> The encode seems to proceed normally until 59% of the way through the
> file,
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
Leigh Dyer wrote:
> 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 -7 produces a
> 9
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
20 matches
Mail list logo
