When I add additional art work to multiple files (whole albums) to files it replaces what's there.
If I do this with one file at a time, it adds the art work.
It's the same whether I drag the additional art work or right click and paste. Why the difference?
Creating an Action group for each album seems to be very slow way of doing this, having to change the path for each album.
Is there a faster way to do this?
I can confirm this (for me unexpected) behaviour.
If you drag & drop a picture to 1 single music file, it will be added - for example as second cover art picture.
If your drag & drop a picture to more than 1 selected file, ALL existing covers will be replaced in all files.
There seems no way to change the + sign or mode during d&d.
Any ideas from other users?
The problem arises if the covers vary.
If you already have the same picture (e.g. the cover) in the selected files and now add or drag&drop another picture, then the new picture is added to the existing ones.
It does not work, if the already embedded picture varies in the selected files.
I have to admit that I find that strange, too.
You are right.
If all selected tracks have no cover at all or the same cover picture embedded, you can add a new picture by drag & drop to all of them.
Some kind of default + (=add new cover to all selected files) or pressing the Shift-Key during drag&drop to replace the various covers would be more convenient.
It is a little irritating that a little + appears at the bottom corner of the dragged image even though it does not add that image to the existing varying picture.
I think we need a comment from @Florian
Glad it wasn't me being silly, missing something obvious.
Over to @Florian
Since Mp3tag v3.27 we have the "Replace Cover" function in the right-click contextual menu on the cover window.
IMHO the current drag & drop behaviour (showing the + sign) should ADD the d&d-picture to all selected files, not replace.
Maybe the default behaviour should be "replace cover", but then not show the + sign.
Pressing the Ctrl-key during drag & drop could change the mode showing a + sign and ADD the picture.
In the same way as adding files. Gets my vote.
Thanks to this thread I learned a new feature that I did not know. 
Is it described anywhere, was this invented sometime and I missed it?
If you drag & drop a cover-file with CTRL-pressed, the existing embedded image (even if there are several) that is currently displayed will be replaced, even if there are several images.
I store the album art in each album folder, and use syntax that allows for a single action to embed the art. I'm curious about your work flow in this regard.
Sharing that syntax would have been useful!
Anyway, I've slept on this one over night and came up with "%_folderpath%*.jpg" in my import cover art action group. This works with all 350 folders in one go.
I copied the artwork into each folder. The folder only has this one piece of art work. This saves having to rename them, too. And it will pickup the only file there. But, if there is more than one jpg in the folder it seems to pick the first one numerically, alphabetically (i think!).
Personally I don't use artwork, but I've been tasked with this job to do for a friend. It's now done.
I was not near my PC when I posted so I couldn't remember the actual syntax, but it would depend on how you store your artwork. I keep them in the folder with the name %album% - Front.* and that's what I use in the action. But it won't be much use if you have a dedicated artwork folder, as some do, and it would require renaming the image to the indicated format.
Sounds like you have it figured out though. I have been fine without artwork for a couple decades but a few recent changes illustrated that it would be nice to have, so I've been working on updating my collection. Be careful, you might decide the same! And then you'll have a new hobby 
like me.
@reason, @confucius
Please note that the problem does not arise in actions but if you try to add pictures with GUI functions and a set of files in which the already existing picture varies.
@ohrenkino
Yes that was noted.
I did a small test with some files and selecting all the files loaded...
This was enough testing for my purposes.
@Reason You're forgiven!
I haven't forgotten about this — it was just a lot of work to change the existing implementation 
I've just released Mp3tag v3.29c with the following changes:
- NEW: added support for adding covers to files with varying covers via drag and drop at Tag Panel and Extended Tags.
- NEW: added support for adding covers to files with varying covers at Tag Panel and Extended Tags.
- NEW: added support for replacing covers in files with varying covers at Tag Panel and Extended Tags.
- FIX: drag and drop effect reflects adding of covers to files with varying covers at Tag Panel and Extended Tags if Ctrl key is pressed.
- FIX: drag and drop effect reflects replacing of covers in files with varying covers at Tag Panel and Extended Tags.
I think this addresses all issues and confusion raised in this topic. It would be great if many people could test the new implementation and provide feedback!
This works now much better then before. Thanks for this changes!
In my first test with multiple tracks with 2 covers, where 1 cover is identical for all tracks and the second cover is different for 1 track, the drag & drop without pressed CTRL works fine and replaces all the existing covers with the new 3rd one.
If I try it with pressed CTRL key, the 3rd cover will not be displayed on the lower left Tag Panel cover placeholder, BUT it will be correctly added silently as 3rd cover.
Is there a way to display the 3rd cover - at least temporarely - in a way to "see" that it will be added? Maybe just for the time during drag & drop?
Now only appears, if Ctrl is pressed simultaneously - which I think is the proper behaviour.
Thank you for the feedback. I've just released Mp3tag v3.29d, which includes a +1 indicator in the cover-info area of the Tag Panel if covers are added to multiple files with varying covers.
Furthermore, this new version adds a preview of added covers in a combined cover grid placeholder image, which is also displayed if multiple files with varying covers are selected.
I think I welcome the additional information.
But it is not quite clear to me what I should do with it and adapt my workflow accordingly.
Here is an example of 13 selected files with apparently varying embedded pictures:
The pictures in the grid look the same to the naked eye.
I added 3 columns so that the picture properties could be investigated at a glance and the result of that check is:
1 file has no embedded picture
13 files have an embedded picture with the same dimensions.
11 files have a picture of the mime type PNG
1 file has a picture with the mime type JPG.
1 file has 2 embedded pictures.
But this additional information can only be found with the already existing means of checking the file properties.
The maximum number of pictures in the grid seems to be 4 - so if more pictures occur in the files, then these would not be visible. I have not found a way to scroll through the list of pictures.
I also selected just 2 files with a total of 5 embedded pictures. 1 files has 4 embedded pictures, each set to be a different picture type (front, back, leaflet, artist).
@Florian: Perhaps some more background information would help.
Thanks for your feedback! It shows that this new addition is not as self-explanatory as I hoped and indicates features or ways of using that are either not intended or not implemented.
I already had a similar (slightly more controversial) conversation regarding this via PM yesterday, which showed that this feature is likely to cause confusion or to disappoint expectations. I've originally simply intended it to be a more detailed placeholder image for covers of files with varying covers. As a bonus, it showed the dropped covers that would be added when saving.
I know that I can't meet every expectation. But I also don't want to introduce features that require extra explanation, especially for experienced users like you, or that only end up highlighting what isn't possible. So, I'm reverting this change with Mp3tag v3.29f.
