[
https://issues.apache.org/jira/browse/TIKA-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100441#comment-18100441
]
ASF GitHub Bot commented on TIKA-4801:
--------------------------------------
dschmidt opened a new pull request, #2983:
URL: https://github.com/apache/tika/pull/2983
Fixes TIKA-4801 for the three formats where the pictures are reachable
today: ID3v2 APIC frames (v2.2 PIC included), the MP4/M4A `covr` atom
(previously explicitly skipped) and Vorbis/Opus `metadata_block_picture`
comments.
Each picture is emitted through the standard EmbeddedDocumentExtractor
mechanism as an inline embedded document, the same way PDF and Office parsers
emit embedded images: /rmeta returns one metadata entry per cover with the
declared content type (or auto-detection where MP4 only has a type code), the
declared description as dc:title and the picture type as dc:description;
/unpack delivers the bytes. Deliberately no new metadata properties on the
audio document and no mapping of the width/height fields that Vorbis picture
blocks declare: ID3 and MP4 declare no dimensions at all, and the embedded
entry carries the real ones once image parsers are on the classpath.
The raw metadata_block_picture comment is no longer passed through as a
giant base64 vorbis: value, it becomes the embedded document instead.
FLAC native PICTURE blocks are out of scope for now: vorbis-java 0.8 keeps
the metadata blocks in a field without a public accessor, so that needs a small
upstream addition first.
One commit per format, each with its own fixture and end-to-end test; the
fixtures are minimally modified copies of existing test files carrying a 1x1
PNG cover (for the Ogg fixture the comment packet was rewritten with recomputed
page CRC). All three tests fail without their parser change.
> Extract cover art from audio files
> ----------------------------------
>
> Key: TIKA-4801
> URL: https://issues.apache.org/jira/browse/TIKA-4801
> Project: Tika
> Issue Type: New Feature
> Reporter: Dominik Schmidt
> Priority: Major
>
> Audio containers commonly embed cover art, but Tika drops it everywhere:
> Mp3Parser ignores ID3v2 APIC frames, TikaUserDataBox explicitly skips the
> MP4/M4A 'covr' atom ("skip this for now"), and the Ogg family parsers do not
> handle METADATA_BLOCK_PICTURE respectively the FLAC PICTURE block.
> Proposal: emit the pictures through the standard EmbeddedDocumentExtractor
> mechanism, the same way PDF and Office parsers emit embedded images. No new
> metadata properties are needed: with the RecursiveParserWrapper (/rmeta) each
> cover shows up as its own metadata entry with content type and real
> dimensions from the image parser, uniformly for all four formats, and /unpack
> delivers the bytes. That is deliberately preferred over mapping the
> width/height fields that FLAC and Vorbis picture blocks declare, since ID3
> and MP4 declare no dimensions at all and the declared values are unreliable
> anyway.
> Where available, the declared picture type (front cover, back cover, ...) and
> description can be set on the embedded document's metadata.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
