When selecting a group of WMA files (all in the same dir) and trying to apply a cover to them, the cover is not inserted in all the files. I tried to check whether there was a pattern that could explain which file ended up with the cover and which did not, but the behaviour seems random.

This problem happens when manually including a local JPEG, but also when importing the cover from a service like Amazon. In such a case the checkbox "Save image in tag" does the same thing and not all selected files end up with the image in their tag. It also occurs when creating a script that imports the covers from "folder.jpg" and applying it to a large batch of files.

Sometimes, even selecting a single WMA and trying to add a cover to it takes two or three tries before the cover is finally included.

In all these cases, the program indicates nonetheless that the modification is successful. I get no warning about file write access and do not consider that to be the culprit.

Other than that, the program does a fine job. Congrats!

I continued investigating and I traced the problem to the fact that some of my WMA files systematically refuse to have a cover art added. No matter how many times I try, the program tells me the modification has been made, but when I go back to the file in question, it still has no cover art.

Opening these files in any tag-friendly application (such as Windows Media Player) confirms that the file actually has no image, so the problem is not with Mp3tag not showing it. It just does not include it at first.

I tried to figure out what these files (approx. 10% of my whole collection dispersed through all my directories with no clear pattern) had different than the others (where they write protected? did they have any DRM or whatever that could prevent them from having a cover art?) but can't see why. I can modify any of the other tag fields of these files without any trouble. Weird.

Yeah, I also noticed this before but I don't know how to fix it. I'm using the WMP Runtime internally so I don't know exactly why the cover isn't added.

Sorry.

Kind regards,
Florian

I have the same problem - when I add cover art to a tag, or a group of tags, not all the tags get the art. I find that the problem almost always resolves itself when, on the second attempt, I set all fields in the tag panel to "keep" before I add the art. I do find occasionally, that some few files still resist the addition of album art, but trying different ways of adding the art has always brought success - bringing up the extended tab editor for example, or making sure the focus is on the problem file in the File View window has allowed me to add album art to some of the more stubborn tags - it just takes a little persistence. However, it still is annoying, and I think you should try to fix it.

You don't want to know how many times I've looked at the relevant code already

As this is my first message to this forum, I want to thank Florian for what I consider to be easily the best and most friendly MP3 tag editor that I have seen. I use this program a lot.

Except for the occasional problem with adding album art, I have no issues at all. In my experience, any time that MP3Tag refuses to add or delete album art to MP3 files, I can resolve the issue by opening the problematic files in another tag editor - MP3 Tag Tools (available for free at http://sourceforge.net/projects/massid3lib) - and deleting whatever album art or album art tag is associated with the files. Once that is done, I can add the album art to the files in MP3Tag without problem.

So it seems to me that MP3Tag is simply not recognizing and handling something - something that MP3 Tag Tools does recognize and handle. Florian, perhaps if you examine the source code for MP3 Tag Tools (also available at the above URL), you might get a clue about what MP3Tag is missing.

Again, thanks for this great program.

Hi!

Until recently, I used mp3tag 2.44 on my desktop PC under Win Vista and 7, and most of the time it worked flawlessly. Now I got some new WMAs on my netbook (Win XP) and wanted to tag them nicely. I installed mp3tag 2.45a and tried to add cover art from Amazon. For the first time ever, I ran into the problem described in this thread. On my other computer, I must have tagged hundreds or thousands of WMA albums, including cover art. Without problems.

So: Has the bug returned in 2.45 or might it be an issue specific to XP OS?

Regards
Ben

It could be related to the version of WMP you're using.

That could very well be, for I guess that it is an older version then the one shipped with Vista/7.

Thanks for your reply.

Ben

I've just encountered this symptom. I'm not sure if it is the very same bug, because ‒ unlike previous reports ‒ I've found it to be reproducible. As this bug has already been reported, I've decided to take this one step further and do some testing. My results:

Cover art does not get added if:

• 65494 < jpeg_file_size < 65512
• 65496 < png_file_size < 65514
• 131030 < jpeg_file_size < 131048
• 131032 < png_file_size < 131050
• 196566 < jpeg_file_size < 196584
• ...
• 262102 < jpeg_file_size < 262120
• ...

Some more results:

• the bug does not effect the sub-32768 interval, and, in my assumption, any lower intervals;
• the formula for the effected intervals, in my assumption, is: (k × 65536 − 42; k × 65536 − 24) for jpeg files, +2 for png files.

Like I said, these are 100% reproducible and is unrelated to the width and height or any metadata. It is not related to file consistency either, so you can just use a hex editor to trim the end off a slightly larger file.

As for a workaround, you can add a text comment to the picture to get just the right size.

This is my first post, and I hope I have been of help, Florian.

Regards,
iRBiS

Btw., I'm using Mp3tag v2.45b on Windows 7 but WMP11 if that has anything to do with this.

Hmm, rather mysterious and unbelievable.

I do not have the time to check all the cases you've mentioned, but ...
... I can do add a jpg file of 65501 Byte size into a mp3 file, can export, can extract to clipboard and so on ... no problem.

Do you know if your problematic files have any extra data beyond the file end?
I think of streams. Please check it out.

DD.20100202.1941.CET

DetlevD,

Nice to see others interested in this indeed mysterious phenomenon.



I haven't mentioned, but this effects only WMA files. Yes, I've tested MP3 files, they work fine, and as Florian mentioned ‒ oh, two years ago, he's using WMP Runtime, which is most likely responsible for this problem.

I think I'll just try adding the same cover art in WMP and see what happens. Then maybe try a different WMP version.

Edit:

Okay, I can't insert cover art into files in WMP. It only creates hidden folder files and updates the library database. I currently don't have access to WMP12, but if anyone wants to give it a go, I've included the original picture which led me to this bug and the same picture patched with an empty text comment to make it just the right size.

The culprit seems to be WMP all right. I updated MP3tag to 2.45b and - heureka! - it suddenly worked flawlessly. I had not noticed that, in the meantime, a WMP 11 Runtime had been installed on the computer. When I noticed it, I uninstalled the runtime and the cover art problem was back instantly.

This makes me believe the problem is definitely connected to the WMP version.

Regards
Ben

Hi Ben,

many thanks for talking back and sharing this helpful information.

Kind regards,
Florian