[Rhythmbox-devel] Extraction of embedded cover art
- From: "John Millikin" <jmillikin gmail com>
- To: rhythmbox-devel gnome org
- Subject: [Rhythmbox-devel] Extraction of embedded cover art
- Date: Thu, 31 Jan 2008 23:30:58 -0800
I've been working on Bug #345975 [Show album covers embedded in files
e.g. mp3 ID3 tags]. "moch" in #rhythmbox asked me to post an
explanation of what my newest patch is doing to the list. I don't know
if this method is the "right" way to handle embedded art as metadata,
but it certainly seems better than my old search plugin.
Defines new metadata and Rhythmdb properties to support a URI, which
points to an image to be used as the album art. When the cover art
plugin begins a search on a track, it checks if a URI exists, and if
so, retrieves it.
To extract the URI from the track, the GST metadata extractor has a
special case for the "image" tag. If one is encountered in a track's
tag list, the art is saved to a file in
~/.gnome2/rhythmbox/cover-art/. The file's name is the SHA-1 hash of
the image's contents, so the same art in multiple tracks will not be
needlessly duplicated. If the cover art's MIME-type is "-->", the
image data itself is stored as the URI. This feature of ID3/FLAC tags
appears to be rarely, but sometimes, used. Currently, directly
specified URIs are not copied into the cover art cache directory.
I did not use the existing /covers/ directory, because that is used as
an on-disk cache by the artdisplay plugin.
There is still a bug, in that two files with no tags but with embedded
art will not have their art properly displayed. It is still extracted
correctly, but the artdisplay plugin's URI retriever caches even local
URIs, and so both tracks would be cached at "Unknown - Unknown.jpg". I
intend to correct this, but would first like to get opinions on the
implementation of the extraction system itself.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]