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. :)
--
The comments and opinions expressed herein are those of the author of this
message and may not reflect the policies of the Martin County Board of
County Commissioners.
On Thu, 16 Sep 1999, Leonid A. Kulakov wrote:
> 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/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
