> How hard is it to detect the results of this fix in the encoded output?
>
> It would be intresting to see if FhG has this fixed, if they don't then if
> they fix it with the next release. :)
>
I'm not sure that this fix can be heared.
Third case can be tested in decoder.
It seems to me that is possible to detect space leaks when part2_3_length
of the granule is greater than real bit length.
With exept of case when next_main_data_begin has a
maximum value - it can be a neccessary stuffing, or in the last
granule in frame - it's length can be aligned to byte.
choose_table bug can be checked if any partition having max==15
is coded with linbits.
I can check this if anyone can send me a bitstream to test.
-Leonid
> > 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.
> >
> > 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.
> >
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
