Copy cover to new MP3 bug?


#1

I think I may have noticed a bug when it comes to copying a cover from an existing MP3 with tags to a new untagged MP3 when using the Copy Cover command.

Sometimes I will need to add or replace an MP3 in one of my own albums, but I find that when copying a cover from another file already in the album, and then pasting it to the new file and saving, it appears to work but then when all files in the album are selected, the cover preview goes blank and says "cover varies".

I found a way of solving the problem by extracting the cover from a file in the album to folder.jpg, and then adding that to the new file - then it works, the cover doesn't vary in the album at all.

At all times, it is just the one cover image in all the files.

I don't know if it's a bug, but since last night I've discovered another way to copy all tags over to replacement MP3s, and that works as well, so it maybe doesn't matter. But I just thought you ought to know.


#2

When you get this message from Mp3tag, you can be sure, that there is at least one file in the selected set of target files, which have different picture properties than the other selected files, ...
or there is a picture missing or there is already some picture in one or more of the target files.
The picture status "cover varies" indicates, that the selected files have not the same status about their embedded pictures. You should check each related file.
A listview column named "Covers", value %_covers%, can help.

DD.20140523.1105.CEST, DD.20140523.1336.CEST


#3

Surely if I copy a cover (out of 1) from an older file, and paste it to a new MP3 with no cover, then it should be the same?


#4

I am not so sure if the way via the clipboard does not convert any compressed graphic to an uncompressed one (bmp) so it could be that this conversion modifies the size.
The way with export/import is generally the favoured one.


#5

I discovered that copying and pasting all tags from one MP3 to another (because I'm replacing old MP3s) seems to work better as well, but isn't the clipboard involved as well?


#6

Yes and no.
When copying complete tags, a special clipboard is used that is owned exclusively by MP3tag.
You can check this if you first copy a text to the (windows) clipboard and then a complete tag with the "Copy tag" function.
If you press Ctrl-V you will get the text and not the tag, although the tag should have overwritten the clipboard contents as you copied that later.


#7

I'm not sure I understand that last bit.

What I read on this board (after googling it) was that if I selected an MP3 in the main window and did Ctrl-C, I could then select the new MP3 and Ctrl-V, and a dialogue would come up confirming that I wanted to copy the tags over, and it worked. That's all I meant. BTW, it has made life much simpler when replacing MP3s, as in the past I've have to type in all the fields again.


#8

Yes, from my experience.

DD.20140523.1338.CEST

Hm ... but maybe no.
Mp3tag not keeping cover size while copying

DD.20140524.0735.CEST


#9

Thanks for the update. Wow, so it's not a bug, but a Windows peculiarity. Oh well, looks like Extract and Add is the way to go.


#10

Hm ... copy one picture to Windows Clipboard and paste it back into the selected files ... should also work.
Possibly the saved picture will get differences in size and encoding, when exported to disk file, in relation to an already existing picture file on disk.

DD.20140525.1406.CEST