> >
> > 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
> >
>
I went through mpg123/mpglib, and confirmed this bug! Very interesting.
The high freq. coefficients which quantize to zero or 1 are all encoded
in lumps of 4. What this bug is doing is reversing the order: encoder
encodes coefficient a,b,c,d, then decoder will decode this as d,c,b,a!
I wonder if this is responsible for some of that high frequency twinkling
in some of our test samples.
Leonid: how the hell did you ever find this?
I'm sill not completely clear on what is going on, but here is what I
think:
ISO = formula in ISO *encoder*
LEONID = Leonid's formula.
ISO encoder is using: ISO formula
ISO decoder is using: LEONID's formula
mpg123 is using: LEONID's formula
But my reading (and I could be confused) of the ISO documentation
looks like the ISO formula. When the documentation is unclear,
the demonstration source is defined to be authoritative. But what
happens when the demonstartion encoder does not agree with the
demonstartion decoder?
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
