Cover Art Anomaly After Upgrade to v3.24

I have been adding cover art to my .mp3s in v3.23. They worked perfectly and my cover art appeared in the .mp3 player on my desktop and in the .mp3 player on the website 'in the cloud' where I store my music.

Yesterday, I upgraded to v3.24. I created a new .mp3 in Ableton yesterday. I used v3.24 to add cover art to it. My cover art (front cover) displays correctly in MP3Tag v.3.24, but when I save the .mp3 and attempt to play it in either the .mp3 player on my desktop, or in the .mp3 player on my 'cloud' site (Mega), the cover art does not display.

Suggestions?

Load the files and then check:
Is the cover really embedded?
Use a filter with
%_covers% MISSING
to see files without embedded cover.

With the directory containing the .mp3 I created yesterday displayed in MP3tag, I employed the filter you suggested. The filter returned 15 files with Missing covers. The file that is giving me the problem was not among them. The directory contains 42 files. So, the majority of the files appear to have embedded cover art and these would seem to include the one created yesterday.

Are there other cover art parameters that I can adjust that might render the invisible art visible in my players?

I would make first make sure that all the files really have embedded covers. This would rule out one possible cause.
Next would be to check if there is a difference between the files that show covers on the players and those that don't, e.g. does one particular cover show in one file but the same does not in other files?
If the covers are different: what format do they have? png? jpg? bmp? etc..?
if they are jpg and some show and others don't: are those that don't show in progressive mode?
And if that turns out to be without anything peculiar: how does the player treat changes? Is there a database or a cover cache that needs updating?

You may have noticed: as soon as the picture is really embedded, most of the other tweaks are outside of the controle of MP3tag - but are features that have to be tested with the player.

Thank you for your kind assistance. I am inclined, at this point, to think my problem arose from 'operator error.' My mistake. I think I have discovered my solution.

Can you share the solution so others may have the benefit from learning from your experience?

At the risk of making myself appear to be the grandest of idiots?

Oh, very well! When you add cover art to your .mp3s, be certain that you have chosen the .mp3 and not the similarly named .wav file which you rendered at the same time. The .wav file will likely play in your media player, and the cover art will not display. Unless your ears are subtle, you will not notice the difference in audio quality and you will place blame on some innocent software developer. Also, if your eyesight is poor and you are on the wait-list for cataract surgery, wear you glasses at the computer because it will help you see file extensions. Lastly, look occasionally at your 'tag' field, if you see: RIFF where all your other .mp3s have ID3v1, know that you messed this up yourself.

1 Like

An innocent mistake. The more important part was finding the error. Often WAV is not supported as widely as other formats when it comes to metadata and cover art. With several lossless formats available like FLAC or ALAC that do have great tag options, there are less reasons to keep the uncompressed WAV files in most cases.