# Some cover art tags are not written v2.46

**URL:** https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268
**Category:** Support
**Created:** [April 8, 2010, 8:46pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268 "2010-04-08T20:46:43Z")
**Posts on this page:** 11
**Page:** 1

<div class="post-metadata">

### Author: ![AlphaWave](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/d26b3c/32.png) [@AlphaWave](https://community.mp3tag.de/u/AlphaWave)
#### Post date: [April 8, 2010, 8:46pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/1 "2010-04-08T20:46:43Z")

</div>

Certain tags are not written with cover art when I use the action: %\_filename%.jpg

I have checked that the files in question do not have ' or [] characters. There seems to be no logical explaination. Out of 2000 files in the same folder, 30 or so are simply not written and the error says:

Import cover from file "%\_filename%.jpg": File D:\Music\blah - blah.jpg cannot be accessed.

Yet, if I go to each file and add the art manually it works 😳

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 9, 2010, 12:16pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/2 "2010-04-09T12:16:06Z")

</div>

Maybe there is indeed a slight mismatch between the name of the cover file and %\_filename% (e.g., a character that looks similar but is in fact another character).

---

<div class="post-metadata">

### Author: ![AlphaWave](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/d26b3c/32.png) [@AlphaWave](https://community.mp3tag.de/u/AlphaWave)
#### Post date: [April 9, 2010, 3:32pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/3 "2010-04-09T15:32:58Z")

</div>

I tripled-checked this and even copied the name of the mp3 file (minus the file extension) into the name of the .jpg. ![:huh:](https://community.mp3tag.de/uploads/default/original/1X/f15ee73c0fd9ec3b0db7481f0558638f8ee224ce.gif ":huh:")

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 11, 2010, 5:24am UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/4 "2010-04-11T05:24:52Z")

</div>

Can you reproduce this for the erroneous cases when you only apply the action to those files?

---

<div class="post-metadata">

### Author: ![nfaiola](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/n/e9bcb4/32.png) [@nfaiola](https://community.mp3tag.de/u/nfaiola)
#### Post date: [August 19, 2010, 3:00am UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/5 "2010-08-19T03:00:15Z")

</div>

I'm having the same issue. Since only a few of the tracks in several albums were missing cover art, I ran the action "Export Cover Art To File: folder.jpg". When running "Import Cover Art from File: folder.jpg" it states that it cannot be accessed.

There are no special characters in the paths, and there are no stray spaces in either of the parameters.

If I run a Quick Action -\> Import Cover Art from File and manually browse to folder.jpg (typing produces the same error), it will apply.

It sounds like a variance in the spellings or the characters, but there are none.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [August 19, 2010, 3:54am UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/6 "2010-08-19T03:54:11Z")

</div>

> [@iRelevntRequiem](#):
>
> ... If I run a Quick Action -\> Import Cover Art from File and manually browse to folder.jpg (typing produces the same error), it will apply. ...

Possible problem with the overall length of the filepath?  
The Windows API knows a "Maximum Path Length Limitation", the maximum length for a path is 260 characters.  
See also: [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx](http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx)

DD.20100819.0754.CEST

---

<div class="post-metadata">

### Author: ![nfaiola](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/n/e9bcb4/32.png) [@nfaiola](https://community.mp3tag.de/u/nfaiola)
#### Post date: [August 19, 2010, 1:31pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/7 "2010-08-19T13:31:38Z")

</div>

> [@DetlevD](#):
>
> Possible problem with the overall length of the filepath?  
> The Windows API knows a "Maximum Path Length Limitation", the maximum length for a path is 260 characters.  
> See also: [http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx](http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx)
> 
> DD.20100819.0754.CEST

Path length is only 60 characters. :\

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [August 19, 2010, 3:51pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/8 "2010-08-19T15:51:15Z")

</div>

Hmm ... possibly Mp3tag does not look into the right folder when trying to import the named picture file?

DD.20100819.1951.CEST

---

<div class="post-metadata">

### Author: ![nfaiola](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/n/e9bcb4/32.png) [@nfaiola](https://community.mp3tag.de/u/nfaiola)
#### Post date: [August 20, 2010, 2:12am UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/9 "2010-08-20T02:12:55Z")

</div>

Alright after some sleuthing, I figured it out...simple solution but due to a glitch somewhere it took a while to catch.

OS: Windows 7  
MP3Tag v2.46a

Check your Folder Options \> Hide Extensions for Known File Types. What looked to be a completely normal "folder.jpg" was actually "folder.jpg.jpg".

Not sure if this is an issue with the way Windows 7 handles files or how MP3Tag creates them, because like I said these were created by Export Cover to File: folder.jpg.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [August 20, 2010, 4:46am UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/10 "2010-08-20T04:46:12Z")

</div>

> [@iRelevntRequiem](#):
>
> Alright after some sleuthing, I figured it out...simple solution but due to a glitch somewhere it took a while to catch. ... Check your Folder Options \> Hide Extensions for Known File Types. What looked to be a completely normal "folder.jpg" was actually "folder.jpg.jpg".  
> Not sure if this is an issue with the way Windows 7 handles files or how MP3Tag creates them, because like I said these were created by Export Cover to File: folder.jpg.

iRelevntRequiem, ... hmm ... as you stated ... there was human interaction envolved ... in this case this leaded to an _uncorrect_ filename with a _correct_ file extension.

If I remember well ... this is a long time known situation and reason for a lot of lost time for debugging. Because Mp3tag can only export a picture as of filetype jpg, it handles the export process by adding the filetype automatically to the result of the given format string.

If the user had added a little deliberate some text to the _format string_, then the whole process of exporting and importing cannot be done successfully, when the applied format strings for export and import respectively their result values are not identical. So there are different filename strings, which leads to the system error message that the file cannot be accessed.

There are some related postings in the forum, the Mp3tag manual has no special note about this trap, but should have.

What do we learn?  
The handling of Mp3tag export and import actions is not working fully symmetrical.  
On export the user is not allowed to set a file extension.  
On import the user has to code the file extension.  
A user of Windows Explorer should always enable the display of the file extension.

Much success with Mp3tag anyway!

DD.20100820.0840.CEST

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [November 12, 2025, 3:06pm UTC](https://community.mp3tag.de/t/some-cover-art-tags-are-not-written-v2-46/10268/11 "2025-11-12T15:06:20Z")

</div>

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