OK. It's clear. But maybe accepting animated gif covers for audio files could be a new feature? Is it possible?
Most media players only use jpg or png files for artwork. Some may also use bmp but not really recommended for full compatibility with the majority. None I am aware of will display a gif, so support by mp3tag would be irrelevant.
AFAIK the ID3 standard only supports jpg and png. So you are free to influence the ID3 folks to add other formats to the standard.
Windows Media Player plays animated gif.
And Media Player Classic even supports SRT Subtitles for animated gif.
Adding support for cover types outside of the ID3 spec could cause more troubles with many other players that do not support this.
Ah, but is the animated gif embedded in the music file or just in the right place so the player accesses it?
Has anyone tried APNG?
MP3Tag Add Cover adopts APNG yet only in PNG extension, but MP3Tag doesn't yet show any animations like to almost all commonly used image viewers. However the Internet browsers, especially the Firefox can show APNG animation.
Also IrfanView displays APNG animation too.
The Player plays animated gif as a video file. Can an animated gif be embedded in an audio file? It will be nice, if it can be embedded in an audio file and if it can be played by a player from inside of an audio file.
ā
However, the animation is a video feature, even if it is an animated gif or an animated png.
ā
An animated gif added to a mp3 file by MP3-Info app doesn't display any animation, and MP3Tag displays it as a still cover-image too.
Well, you are looking for a feature in mp3tag that applies to animated video that doesn't exist in mp3tag for non-animated jpg or png.
If you look at a music file in mp3tag that has a jpg "nearby", you will not see the jpg (unless that jpg is embedded inside the music file). In this case, some players might display the non-embedded jpg. Other players might retrieve an image from the interwebs. This is unique to each player.
I'm not sure that curing all of the ills of the world (of players) is in the purview of a program that deals with the standards of tags.
You can if you want. ![]()
In the options, remove the check-mark for "Don't display first image from file directory as cover art".

Yes, you are right. So sorry.
Symfonium has recently started supporting animated artwork. I cannot tell you how excited I am to integrate animated artwork into my library. Iāve been collecting them for a couple years now. Iāve been using the tags on my music files to have mp3tag sort my files. Iām unfortunately unable to add tags or embed gif files to tracks so Iām trying to think of any ways I can automate sorting the gif files as they need to be ācover.gifā within the folder of their respective albums to be read by the app. Any suggestions would be greatly appreciated. I donāt mind needing to manually organize the animated artworks especially considering I donāt have too many but If I can save myself time by thinking outside the box Iād be very happy.
See the action to export covers to file:
there you can set the filename to
(provided, it is a gif file, it will be saved as "cover.gif".
Thinking outside the box indeed. I was able to Embed a gif using the import action instead of trying to manually add it. Then I was able to export it as well Now I just need to see if keeping a Gif embedded will break my music app lol.
UPDATE.
Leaving the Gif embedded does prevent the animation from actually playing in my music player
I can however still use mp3tag to sort & name the Gif cover arts. My current workaround will be
- new tag field or prefix / suffix to an existing tag field I use so that I can denote when a track is utilizing animated artwork
- Whenever I use mp3tag to move or re-sort tracks with animated artwork I will use an action that will import the Gif cover art, re-locate the file & then export the Gif cover art to a new path relative to the the trackās new path
- Last step would be to delete the embedded Gif so that my player doesnāt just read the first still frame
This should keep me from loosing or misplacing animated artworks
Thinking outside the box indeed. I was able to Embed a gif using the import action instead of trying to manually add it. Then I was able to export it as well Now I just need to see if keeping a Gif embedded will break my music app lol.
UPDATE.
Leaving the Gif embedded does prevent the animation from actually playing in my music player
I can however still use mp3tag to sort & name the Gif cover arts. My current workaround will be
- new tag field or prefix / suffix to an existing tag field I use so that I can denote when a track is utilizing animated artwork
- Whenever I use mp3tag to move or re-sort tracks with animated artwork I will use an action that will import the Gif cover art, re-locate the file & then export the Gif cover art to a new path relative to the the trackās new path
- Last step would be to delete the embedded Gif so that my player doesnāt just read the first still frame
This should keep me from loosing or misplacing animated artworks
NEW, NEW Update (This May need a new thread)
The Symfonium update will allow users to embed GIF & WEBP images to support animated artwork within the app.
Currently in Mp3tag I canāt use the action āimport cover from fileā to import an animated webp, manually adding it with a right click on the current cover does work but there is no thumbnail present.
Inversely, Gifs can be embedded using the āimport cover from fileā action but cannot be added manually when right clicking on the current cover. (A thumbnail does appear for these)
I do think supporting GIF & WEBP in mp3tag is be beneficial especially as more players begin supporting animated artwork.
Iād love to be able to see a thumbnail & cover details when using an animated WEBP image. Iād also love to be able to import GIF & WEBP using either importing method just like the other static image formats.
Side Note
Iām currently not able to see the thumbnail on any animated WEBP on my PC so the lack of thumbnail may be a windows issue (I do have the WEBP image extension installed) So I'm not totally sure if / how I can fix that
Ah, so maybe mp3tag iās just not having it with the beefy file sizes, I tried another smaller one (6mb) same results
Iām using ffmpeg to convert an mp4 to a WEBP, they seem to look a bit better than GIF files is it possible a codec is incorrect? Iāf im honest just having a thumbnail there when Iām using a WEBP is good-nuff for me I just want to know whatās there
This is the tutorial I used (not at all an expert on ffmpeg)
ffmpeg -i input_filename.mp4 -vcodec libwebp -filter:v fps=fps=20 -lossless 1 -loop 0 -preset default -an -vsync 0 -s 800:800 output_filename.webp

