Unexpected behavior with .mp3 icons

[sybersitizen]

I saw a warning in the Dashboard today that I had three files without thumbnails. They are three .mp3 files in a folder that was scanned by IMatch for the first time a few days ago. These files have normal full size generic icons when viewed in File Explorer, but only tiny icons appear for them in IMatch. Video files in that folder have no display issues.

I have one other .mp3 file in a different folder that was scanned many months ago. IMatch shows the full size generic icon for that one. As a test, I copied that file, renamed it, and put the copied file in the folder with the 'problem' files. IMatch shows only the tiny generic icon for it as well, and the count for files without thumbnails in the Dashboard increased to four.

That newly scanned file also appears in the Dashboard under Session Statistics as a file with indexing problems and a file without date.

I conclude that something different is happening now when .mp3 files are scanned compared to what happened in earlier versions, and it seems like a bug.

[Mario]

If the MP3 library in IMatch cannot find a supported cover image in your MP3 files, IMatch falls back to the default icon provided by Windows (usually the icon of the application associated with MP3 on your system).

Looking at the 100+ sample MP3 files in my test file library, they all show proper thumbnails / album covers in the Viewer.

You can try embedding a new cover image in your MP3 files, with suitable software. I don't remember anymore which software was used back in the day to add album info and cover images to MP3 files, sorry. That was a decade ago. Windows Media Player?

Be careful when downloading MP3-related software. Many of the apps out there are malware these days.

[axel.hennig]

I conclude that something different is happening now when .mp3 files are scanned compared to what happened in earlier versions, and it seems like a bug.

Can you upload one of the "problematic" mp3-files to your cloud and share the download-link here? I would like to test this with my current IMatch version (2025.5.2).

[Mario]

I've added a folder with a dozen MP3 files to a database and all show thumbnail and previews in the Viewer. The size of the covers in the Viewer varies a bit, depending on the size of the cover image in the MP3. So, looks OK here.

IMatch uses ExifTool to extract cover images / previews for MP3 files. I removed the very old MP3 component in October 2024 in commit 43bcaa7f583d1f0346f601f0590bab335929d05d and switched to using ExifTool. Less dependencies and ExifTool does a good job.

If you have a MP3 file that fails to produce a thumbnail, attach it or send it to support email address so I can have a look at the ExifTool output.

[sybersitizen]

Okay, three things:

1) The .mp3 files have no embedded thumbnails, which is fine. I only want the generic ones.

2) An old file whose icon is large in an old folder that was scanned well over a year ago displays a tiny icon instead when I copied it and placed in the new folder and scanned it yesterday. The two files in the attached image are identical except for the filename. The left one is in the old folder; the right one is in the new folder. This file was an export from ACID Music Studio.

3) All icons display normally as expected in File Explorer.

Here is the file for downloading:

https://drive.google.com/file/d/1WdEeV-KjYRYZG71otLTA7d5N9dPp2uWe/view?usp=sharing

You cannot view this attachment.

Does anyone else have two different types of generic icons displayed for some .mp3 files?

Another thing:

This 'new' folder that contains some video and audio files is not really new at all. It should have been in my collection for years, though I have had no reason to ever look to see if IMatch had scanned it. However, IMatch apparently added it to the database for the first time a few days ago, and flagged its contents as new files. That's something else I don't understand. It's possible that it was not in the collection where I thought it was, and that I somehow copied it there a few days ago from a backup source, though I certainly didn't do so consciously. Is it reasonable for IMatch to miss a folder for such a long period of time and then discover it later (and have problems with .mp3 files)?

[axel.hennig]

2) An old file whose icon is large in an old folder that was scanned well over a year ago displays a tiny icon instead when I copied it and placed in the new folder and scanned it yesterday.

Does anyone else have two different types of generic icons displayed for some .mp3 files?

Now, I think I've understood.

Did you maybe change the setting for thumbnail creation? E.g. from 800px to 100px or something like this?

EDIT: Just double-checked and the setting "Edit > Preferences > Database > Thumbnail Size" does not change the size of the icon. I've changed the setting from 160px to 1200px and "force re-scanned" the mp3-file... nothing changed.

[Mario]

EDIT: Just double-checked and the setting "Edit > Preferences > Database > Thumbnail Size" does not change the size of the icon. I've changed the setting from 160px to 1200px and "force re-scanned" the mp3-file... nothing changed.

The size of the thumbnail / preview image IMatch can use depends on the size of the cover file / preview in the MP3. The process is designed to find the largest cover / thumbnail and use it. And the size can vary from MP3 to MP3, when I recall.

[sybersitizen]

It occurs to me that I could go back to a recently saved version of the database (saved using Pack & Go) that I think did not include this 'new' folder. Then I could save the log file to examine the issues that it finds when it's scanned. If I want to do that, what's the exact process? I believe the recommendation is to unpack to a different folder and tell IMatch to use that one. Anything else?

[Mario]

I don't follow what you want to do.

I have downloaded the MP3 file.
It seems to have no embedded cover image / album art / preview? 
Windows Explorer shows no thumbnail / album art, IMatch shows no thumbnail, VLC shows none, Windows media player shows no album art, ExifTool does not report any preview in the file.

When no preview can be found, IMatch displays the icon of the associated application. On my PC that's the VLC logo, on you PC Windows Media or something. 

Looks like IMatch is right. No cover art in that MP4 file.

[axel.hennig]

I think the question is not about the thumbnail (there is no thumbnail) the questions is about the icon.

Why is the one icon in the screenshot above so small compared to the other one. And both files are mp3, so associated with the same application.

[sybersitizen]

I don't follow what you want to do.

Looks like IMatch is right. No cover art in that MP4 file.

You don't understand ... as I said, there is no cover art, and I'm not looking for cover art. I'm looking for a normal large generic icon instead of a tiny generic icon - I've used the word 'icon' many times. I can't describe or illustrate the issue any better than I already have.

I'm looking for some way to make IMatch treat that duplicated file in the same way it treated it more than a year ago so it shows a large icon and does not tell me there's some kind of error with the file.

[sybersitizen]

I think the question is not about the thumbnail (there is no thumbnail) the questions is about the icon.

Why is the one icon in the screenshot above so small compared to the other one. And both files are mp3, so associated with the same application.

And why are problems found with any .mp3 file that's newly scanned? When I duplicate the old file that displays the correct large icon, and IMatch scans that duplicate file, it finds an error in addition to only displaying a small icon instead of a large one:

You cannot view this attachment.

Hovering over the 'I' icon shows this message:

Files without usable metadata.
IMatch uses a file system timestamp for File.DateTime.

ExifTool GUI shows me the following metadata - so what do I need to do to fix the date problem?

---- ExifTool ----
ExifTool Version Number         : 13.19
---- File ----
File Name                       : Lisa B-Day Project Music - Copy.mp3
Directory                       : .
File Size                       : 5.8 MB
Zone Identifier                 : Exists
File Modification Date/Time     : 2018:10:16 18:42:27-07:00
File Access Date/Time           : 2025:09:19 11:10:59-07:00
File Creation Date/Time         : 2025:09:19 11:10:59-07:00
File Permissions                : -rw-rw-rw-
File Type                       : MP3
File Type Extension             : mp3
MIME Type                       : audio/mpeg
---- MPEG ----
MPEG Audio Version              : 1
Audio Layer                     : 3
Audio Bitrate                   : 160 kbps
Sample Rate                     : 48000
Channel Mode                    : Joint Stereo
MS Stereo                       : On
Intensity Stereo                : Off
Copyright Flag                  : False
Original Media                  : True
Emphasis                        : None
Encoder                         : LAME3.98r
Lame VBR Quality                : 4
Lame Quality                    : 2
Lame Method                     : CBR
Lame Low Pass Filter            : 17.5 kHz
Lame Bitrate                    : 160 kbps
Lame Stereo Mode                : Joint Stereo
---- Composite ----
Duration                        : 0:04:51 (approx)

Even that .txt file that I placed next to the .mp3 file is flagged by IMatch as having a date problem. Is there an explanation?

[Mario]

If the text file is empty, ExifTool will report a warning when trying to read it. So this is normal.
So it's the last resort fallback icon that is now smaller than before. Got it.

When ExifTool fails to extract a cover image, IMatch will fall back to ShellExtractIconEx, requesting a "large" icon for the file. The large icon size depends on the Windows version and the application associated with the file format. When it was MediaPlayer before and it is now on your system, I don't see why the icon is smaller. I will look into this for one of the next releases.

[sybersitizen]

If the text file is empty, ExifTool will report a warning when trying to read it. So this is normal.

Not sure what you mean by empty. The text file has text in it. I have many text files, and all display the tiny icon, so I guess that's as expected. Do you mean the date tag that IMatch wants to see is empty? Most or all of those files were made by me with Notepad.

When ExifTool fails to extract a cover image [for a .mp3 file], IMatch will fall back to ShellExtractIconEx, requesting a "large" icon for the file. The large icon size depends on the Windows version and the application associated with the file format. When it was MediaPlayer before and it is now on your system, I don't see why the icon is smaller.

To be exact, my default player has always been the old Windows Media Player for years, and it still is.

I will look into this for one of the next releases.

Great, thanks! Any ideas about why newly scanned .mp3 files and .txt files are also being flagged with a date error? Maybe they always were and I just never noticed. I think that notification only appears in the Dashboard Session Statistics, which gets cleared when IMatch closes.

[Mario]

That's not a date error. IMatch just tells you that it could not find any usable date in the metadata of these files and that it had to fall-back to using the "last modified on disk" file system date. Which is usually OK for simple text files, or not, in which case you just assign a date in the Metadata Panel, and the "error" is removed.

This not only happens with text files, but also with image files which have no usable date and time in metadata.
It's just IMatch helping you to identify files which may not show up in the Timeline View or the Event View in the spot you'd expect. They may also sort "wrong", if the last modified date on disk is not the date you would consider for these files.

Dashboard help: Files Without Date

[Mario]

I have fixed this issue for the next release. See https://www.photools.com/release-notes/.

[sybersitizen]

I'm glad that was an easy fix, and that the date issue is just normal behavior.

I'm still left wondering why IMatch only 'discovered' that particular folder a few days ago, which alerted me to these other things. I checked older backups of my collection, and it has been there all along, so I don't know why it suddenly showed up as a new folder on the 16th.

I guess there's no action to take unless something similar happens again.