[
https://issues.apache.org/jira/browse/TIKA-4850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109997#comment-18109997
]
ASF GitHub Bot commented on TIKA-4850:
--------------------------------------
dschmidt commented on PR #3090:
URL: https://github.com/apache/tika/pull/3090#issuecomment-5482216692
Thanks, that was a useful list. All six are in:
1 was real: extractComments now returns the pictures and FlacParser merges
them with the native PICTURE blocks before one emission;
testFLAC_commentAndNativePicture.flac (built from the existing fixture) pins
one THUMBNAIL for a file carrying both.
2: types beyond the ID3 table count as unknown now, normalized in one place.
3: the javadocs point at CoverArt#thumbnailIndex instead of restating it.
4: a synthetic back-then-front APIC pair in Mp3ParserTest asserts
INLINE/THUMBNAIL.
5: readNativePictures got a direct test: a PICTURE block declaring more data
than the file has left ends the walk and keeps the earlier pictures. That
avoids the vorbis-java tolerance question entirely.
6: one emission lives in CoverArt.extractPictures over a small Picture
record; MP3, Ogg and FLAC share it, MP4 spells out its ternary.
> Mark audio cover art as THUMBNAIL embedded resources
> ----------------------------------------------------
>
> Key: TIKA-4850
> URL: https://issues.apache.org/jira/browse/TIKA-4850
> Project: Tika
> Issue Type: New Feature
> Reporter: Dominik Schmidt
> Priority: Major
>
> The audio parsers (Mp3Parser, MP4Parser/TikaUserDataBox, OggAudioParser,
> FlacParser) emit embedded pictures with tk:embedded-resource-type=INLINE. For
> a client that wants "the representative image of this file" that is
> inconsistent with the other container parsers: ODF, OOXML, iWork, GeoGebra
> and RawTiffParser all mark that image THUMBNAIL, so a client can pick the
> first THUMBNAIL without knowing the format. For audio it currently needs a
> special case (INLINE image, and for ID3/FLAC preferably the one whose
> dc:description is "Cover (front)").
> INLINE also does not describe what cover art is: it is not a picture placed
> in the document's text flow, it is the picture that stands for the file.
> Proposal:
> - ID3v2 APIC and FLAC/Ogg PICTURE blocks: emit picture type 3 "Cover (front)"
> as THUMBNAIL. If a tag has no front cover, emit the first picture as
> THUMBNAIL. All other pictures stay INLINE (or become ATTACHMENT).
> - MP4 covr: the atom carries no picture type; emit the first cover as
> THUMBNAIL, further ones INLINE.
> - Keep dc:description with the picture type name as it is.
> This changes the resource type of one embedded document per audio file;
> clients filtering on INLINE to find cover art would need to accept THUMBNAIL
> as well. Worth a CHANGES note.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
