>
> In reply to Robert Hegemann <[EMAIL PROTECTED]>:
> >>> Second: With some (usually high) bitrates, LAME seems to mangle the
> >>> bitstream. The effect is usually to hear short bursts of garbage in the
> >>> left channel, but it seems to depend on the input file as well as the
> >>> bitrate. Not all frames are affected.
> >
> > Rob, can you provide us with a short example track?
>
> I'm happy to report this turned out to be a bug in my code, not in LAME.
>
> I didn't anticipate well enough the possible resulting main_data() lengths
> for some of these very high bitrates. I think I've properly recalculated the
> maximum main_data length to be 16380 bits, since each part2_3_length is
> limited to 2^12 - 1. Does this seem right?
>
> I suppose a legitimate decoder might well refuse to decode a stream with
> main_data() lengths exceeding the 7680-bit buffer limit imposed by ISO/IEC
> 11172-3.
>
16376 is what LAME uses, unless you specify --strictly-enforce-ISO.
I'm sure this problem is why the FHG decoder will not decode free format
over 320kbs. However, even CBR 320kbs frames encoded with LAME will often
violate 7680 bit buffer limit (since we use the bit reservoir
even at 320kbs) and I've never had any reports of a decoder
which could not handle this.
> My next release of MAD should have this fixed and will fully support any
> free format bitrate produced by LAME... with the exception of MPEG 2.5
> streams.
>
> On that subject, where can I get "official" documentation for the so-called
> MPEG 2.5 format?
>
You dont need it :-) MPEG2.5 is almost identical to MPEG2: just divide
all the sample rates by 2 and the syncword is FFE instead of FFF.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
