>
> 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
>
sorry about that - I had only changed count1_bitcount() even though
your message was very clear about both routines. When I also change
l3_huffman_coder_count1() it works. I still cant do listening tests
because my sound card is broken - have you noticed any differences
between the two formulas? This could be a rather significant
bug - it will scramble quadruples of the highest MDCT coefficients.
Are you refering to page 104, C.1.5.4.4.5 in the 11172-3 doc?
In my version of the docs, the term involved is:
ix(4k) + 2*ix(4k+1) + 4*ix(4k+2) + 8*ix(4k+3)
v w x y
And in l3bitstream.c:
for ( i = bigvalues; i < count1End; i += 4 )
{
v = ix[i];
w = ix[i+1];
x = ix[i+2];
y = ix[i+3];
// bitsWritten += L3_huffman_coder_count1( pph, h, v, w, x, y );
bitsWritten += L3_huffman_coder_count1( pph, &ht[gi->count1table_select + 32],
v, w, x, y );
}
and thus shouldn't this translate into:
v + (w << 1) + (x << 2) + (y << 3);
However, if you look at table B.7 (huffman code table for quadruples)
where they use the vwxy notation, it looks like v is the most
significant bit, although they dont say how v,w,x and y are defined.
Mark
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
