[
https://issues.apache.org/jira/browse/TIKA-4801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18105642#comment-18105642
]
Dominik Schmidt commented on TIKA-4801:
---------------------------------------
Looks great: 963 covers from 937 mp3s (so multi-cover files are handled), plus
mp4/m4v, opus/vorbis and flac all contributing, and no attachment regressions
in the no-exceptions report. Related: TIKA-4824 (PR #3037) extends the same
embedded-preview approach to TIFF-based camera raw files, so those should show
up here too once merged. :)
> 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
> Fix For: 4.0.0
>
>
> 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)
