[
https://issues.apache.org/jira/browse/TIKA-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096229#comment-18096229
]
ASF GitHub Bot commented on TIKA-4791:
--------------------------------------
dschmidt opened a new pull request, #2954:
URL: https://github.com/apache/tika/pull/2954
Fixes TIKA-4791. MpegStream computed every non-Layer-I frame with the MPEG1
values (144 * bitrate / samplerate bytes, 1152 samples), but MPEG2 and MPEG2.5
Layer III (the low sampling frequency 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.
The effect on low-samplerate MP3s: the frame walk skipped over the following
frame and visited at best every second frame (where the doubled skip landed
mid-frame, the sync scan dropped further frames), `AudioFrame.getLength()` and
`getDuration()` were wrong by exactly 2x, and while the summed duration nearly
cancelled for CBR files, it came out over 10 percent short on 22050 Hz VBR
files.
Frame length and duration now branch on version and layer. Layer II keeps
1152 samples in every MPEG version and Layer I was already correct, so those
paths are unchanged and covered by a guard test. Regression tests cover all
four version/layer combinations, plus an end-to-end duration check on a real
ffmpeg-encoded 22050 Hz MPEG2 file (79 frames, walked to a clean EOF); the
three LSF assertions fail against the previous code.
> 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
> Priority: Major
>
> 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)
