> >
> > Hi,
> >
> >
> > There is a bug in count1_bitcount calculation.
> > It came from dist10 and still remains in lame.
> >
> > In functions L3_huffman_coder_count1() (l3bitstream.c, line 799, 3.27beta)
> > and count1_bitcount() (loop.c, line 2184, ...)
> >
> > line
> > p = v + (w << 1) + (x << 2) + (y << 3);
> > must be
> > p = (v << 3) + (w << 2) + (x << 1) + y;
> >
> >
> > BTW, in count1_bitcount() lines
> > signbits = 0;
> > if ( v != 0 )
> > signbits ++;
> > if ( w != 0 )
> > signbits ++;
> > if ( x != 0 )
> > signbits ++;
> > if ( y != 0 )
> > signbits ++;
> > can be simplified by
> > signbits = v + w + x + y;
> > because they can be either 0 or 1.
> >
> >
> > Regards,
> > -Leonid
> >
>
> Hi Leonid,
>
> Are you sure about this? If I replace that line with:
>
> p = (v << 3) + (w << 2) + (x << 1) + y;
>
> I get (within the first few frames of castanets.wav) the followig error:
>
> lame: l3bitstream.c:759: Huffmancodebits: Assertion `stuffingBits > 0' failed.
>
> This almost always means that loop.c has choosen a quantization that
> uses more bits than available, probably because count1_bitcount() is
> returning too small of a value?
>
> Mark
>
Hi Mark,
I'm sure about this. I've verified this part with 11172-3 spec.
Have you replace this line in both functions L3_huffman_coder_count1()
and count1_bitcount()?
I've fixed the same way the 'dist10' code and it works.
May be there is another place in lame code where count1 length is calculated?
-Leonid
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
