Prioritize own ID3 cover art

[Matthieu-LAURENT39]

Is your improvement request related to a problem? Please describe. Most of my songs aren't parts of any album as they are just singles. All of them are MP3s with a cover image embedded into them as an ID3 tag. But in the app, most of the songs use the cover art of other songs in the same folder (sometimes even from a different artist) instead of their own embedded cover.

Describe the solution you'd like Songs should prioritize using their own ID3 cover art if they have one, and only fall back to another song's cover art if they don't have one themselves.

Describe alternatives you've considered Having every single of my song be in a different album, but that turns my collection into a massive mess.

Additional context I'm not sure this qualify as a bug, as it's the behavior of most music players. That's why i set it to "improvement request" instead.

[moritz-weber]

Ok, this is a case, that I have not considered...

Do these songs have an album tag? If they all get assigned to the same album, what should the cover look like for this collection in your opinion?

The idea right now is that songs from the same album use the same cover image. The image is obtained from the ID3 tag of the first song of the album that is being scanned. The folder shouldn't have anything to do with that. Handling every song individually could dramatically increase the time it takes to scan the library if we implement it for our current approach. So, this is not an easy fix...

[Matthieu-LAURENT39]

These songs don't have an album tag, so they all get added to albums called "Unknown Album". For some reason there are multiple such albums of various size, all with mix of different artists. For that kind of fallback album, maybe a placeholder cover with a ... or ? could be good, as having the cover of one arbitrary song is confusing.

As for the speed concerns, maybe you could have an option to do an "in-depth" scan that is slower but scans every song, and keep the current scanning method as the default faster option

[moritz-weber]

Thanks for clarifying. Albums are identified by their title (null in your case), artist name, and year. So, I'm not sure how these 'albums' with different artists are created.

Could you upload a few screenshots of these albums so I can get a better understanding of the problem?

With the recent progress in scanning performance, I think we can implement this as the default to keep it simple for users.

[Matthieu-LAURENT39]

Here is an example of an album

[moritz-weber]

Thank you for the quick response. I'm still not sure about the reason for this. Maybe we make an error when differentiating between artist and album artist.

I just remembered that we now have the possibility to export the whole database. Could you send me an export file of your database? You can create it in the settings and it should be written to your downloads folder.

[Matthieu-LAURENT39]

Of course, although i would rather not send it publicly Do you have an email i could send it to?

[moritz-weber]

Sure, I understand that. You can send it to dev@mucke.rocks

[Matthieu-LAURENT39]

Sent!

[moritz-weber]

Thanks, I think I now understand how these weird albums are created:

• Albums are differentiated by the 'album artist' tag, which is probably empty in your case.
• Thus: No title, no artist, just the year to identify an album.
• However: An album is created using the 'artist' tag as a fallback. So an album will have a specific artist but can contain songs by different artists.

This should already be solved in our current builds. If you like, you can try the build from this commit: https://github.com/moritz-weber/mucke/actions/runs/5985426939

This does not solve the cover issue, but your library should make a bit more sense like that.

[Matthieu-LAURENT39]

Yes, now albums are by artist, much better indeed! Although, i noticed that some artists still get multiple albums

Edit: I figured it out, it's one album per year. A bit confusing, but makes sense