Tatiana Azundris

Thank you for your kind words about evidence.
I think part of what makes it interesting is that it is a file-manager for shell-users, by shell-users.
I've never used nautilus or konqueror for a variety of reasons, and at first I wasn't convinced I'd actually use evidence. Nowadays, I do about 5o % of my file-managing in evidence and 5o % in the shell. Basically whenever previews come in handy, evidence wins hands down. Imagine looking for a particular image in a hundred that you downloaded from your digitical camera. Ultra-fast JPEG thumbnailing, support for EXIF, ID3/Ogg tag editing, actions for renaming the file from the tag (or tagging based on the file-name) etc. make ev really useful when working with media.

This usually correct. : )

Normally, an image of a well-known type (JPEG, PNG, ...) will be embedded. It is however also possible to embed an URL instead of the actual image data.

While this may seem silly at first (given that usually the image isn't all that big compared to the actual sound data, especially when the former is JPEG-compressed), it can be argued that if you actually want to include decent-quality images of all of the types (composer, cover, ...), and you have an album full of songs for which most of these images don't change (for instance, the album-cover is the same for each song), avoiding the redudancy may be desirable.

As stated above, several images may pertain to each song-file. The MIME-type for each image is explicitly noted; each image may therefore be of a different MIME-type. (This would imply that some you can mix in-band per-song images and out-of-band per-album or per-band images.) If the MIME-type (denoting embedded image data) is missing in favour of the magic marker "-->", an out-of-band image referenced by an URL (as per RfC 1738) is assumed. This seems interesting specifically for absolute HTTP-URLs and relative URLs (using the URL of the MP3 as a base; this will normally result in an URL using the file-scheme -- or in real terms, "look for the image in the same directory you found the MP3 file in").

To quote from the randomly googled http://id3lib.sourceforge.net/id3/id3v2.4.0-frames.txt:

«Image format is the MIME type and subtype for the image. In the event that the MIME media type name is omitted, "image/" will be implied. The "image/png" or "image/jpeg" picture format should be used when interoperability is wanted. Description is a short description of the picture, represented as a terminated text string. There may be several pictures attached to one file, each in their individual "APIC" frame, but only one with the same content descriptor. There may only be one picture with the picture type declared as picture type $01 and $02 respectively. There is the possibility to put only a link to the image file by using the 'MIME type' "-->" and having a complete URL instead of picture data. The use of linked files should however be used sparingly since there is the risk of separation of files.»

Detect all MP3s with image tags (using the id3info program):

find "/my/music" -print0|perl -n0e 'chop; $f=$_; $e="id3info ".chr(34).$f.chr(34); $r=`$e`; if($r =~ s/.*\n=== APIC (.*)\n.*/\1/m) { print "$f: $1\n"; }' > fancy_tags.txt

Monitor progress:

watch -n 45 "(wc -l fancy_tags.txt; echo; cat fancy_tags.txt|cut -d: -f4|cut -d, -f1|sort -u)"