The storing of covers to audio files is not uniformly defined. Widely used are image files like "front.jpg" or "cover.jpg", if the tracks of an album are stored in a folder. Windows offers hidden files like "folder.jpg". Image data can also be stored directly in the metadata of the files. However, since this increases the memory requirements, some systems use an image database and store only an ID in the metadata.
Cover handling in the media library
Nemp tries to make the handling of covers efficient, and as far as possible without changes to the files. The basic concept looks like this
- For each title a cover is searched
- An ID is calculated from this cover
- The ID is stored in the media library, but not in the metadata of the audio file
- In the directory, in which Nemp stores settings and data, a (possibly) scaled down copy of the cover is stored with the ID as file name.
This allows a quick access to the images - even if the original image has been deleted or renamed, or if the external hard disk with the music collection is currently not connected.
If no cover could be found for a file at all, then a temporary cover ID is calculated from the directory name.
The search for covers takes into account image data in the metadata of the audio files as well as image files on the hard disk that appear to match the respective title. Other systems, such as cover IDs from Windows Media Player or iTunes, cannot be taken into account.
First, image data is searched for in the metadata. If there is a cover there, it will be used. If there are several (which can be the case with ID3 tags), the one marked as "Front Cover" is used, if available.
If no cover is found in the metadata, then the hard disk is searched for images " close to the audio file". From this list of images, the image that looks most like a front cover in terms of the file name is then picked. What exactly " close to" means can be specified in the settings dialog. The following search behavior is preset, which has proven to be very reliable in quite extensive tests.
- Search in the folder of the audio file
- Search in a subfolder with "cover" in the folder name
- Search in the parent folder (if there are not too many files/folders there)
- Search in a subfolder of the parent folder (neighbor folder) with "cover" in the folder name (if the parent folder does not contain too many files/folders)
The idea behind this are the following cases, where the matching image to the songs is found successfully.
Download cover from last.fm
If no cover is found for a song, then Nemp can search the Internet for a suitable cover. For this Nemp uses the API of last.fm, which is also used for scrobbling. However, no registration is required for the cover search - it just works like that.
To avoid repeating unsuccessful queries to last.fm all the time, the queries are cached. In case of a failure, the next query will be delayed for a while. The query interval for a particular cover will increase with repeated failure, until finally the query for it is stopped entirely. This cache can be cleared in the settings dialog under File Management.
Quality of the covers
Nemp stores the found covers reduced in size, if necessary, to save storage space and to reduce loading times. The quality (i.e. the maximum resolution) of these copies can be configured.
A maximum resolution does not necessarily mean best quality of the displayed images in the coverflow. Indeed, the (simple) OpenGL scaling function in the Coverflow is more prone to artifacts than the better quality scaling used when creating the image files for the media library.
Some notes on this:
- The change in quality level is not immediately visible, but only when the coverflow is rebuilt.
- The covers that are automatically downloaded from last.fm usually have a resolution of 300 × 300 pixels.
- After changing the quality setting, the covers must first be generated in the new resolution. This happens only when needed, when a cover is to be displayed in the coverflow.