[
https://issues.apache.org/jira/browse/TIKA-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18100514#comment-18100514
]
ASF GitHub Bot commented on TIKA-4801:
--------------------------------------
tballison commented on PR #2983:
URL: https://github.com/apache/tika/pull/2983#issuecomment-5134178216
This is amazing. All the nooks and crannies for embedded files...
> 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)
