I understand this is an old topic but it is relevant to the issue I'm having. I have MP3 and JPG files that start with the syntax YEAR_TRACK where YEAR is 4 digits representing the year and TRACK is a three digit track number . Beyond the first 8 characters in the JPG filename I don't really care about the characters since the first 8 digits will uniquely match the JPG to the MP3 file. If I manually remove the characters beyond the first 8 characters of the JPG filename I can get the import cover art to work using:
%year%_%track%.jpg
When I try and match the JPG to the MP3 file using:
%year%_%track%*.jpg
The import cover art doesn't match the JPG to the MP3 file. I'm trying to avoid renaming all the jpg files to get this to work simply by using a wildcard character. In a previous posting, someone claimed that wildcards "*" and "?" are now supported on versions of MP3Tag greater than 2.49.
Could someone confirm this statement? It seems like it doesn't work on the Mac version 1.8.2 (105)
Thanks for the response, I did follow the proper filename/path syntax as I got the import cover action to work. In my previous post, I omitted the path specific info but will include it here for clarity:
In MS Windows environment you can use AREN to prepare the picturenames accordingly.
The tool can be found this website.
Maybe there is something similar for MAC available.
I wrote a short shell script in LINUX that renamed the scan files into the %year%_%track%.jpg, and from there, I was able to use the import cover art action to update the MP3 files with missing cover art. MP3Tag did most of the work on this task which would have been tedious to do manually given the number of MP3s I had to update.
You've observed correctly: wildcards like * and ? are currently not supported for the filename in of the Import Cover action and I've added a corresponding note to my internal wishlist.