Cover image not displayed in some cases

[JustToby22]

I have noticed that when playing some of my audio files the album cover isn't displayed. After some fiddling I'm pretty sure this affects files where the covers don't have a 1:1 aspect ratio. Tested with FLAC and MP3.

Steps to reproduce: Ripped CD and added image (500x488p) on Linux using EasyTag (EasyTag categorises the image as "Cover (front)"), send over to smartphone, rescan library, open song. Album art not displayed.

Fix: Resized image to 488x488 pixels, added using EasyTag, sent to smartphone, rescanned library. Cover art displays correctly.

I'm running Mucke v1.1.0 on a Fairphone 4 eith Android 12 stock.

[moritz-weber]

Thanks for your report. I have a few albums in my library that have different aspect ratios and show up just fine (just cropped to 1:1). Thus, I'm pretty confident that the aspect ratio is not an issue.

BTW I'm using the same hardware and software, so you should get the best possible support ;)

[JustToby22]

A fellow Fairphone user, Nice! Interesting it's not the aspect ratio that's the problem, though I seem to just not have tested it enough. If it helps, I'll send the two files from my example. Maybe that can help diagnose the issue. Original: Resized:

Also, here is another album cover that doesn't show up in the app. I haven't tried to resize this one yet for lack of time.

[moritz-weber]

Just tried both original files without any problems. I just set them as cover images for some random songs with MusicBrainz Picard:

[JustToby22]

Very interesting. I've been testing a bit with using different encodings for the metadata and switching between ID3v2.3 and v2.4 but no luck so far. Would it be possible for me to send you one of the audio files, maybe? I'm not sure what the guidelines say about sending media files like music.

[moritz-weber]

You can send me the file via e-mail at dev@mucke.rocks

[moritz-weber]

Even using the same MP3 files, the problem could not be recreated. It seems to be a problem with the metadata plugin, but it is unclear, what causes this issue.

[moritz-weber]

@JustToby22 there is currently a new implementation of the metadata reader in testing. Could you try out the new build and let me know if this fixes your issue?

https://drive.google.com/file/d/1V1NI5stTFjQdtnyaKv4tX9umyiTCETZc/view?usp=sharing

[JustToby22]

This fixes the issue, indeed. Funnily enough, it breaks some other covers at the same time. So far I've only noticed the covers of the Half Life games' soundtracks missing, though.

[Knusper]

OK... I just updated to 1.4.0 and now I also experiences missing covers.. I cleared the cache and storage... Reinstalled, and scanned the library... Now all the covers that were not in the ID3 tags but as JPGs or PNGs within the folders of the albums are gone.

[moritz-weber]

Yeah, that makes sense. With the new metadata reader, we just read the music files. I wasn't aware that the previous scanner also scanned for image files in the folders. The problem shouldn't be too hard to fix, but I can't make any promises about when I have time to work on this. Sorry for the inconvenience.

[Knusper]

Ah .. no worries... I revert to the previous version for full cover glory in the meantime ... thanks for this app!

[moritz-weber]

I wrote a quick fix for this. Would you mind trying this build (Google Drive)?

This just grabs the first jpg or png file it finds in the album folder and uses it as the cover (if there is no image in the meta data).

[jdg2011]

I've tested the build linked above, and it solved my original problem of new album art not being imported in version 1.4.

However, in my music collection I have a mix of album art that I named "cover.jpg" and art that was auto-downloaded with another tool where the art has names like "AlbumArt_{B5020207-474E-4720-A6EC-E32AD8402400}_Large.jpg". In other versions of mucke, including 1.4, those images with the longer names got imported, but not in this build.

[FriederHannenheim]

The root cause of this is probably that images specified as paths in id3 tags are not automatically parsed by the new system. I will modify metadata_god to do that soon. This should be fixed after that

[moritz-weber]

In the current fix, mucke just scans the folder for images (if there is no cover in the tags) and uses the first one it finds as the album cover. Is the problem that you would prefer the auto-downloaded images over the cover.jpg files?

I can't really imagine that 1.4 imported those images, since I just added the following lines to the scanning process:

if (albumArt == null) {
  // get directory of song and look for image files
  final images = await songFile.parent
      .list(recursive: false, followLinks: false)
      .where((item) =>
          FileSystemEntity.isFileSync(item.path) &&
          IMAGE_EXTENSIONS.contains(p.extension(item.path).toLowerCase().substring(1)))
      .asyncMap((item) => File(item.path))
      .toList();
  if (images.isNotEmpty) albumArt = images.first.readAsBytesSync();
}

[moritz-weber]

@Valotio @chris-blues, would you be so kind to test the current build for this branch? I'm asking you because you now have quite some experience with testing builds, and you have some extensive libraries that are just good test scenarios :smile:

This new build just looks for image files in the song folder, if the song file itself does not contain a cover image.

@jdg2011 could you also test this and clarify what the problem with the auto-downloaded images is exactly?

[chris-blues]

Impressive! This scan took about 4 minutes. All seems well! Sorry, I couldn't find any logs though...

[Valotio]

For me it worked perfectly. The scanning of 4669 Songs took about 20 Seconds. Logfile is as always placed in /storage/emulated/0/Android/data/rocks.mucke.dev Good Job, bye