I was going through my backlog of email that still needs to be
answered, and I came upon Rob's Jun 21 message (below) about the
maximum value of the big_values range. As I read this message for the
third time, still not sure what to think about this issue, it occured
to me: This has to be the winamp/100hz bug!
If you change IXMAX_VAL to 8191, then the LAME produced
"100only.mp3" file plays back correctly in Winamp :-)
I always thought the bug was related to the large amounts of ancillary
data. But the same thing that causes that (very little bit pressure)
also allows for very large amplifications, causing encoded values to be
in the range 8192 up to 8206.
It is possible to encode values up to 8206, although the ISO docs can
be interpreted to say you should not use values greater than 8191.
Most decoders can handle values up to 8206, including Fraunhofer, but
some decoders (Winamp, Macamp, Sonique) choke on this.
This probably shouldn't be called a winamp bug or a LAME bug,
but instead a unclear ISO specification.
Should we change IXMAX_VAL to 8191?
pros:
1. as Rob points out, less false syncwords in the bitstream.
(8206 is encoded as 0x1FFF).
2. LAME produced mp3's will no longer trigger Winamp bug.
cons:
1. Winamp may not bother to fix their decoder
2. Tiny loss in quality just to pander to Winamp users.
(all Linux decoders I've tested do not have this problem)
3. LAME produced mp3's will no longer trigger Winamp bug
(so it will look like it was a bug in LAME :-)
Mark
> From: Rob Leslie
> Date: Wed, 21 Jun 2000 03:06:27 -0400
>
> Hi Mark,
>
> > I'm pretty sure it is okay as is. Values greater than 8191
> > would always be encoded with "linbits", meaning the number
> > is written directly into the bitstream after an escape code.
> > linbits allows up to 13 digits, which would give
> > an upper bound of 8191. But with mp3/linbits, 15 is subtracted
> > before the number is written to the bitstream. Thus the actual
> > maximum is 8206. (numbers < 15 are encoded with huffman codes)
>
> I understand how values up to 8206 can be encoded; my question is whether it
> should be considered legal to encode values greater than 8191, since a decoder
> relying on the statement in ISO/IEC 11172-3 that "[t]he maximum absolute value
> in this [big_values] range is constrained to 8191" might be tempted to
> allocate a requantization lookup table with only 8192 entries. Such was the
> case in my own implementation until I discovered LAME could (albeit rarely)
> create bitstreams with encoded values > 8191.
>
> It wouldn't be the only ambiguous statement in the standard, but in context it
> does appear pretty clear. The informative statements in C.1.5.4.4.2 are less
> clear but, at face value, could also support the conclusion that the maximum
> absolute value should be constrained by linbits alone, and not 2^linbits + 15.
>
> At least one argument I can think of in favor of the limit, other than the
> assertion in the standard, is to help prevent creating false sync words. It
> can also serve as minimal error detection.
>
> More thoughts?
>
> --
> Rob Leslie
> [EMAIL PROTECTED]
> --
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
