[
https://issues.apache.org/jira/browse/TIKA-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096639#comment-18096639
]
Hudson commented on TIKA-4791:
------------------------------
SUCCESS: Integrated in Jenkins build Tika ยป tika-main-jdk17 #1482 (See
[https://ci-builds.apache.org/job/Tika/job/tika-main-jdk17/1482/])
[TIKA-4791] Use LSF frame size for MPEG2/2.5 Layer III (#2954) (github:
[https://github.com/apache/tika/commit/73c816079bb1c7ebb32b31ea248b67eaf6df4270])
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-audiovideo-module/src/test/java/org/apache/tika/parser/mp3/Mp3ParserTest.java
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-audiovideo-module/src/main/java/org/apache/tika/parser/mp3/MpegStream.java
* (edit)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-audiovideo-module/src/test/java/org/apache/tika/parser/mp3/MpegStreamTest.java
* (add)
tika-parsers/tika-parsers-standard/tika-parsers-standard-modules/tika-parser-audiovideo-module/src/test/resources/test-documents/testMP3mpeg2.mp3
> 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)
