[X] remove cover does not remove the tag field COVERART


i passed one year to search where that problem came from in my music manager (helium music)

When a mp3 file came with the tag "COVERART" (see in id3 tag from windows properties), my music manager software fails and crashed whereas i always use mptag to clean my tags.

but, i just discover now why.

The feature "remove cover" of mp3tag forgets to remove the field COVERART (and another one i can't see the name, sorry)

here a screen capture of a mp3 properties where i just used the "remove cover" feature :

Even, when i upload a new cover art album with mp3tag, this two fields are not updated , why ?

thanks for help please.
Best regards


How do you delete a cover?
The easiest way to do it is to select the files and right-click on the cover in the tag panel and select "Delete cover" and save the modification.
The other field that your program shows is the cover_mime_type which shows the type of an embedded cover.
It is a little puzzling that your program shows the binary of a picture as characters.

i do exactly like you said.

The other fields should be removed too when i saven my modification! But mp3tag let them there ! that is the problem ! i don't want them!

i am not the one who put that fields (i guess it is the plateform where i buy the digital). Because they contains a 600x600 cover art album, i always remove the original cover (with mp3tag) and replace them by my own 1000x1000 that i reupload into the mp3 (using mp3tag too).
Even when i upload it, mp3tag forget to update then (even i'd prefer it will erase them and only keep the normal picture inside the tag).

for me it is a bug that mp3tag forget to take in charge of them while i delete the cover or i update it. if you want, i can send you a exemple of such mp3.

i did a test, i just try to remove the old original one (which was a jpeg embeded picture) and upload a PNG new one.

look at it, mp3tag forget to update the fields ! but it got my PNG file into.
so , the bug is produced!

If MP3tag apparently does not delete tags then you should check which tags you let Mp3tag read, write and delete.
The proper setting would be: read and delete all, write only V1 and V2.
Esp. APE tags are a problem.
If you have these in a file, get rid of them.

If this is not the case, check the file's integrity with mp3val and/or mp3diags.

Go ahead.

here is a trim (3 seconds) of a file with that kind of problem


You have 2 tag-fields (coverart and covertartmime) in your mp3.
As far that I know these tags belong to OggVorbis.
Maybe an orginal Ogg-file was recoded as mp3 and the tags were taken from these ogg-file.
The cover-file you see in Mp3Tag has nothing to do with theses tag-fields.

As you have a mp3 now you don't need these tags.
Just take the extended tag-menue in MP3Tag (ALT-t) and delete these tags.

But because you mention a crash from your player:
I noticed that your embedded cover has xmp-metadata.
Till now I had no such experience but I heard that some players may have problems with metadata in embedded pictures. Perhaps you should strip the pictures from metadata before you embed them in the mp3-file with Mp3Tag.

You only have V1 and V2 fields in the files. That is good.

You have several user-defined fields in the file
TXXX/COVERART which is shown as COVERART in MP3tag extended tags
TXXX/COVERARTMIME which is shown as COVERARTMIMETYPE in MP3tag extended tags

These fields have nothing to do with embedded covers and their mime type.
Additionally you have a cover APIC with the size 2034250 and the status cover. This represents the actually embedded picture.

The user-defined fields do not get deleted if you remove the cover - which is perfectly possible with MP3tag. Also, these fields do not get updated as they have nothing to do with the embedded picture.

So: whatever software wrote these 2 fields I don't know but I would say that they are absolutely superfluous. You can delete them.

To sum it up: I can see no bug for MP3tag.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.