DirViewer - show cover images from metadata

[xeruf]

Most of my FLAC and MP3 files have embedded cover images, but the dirViewer does not show them.

[sghpjuikit]

Not implemented. It can be done, but it is a little unusual. The cover belongs to the album, not song. I'll look into it, shoulnt be that hard. As for performance: cant promise anything.

[sghpjuikit]

Closing as delivered.

Implementation was indeed simple, although puts additional burden to the messy legacy code. Performance should be good unless the covers are really big. Unfortunately ImageCover.getImage(size: ImageSize) is not fully implemented, i.e., returns full image, thus higher memory consumption (as necessary) should be expected. Implementing that is out of scope.

I want to point out two things about this feature:

• album covers are album metadata. Not song metadata. They do not belong to song file. This applies to track count/disc count and similar fields as well, but they are textual and that means that 1 - performance/memory is not sacrificed, 2 - they can not be effectively put out of the song into the directory. Because cover is binary it adds quite an overhead to the file. 0.5MB cover in an album of 100 songs is 50MB in covers alone! For library of 50k songs, this would amount to 25GB. And its all duplicate data! There are problems with cover support in some tag specifications, cover reading support in libraries (jaudiotagger produces weird cover size values I think), cover reading/writing support in applications, taggers and browsers. There is a problem of syncing this content for all songs as well. It's complicating and worse performing than simple cover file in the album directory. That approach has a single disadvantage of when multiple album files reside in the same directory.

• displaying same cover image for the files is easily done using GridView's feature to display image's parent directory's cover image for all its content. Thus if cover.jpg resides in the directory, all child files that do not have a cover of their own will display cover of its parent. This is effectively fulfilling the requested feature in case song tag is not used to store the cover. And this is accomplished without reading the image more than once and storing it in memory more than once, thus achieving O(1) performance, like it should be.

I do think this feature should be implemented, but I also think covers do not belong into the tag, and the use case right here right now would benefit user tremendously. If he avoids using tag for covers, application would load single cover from a file instead of reading the same cover per every file. This is in user's hands. Something to consider.

PS: the features 'use parents cover' and 'display cover from tag' do not conflict. The tag has higher priority.

[xeruf]

1) This is your choice. Which album has 100 songs? I have quite a lot of singles with their own artwork, do you propose to put each Single in a folder with its artwork as a separate file? Doesn't sound sensible. 2) I don't see this behaviour in current master 3) Please stop "closing as delivered". Instead, use the fixes syntax in a commit message, that also associates commit and issue. Or, if you forgot it, do it like this:

Fixed by 899e1f00c2215f95763d7f18d2b3262cd51b48f5

Anyways, it looks great now :)

[sghpjuikit]

1 I have albums with 200+ songs. In fact 2000+, but that one is an exceptional case (rip). Well, I agree the solutions are trade-offs.

2 It appears it does not work when the parent directory is the root of the view. Fixed.