When I import a 600x600px jpg file of 90Kb into a m4a file (tag structure mp4), MP3Tag tells me that the size is 212KB (when I paste it in the cover art box), and 90KB when using "add cover..." method.
Of a different jpg (also 600x600px) of 110KB, MP3Tag tells me it is 76 KB (when using the copy/paste method), and 110KB when using "add cover..." method.
Is MP3Tag adding additional compression (or expansion !)?
Or is the windows copy/paste command the cause?
Ok, I did some further testing myself. FYI, I have Windows 10 64-bit system.
I choose a random jpg file from the web (so others can try to duplicate this if they wish):
https://musicophilesblog.files.wordpress.co...4746417_600.jpg
JPEG Image, 600 × 600 pixels
147.2 KB (150,733 bytes)
And I will import in 4 different ways into a mp3 file with MP3Tag (I tried an m4a file as well, and it gives the same results) . I read the resulting cover art file size next to the thumbnail in the left panel of the navigation window when I select the file, and give it below for each method:
(1) Rightclick and “Copy image” in Firefox, and then rightclick and “Paste cover” in MP3Tag : 346 KB
I then saved the image on my desktop (mediainfo and file explorer confirm that the 147 KB file size did not change).
(2) Open the image with the default Windows 10 photo viewer, Rightclick “Copy”, and then Paste in MP3Tag : 346 KB
(3) Open the image with another image viewer/editor (I tried GIMP and paint.net), select all, paste in MP3Tag : 346 KB
(4) In MP3Tag, rightclick and “Add cover …”, and then select the file : 147 KB
(5) Import function (I copied the image as folder.jpg) : 147 KB
So the “issue” seems to be with the copy out of a windows program, and paste into MP3Tag.
My next steps was to extract the images again from MP3Tag. The image that didn’t change, remained identical after extraction.
The image that got more than doubled in size, maintained that size when extracted, BUT the image properties have changed : the Chroma subsampling moved from 4:4:4 (in the original image) to 4:2:0. Although I am not an expert in jpg and chroma-subsampling, I understood from a quick websearch that subsampling from 4:4:4 (i.e. no subsampling) to 4:2:0 should reduce the filesize with 17% (not increase with 125% !!).
So is this a copy/paste issue with Windows 10 ?
I did another test with GIMP, with the two methods (directly opening the jpg vs. copy/pasting it into a new image), but here there was no difference in the resulting file size (and I don’t really have any ideas about other program where a file can be embedded and that I can use to test).
So my question is, does MP3Tag do any re-saving of the jpg (if done at a 100% quality, this always dramatically increases file size) when it is pasted in the cover art box?
What jpg engine/libraries does MP3Tag use?
Thanks for pointing this out (I did search the forums before posting, but didn't see this topic).
But, this is how it was implemented in 2008.
Did the copy/paste function (Clipboard) in Windows not become more "intelligent" since then?
Or is this a design choice of MP3Tag?
My understanding of the Clipboard (as currently implemented in Windows) is that it captures different types of information about the copied content, and the "receiving" application basically decides what to take from that.
In case of an image, the Clipboard contains a DIB (probably converted by the source application or the OS itself), but the original jpg file is also kept on the Clipboard.
I understand from Florian's explanation (in 2008) that he choose to take the plain Bitmap (DIB) information (and maybe there was at that time not another option).
I am quite sure that nowadays you can extract more information from the Clipboard, and there is no need to import the flat Bitmap, and then re-convert to jpg (probably with very high quality settings, which explains the big file size).
Today, with exactly the same scenario (copy from photo viewer or from firefox), other applications manage to extract the jpg as a whole from the Clipboard, and they don't take the DIB. Two examples:
So in short, I understand now the "why"(because MP3Tag takes the DIB from the Clipboard).
But I think the expected behavior should be to take the original file (jpg or png or whatever is supported) from the Clipboard, and only take the DIB if no other information is present.
But this I probably have to put as a feature request ...
As I understand applications, which are ready made for Emailing, they just only can attach complete data objects into an Email container.
This way the clipboard carries only the full pathname to the original file.
To put data into a binary tag structure, which is attached to media file, is not as simple as attaching a data object to an email body.
How a binary data object like a picture has to be stored into a tag structure is declared by the tag type itself.
In Mp3tag I am trained to insert a picture binary stream into a dedicated place within a given tag structure, ... via Clipboard ... as a clean binary object.
DD.20170118.2239.CET
Well, I don't want to say it's easy, or even possible, and I am not an expert in application design or programming.
Just some final thoughts:
If the clipboard contains other information (e.g. filepath as you mentioned), it looks to me that it should be possible to access that file and add that jpg directly as cover art.
If it is impossible (because the file is not accessible), I think it could be made clearer, that if you copy/paste a jpg into MP3Tag, it will transition through a DIB file and become more than double the size (just calling it "Past as Bitmap" instead of just "Paste" would already have put the red alarm bells ringing ... )
Anyway, too late for me now, because I literally inserted tens and tens of cover art into hundreds of music files with the copy/paste method (often even while having the jpeg on my laptop, but it was just so easy to double click on the jpg, do a copy and then paste into MP3Tag, instead of searching for the file again within MP3Tag ... lazy me ...), and "lost"/spoiled probably many Megabytes because of the files became more than double the size. 
I assume there is no possibility to check whether the embedded cover art went through such Bitmap stage? (can we check the Chroma Subsampling directly?? as this seems a way to recognize these images)
Maybe you can diminish the waste of space by using the Mp3tag dialog "Extended Tags..." and within there, do add one or more cover pictures using the dialog "Add cover...".
This will add an image stream without any change in size.
DD.20170119.0651.CET
Yes indeed, that works as well.
But as I said, rightclicking in the left panel cover art area and then "Add cover ..." instead of "Paste" also is sufficient to add the original jpg without change in size.
Idem for creating an action "import cover art".
Hmm, there is already a Mp3tag Action "Import cover from file".
DD.20170119.1033.CET