|
|
Peke, can you update this bug with more detail?
- Is Album Art lookup enabled?
- Did the tracks with the incorrect artwork have unsaved artwork?
- Does it occur in all Preview window layouts?
- Does it occur when Preview is in Playing and Selected modes?
My guess is that you're just observing unsaved artwork (artwork that has been looked up but not saved), in which case the only issue is that the 'Save' icon should appear on the image (as it does with Preview [Advanced]). |
|
|
|
It is clearly seen on my video and screenshot:
- No lookup is enabled (No save icon) and if I start lookup that image is not suggested
- Also video shows that affected track do not have any artwork, saved or unsaved, changing tracks in video shows that default image is correctly shown.
- Art and details is affected not other nodes.
- Both screenshot and video shows that it is related to playing track.
|
|
|
|
Your video shows testing of the Preview [Artwork] view, but you need to look at the track's Properties OR Preview [Advanced] in order to see the status of the Album Art (since all other preview windows will just display unsaved artwork within indicating that it's unsaved. The only bugs that I'm able to replicate are:
1) There's no 'Save' icon for unsaved artwork in Preview [Artwork only, Basic, Side by Side] . This makes the artwork's status somewhat unclear an all Preview modes except Preview [Advanced].
2) Deleting an image that is 'unsaved' has no effect i.e. it doesn't actually remove the 'Unsaved image' from the image cache. e.g.
0 Enable Tools > Options > Metadata lookup > Background metadata lookup (Artist images, Artwork, Lyrics)
1 Click a track that has no image in the tracklist, but that shows artwork in the Preview [Advanced] window
2 For the track in question, go to Properties > Artwork and verify the status of the image (it should show 'unsaved image'
3 In Properties, right-click on the image and Remove the image
--> a) the image is removed in Properties > Artwork, but remains in Preview:Selected [Advanced]! The two should be in sync!
--> b) even after revisiting Properties > Artwork, the image is missing! The image should have re-appeared because artwork lookup is enabled!
4 Disable Tools > Options > Metadata lookup > Background metadata lookup (Artist images, Artwork, Lyrics)
5 Click a track that has no image in the tracklist, but that shows artwork in the Preview [Advanced] window
6 For the track in question, go to Properties > Artwork and verify the status of the image (it should show 'unsaved image')
7 In Properties, right-click on the image and Remove the image
-->The image disappears from both the Preview:Selected [Advanced] and Properties > Artwork windows (as expected).
Those are the issues that I'm seeing. Without a full bug report from you, it's hard to understand exactly what you're reporting / how to replicate it. |
|
|
|
Note: my comments at 0016473:0057442 have been moved to a new bug.
The revised bug description as re-written by Peke doesn't seem to be a bug to me. i.e. in most cases it's the desired behavior. To elaborate, it might not be the desired behavior in the case of a multi-artist album that happens to have different artwork for each track, but the only alternative would be to show no art at all in such cases, and that would seem to be a worse approach in the majority of cases of multi-artist albums. |
|
|
rusty
2020-04-03 05:48
administrator
~0057471
Last edited: 2020-04-03 06:00
|
To summarize, there are a few related issues here re. MM's approach of using the artwork from the first track as a source of 'default artwork' in the case of multiple-artist albums that have tracks with missing artwork:
1) The artwork from the first track is specific to the first track, but is used to represent the Album in Albums view even though it's not necessarily representative. What should happen in cases (where Artist |= Album Artist AND multiple tracks have different artwork), rather than applying the artwork from the first track automatically to represent the album:
a) Look up an image for the Album based on the Album Name + Album Artist (if enabled). I think that this should be possible since this is what normally happens when initiating a 'Lookup image' operation for a track. In fact, deleting Album art from the first track of such a compilation album (with 'Apply to all files in the Album/Series' disabled), causes the correct newly looked up art to be applied as unsaved art to all tracks on the album that are missing artwork.
b) OR Generate a collage based on the artwork contained in the various tracks within the album (if lookup isn't enabled)
2) For such albums (where Artist |= Album Artist AND multiple tracks have different artwork), the current approach of automatically applying the artwork from the first track to other tracks on the album that are missing artwork isn't a good one as it can result in completely wrong artwork. It would be preferable to use the same approach as in the first case.
3) Currently, Album Art has an attribute re. the type of image being stored (e.g. Cover (front) or Artist). I'm not sure if these are tagged Attributes and/or whether they're standardized, but would it make sense to add an attribute for 'Cover (Compilation)' or 'Cover (Track)'? This could be used to help independently store Album Cover for the track vs Album Cover for the Compilation Album.
4) If we implement 3) at some point, the user would need to have a means of mass tagging an Album Cover without losing Track covers. One possible way of doing so would be to treat them as independent fields (with independent checkboxes). e.g.
Properties > Artwork
---------------------
[ ] Compilation Image
. . [Image] Image Type _Cover (Compilation)_ [Lookup]
[ ] Images
. . [Image1] Image Type _Cover (Front)_v
. . [Image1] Image Type _Cover (Front)_v [Lookup]
[ ] Apply to all files in the Album/Series
This would allow users to apply one image type ('Compilation Image') without affecting the other Types.
Assigning to Michal for feedback/triage. I'm hoping that 1a/2 may be reasonable for 5.0 (3/4 are more for the future, but I wanted to document those thoughts since it was brought up by Peke).
|
|
|
|
1) but even compilation albums have some common cover, cover type "Cover (front)" is meant to be mainly front cover of this whole album, compilation album or "ordinary" album. We cannot recognize, when it is related to only one track, and when to whole compilation album. It is also very hard to recognize, that artworks in tracks are really different and not only e.g. different scans of the same cover, so detecting whether images are different is not easy and even if it would be somehow done, it would significantly slow down searching for cover of one album (as it would need to go through all tracks and compare all images, to find out, whether the image could be used). The same problem is for collage, it would be very slow and could lead to display collage of several scans of the same image... Implementing 1a) would cause, that wrong image could be found and displayed, even though album has correct image set for his first track, it would look like clear bug...
2) the same problem... e.g. I have some compilation albums with correctly set common artwork, I want to display this artwork, not some newly searched one...
3,4) they are standardized, it is based on standard MP3 picture types, it does not include special type for compilation: http://id3.org/id3v2.3.0#Attached_picture |
|
