Dominik Schmidt created TIKA-4791:
-------------------------------------
Summary: MpegStream uses MPEG1 frame size constants for MPEG2/2.5
Layer III
Key: TIKA-4791
URL: https://issues.apache.org/jira/browse/TIKA-4791
Project: Tika
Issue Type: Bug
Reporter: Dominik Schmidt
My agent reported this while working on the variable bitrate and drm feature:
MpegStream.calculateFrameLength computes every non-Layer-I frame as 144 *
bitrate / samplerate + padding, and calculateDuration credits every non-Layer-I
frame with 1152 samples. That is correct for MPEG1 Layer III and for Layer II
in all versions, but MPEG2 and MPEG2.5 Layer III (the LSF mode of ISO/IEC
13818-3) carry a single granule of 576 samples per frame, so the coefficient is
72. Reference decoders (FFmpeg, mpg123, libmad) all halve these values for LSF
streams; MpegStream never consults the MPEG version it already parses.
Consequences for low-samplerate MP3s (verified against ffmpeg-encoded MPEG2/2.5
files): the computed frame length is twice the real one, so the frame walk
skips into the middle of following frames and only resyncs via the 0xFF scan,
visiting roughly every second frame (every third at 22050 Hz).
AudioFrame.getLength() and getDuration() are wrong by exactly 2x. The summed
duration nearly cancels for CBR files (measured 1 to 3 percent off), but is
more than 10 percent short on 22050 Hz VBR files, and the average bitrate
statistic is skewed there for the same reason (biased frame sample).
The existing tests never assert frame length or duration for an MPEG2 header,
which is why this went unnoticed. Fix is local to MpegStream: select the length
coefficient and sample count by MPEG version and layer (72/576 for MPEG2 and
MPEG2.5 Layer III, unchanged otherwise).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
