<table><tr><td style="">astippich added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D12320">View Revision</a></tr></table><br /><div><div><p>This revision is only one possibility and is mainly there to start the discussion again on how to read the embedded picture data from e.g. audio files. Before this can land, Baloo has to be patched in order to cope with binary data.<br />
I think for Baloo there are two possibilities: (a) Put it in the database same as all other data or (b) ignore the binary data. In the latter case, applications would have to query the metadata separately in order to get the cover.<br />
For KFileMetaData I also see two possible implementation: Either in the taglibextractor, or in a completely new extractor that only reads the cover files (may be also useful for ebooks, but I don't know if such things exist there). If we agree on (a), I would opt to implement it in taglibextractor, if we chose (b) I think a new extractor makes sense such that applications would not have to read all the metadata again with the taglibextractor, but could specifically just read the picture data and get the rest from Baloo.</p>

<p>Any other suggestions? Opinions?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R286 KFileMetaData</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D12320">https://phabricator.kde.org/D12320</a></div></div><br /><div><strong>To: </strong>astippich, mgallien, michaelh<br /><strong>Cc: </strong>Frameworks, ashaposhnikov, michaelh, astippich, spoorun, bruns<br /></div>