How do I program the mp3tag command Actions: I have an image with the same name, and I would like to save it over an existing image if they are not the same size?

Support
1

Hello, I have a small problem: if I reduce the size of the image of my audio file and send this image with the same name to a folder using an Action command, Mp3tag adds the following character: (01) even though my image has the same name as the other unreduced image?

I'd like to be able to save my image over another image with the same name, even if they're not the same size.

Thanks in advance for your help.

artist-album.jpg (600)
artist-album(01).jpg (200)

2

AFAIK there is no function or setting in MP3tag to get a different behaviour.
As such files are external files and not among the supported file types, it would be the task of an external task/tool to probably remove these files.
E.g. a batch file, with the command
del *.jpg
would remove jpg files from the current work directory.
It would be an extra step in the workflow, no automatism.

3

How do you do that?

If I do this by an action of the type "Export Cover to File" and don't mark "Allow duplicate covers" in the action dialogue files with the same name are overwritten.

4

Hello @ohrenkino,

Thanks for your reply. :slightly_smiling_face:

I was hoping there was a command in Mp3tag that could handle this...

As you said, I imagine it would be possible with a batch file (and an Mp3tag tools)... :thinking:

5

You are right, but the option is called "Export duplicate covers".
If NOT checked/activated there is no (1) or (2) addition to the filename.

image
image436×289 6.32 KB

"Overwrite existing identical covers with the same name" might be a clearer description.
But with a switched function then.

6

Are you sure that "Export duplicate covers" works like that?
I just took 2 files which had the same cover in size and dimension.
I exported the cover from these 2 files and really got only 1 picture file:
folder.jpg
To get a clean setup, I deleted this file, as next I reduced the dimensions of one of the cover and exported the covers again with the same setting.
But this time I got
folder.jpg
folder(1).jpg
I think that this option avoids that an identical file is created for each of the selected files. As soon as the files differ, a file with an index is created.

7

Hi @poster and @LyricsLover,

Thanks guys for your help...

I just did a test: the "Export duplicate covers" box isn't checked...

It's not working; the first image is 600

The second image, with the same name, is 200 with (1)

8

Hello @ohrenkino

You're right, I get the same result as you...

9

That one is correct, as the documentation says:

If Export duplicate covers is enabled, identical covers (same name and content) are exported.

10

The behaviour may have 2 different sources:
If there are identical pictures in all the selected files, then only a single file would be sensible as all others would be redundant information. If the user still wants to get duplicates, it is MP3tag's task to take care of that. And that is triggered by the option in the action.

The second source is IMHO the OS that creates indexed files when it is requested to save different files under the same name. MP3tag has no influence on how the OS behaves under these circumstances.

Perhaps an amendment to the documentation like "Even it selected, duplicate, indexed files may be created if exported files have different properties besides the filename."

11

Hello @florian,

It would be great to have a new function added to Actions: "Export cover to file".

Adding a command would allow us to overwrite the image if the file name is the same but the image size is different.

Have a good day.

12

I think this would be dangerous as it would lead to loss of data if accidentally covers of with different properties get exported.
As there is no function to compare the properties of embedded pictures between files, the last export would win.
So I think it is a fair deal to ask the user to delete any external files if they are not needed any more.
Picture files in the file system, BTW, are not even supported by MP3tag. SO MP3tag does not really know that they are there and therefore relies on the OS functions.

13

This way OR alternatively, allow the user to decide (with an additional option) whether to always overwrite exported covers, regardless of whether the content is the same.

14

I would set that option to always "on" - which would then disable the safeguard.
So in the end it would mean that the last export would win.
I would prefer an additional message that tells you that different files were found.
Also, I would prefer a behaviour that if an existing file with the same name requires the index, then the existing file should get it and not the newly written one - as I would assume that the user actually wanted a file of the set name and not one with the index.
It would then also be easier to delete the files with the index number than the ones with the plain name and then rename the indexed files to the plain name.

15

A huge thank you to @ohrenkino for this fantastic idea and for explaining it in such detail. :smiley: :+1:

Thank you to @LyricsLover for expanding on ohrenkino's idea and adding this solution: allowing the user to decide (with an additional option) whether to always overwrite exported covers, regardless of whether the content is the same. :wink:

Thank you both; this would prevent data loss.

I'm amending my request to @Florian, thanks to ohrenkino's excellent suggestion and the addition of LyricsLover's idea, which I find much less risky in terms of data loss.