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/ )
