Hi
> 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
>
It seems to be a bug of 11172-3 doc. It is in my paper too.
I rely on 2.4.2.7, which describe decoding process.
> Leonid: how the hell did you ever find this?
>
My goal was to fix situation, when bit length of code granule
occurs to be different with value calculated in iteration_loop().
We can make the same in lame.
First, ResvFrameEnd() should be fixed to not insert any stuffing to granules.
It seems to me that it will be better put stuffing with ancillary data
outside frame data, i.e. between end of main data of this frame
and before next main_data_begin.
Second, this count1 fix.
Third, it seems to me that this error exist in lame too.
In subdivide function when cod_info->window_switching_flag is 1,
can be the case when address2 ( == bigvalues_region ) is less than
address1. So calculation of bit length of big_values_part[0]
(from 0 to address1) counts more bits that it should because it adds
a number of pairs that belongs to count1.
This is checked in l3bitstream and packed length is correct and less
that one stored in part2_3_length.
If we count bits the right way, we get more bit available. The more
bits - the higher quality.
Mark: if you have a questions on how to make this,
feel free to contact me via mail directly.
After all of that in the Huffmancodebits() function
stuffingBits = gi->part2_3_length - gi->part2_length - bitsWritten
will allways be zero and can be asserted.
And one more lame error:
new_choose_table() and choose_table() have line
if ( max < 15 )
It should be
if ( max <= 15 )
because tables 13 and 15 are limited to max value 15 including.
Otherwise it will be coded with linbits and in more bits.
Again, the more bits - the higher quality.
Regards,
-Leonid
P.S. Sorry for bad english, it is not my native.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
