Ok, I found two more bugs (now fixed) in the latest CVS version:
(Sorry Takehiro, but they were in your new code :-)
1. The count1 quadruples were encoded with the wrong sign: Any non-zero
coefficient in the count1 block was marked as negative!
2. The meaning of cod_info->big_values was changed by a factor
of 2 in the new takehiro.c/l3bitstream.c. But for short blocks,
cod_info->big_values was initialzied to the old value 288,
instead of 576.
#2 brings up another point: short blocks using a fixed big_values=576
(meaning the special huffman tables for the runs of data which are
just 0 or 1 are not used). This was just lazyness on the part
of the ISO programmers. Takehiro, have you given any thought to
coding up a search for a more optimal short block big_values ?
Mark
> X-Authentication-Warning: geek.rcc.se: majordom set sender to
>[EMAIL PROTECTED] using -f
> From: Robert Hegemann <[EMAIL PROTECTED]>
> Date: Tue, 28 Mar 2000 08:57:18 +0200
> Content-Type: text/plain
> Sender: [EMAIL PROTECTED]
> Precedence: bulk
> Reply-To: [EMAIL PROTECTED]
> X-MIME-Autoconverted: from quoted-printable to 8bit by cs.csoft.net id BAA15917
> X-UIDL: C&N!!U[m"!EOe"!:B%"!
>
> Hi Takehiro.
>
> I still get assertion failures at this point.
>
> Takehiro Tominaga schrieb am Die, 28 Mär 2000:
> > Hi, Robert.
> >
> > This "cod_info.count1 += 2" is necessary to reduce the code size,
> > but we can't reduce the code size when cod_info.count1 == 576.
> >
> > this is fixed before you check in the "assert".
> > and I think it is OK now...
>
> Sorry, but it is not OK now. If you check count1 == 576 before this,
> what happens if count1 == 575?
> 575+2=577 --> index overflow --> crash/assertion failure!
>
> So I assume, you have to check count1 >= 575 before.
>
> > ---
> > Takehiro TOMINAGA // may the source be with you!
> >
> > >>>>> "R" == Robert Hegemann <[EMAIL PROTECTED]> writes:
> >
> > R> I checked the 3.67 tarball from sulaco.org and it seems to
> > R> work. For the SEGFAULT problem with Takehiro's enhanced code I
> > R> inserted an assert(i<=576) in best_huffman_divide, and now it
> > R> stops with an assertion failure instead of a segmentation
> > R> fault.
> >
> > --
> > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
> Robert
> --
> http://linux.unixcity.de/catwalk/index.html
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
