Some cover art tags are not written v2.46


#1

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 :flushed:


#2

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).


#3

I tripled-checked this and even copied the name of the mp3 file (minus the file extension) into the name of the .jpg. :huh:


#4

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


#5

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.


#6

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

DD.20100819.0754.CEST


#7

Path length is only 60 characters. :\


#8

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

DD.20100819.1951.CEST


#9

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.


#10

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