# Feature Suggestion: "OK to all" when renaming files

**URL:** https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857
**Category:** Mac
**Tags:** feature
**Created:** [August 19, 2023, 1:48am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857 "2023-08-19T01:48:49Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![triks\_melb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/3be4f8/32.png) [@triks\_melb](https://community.mp3tag.de/u/triks_melb)
#### Post date: [August 19, 2023, 1:48am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/1 "2023-08-19T01:48:49Z")

</div>

Any chance an option could be added to automatically answer `OK TO ALL` when renaming files? Clicking this 1000s of times gives RSI, and using macOS Automator works but is much slower than if the feature was built-in.

thank you in advance.

 ![Screenshot 2023-08-19 at 9.56.57 am](https://community.mp3tag.de/uploads/default/original/2X/3/3517565e9bcebefdba2b4f63d887cc735e6c301b.png)

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [August 19, 2023, 3:37am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/2 "2023-08-19T03:37:59Z")

</div>

There have been several similar discussions in the past about this. See here for some perspective on the thoughts around OK to All.

> [@\[Idea\] Ignore Errors, bulk skip un-editable files](https://community.mp3tag.de/t/idea-ignore-errors-bulk-skip-un-editable-files/60188):
>
> I have been using the program for a long time, sometimes it fails to change the metadata of a file and the program spams me with windows that I have to open several hundred times, is it possible to put a marker to ignore errors and miss files that cannot be edited?

---

<div class="post-metadata">

### Author: ![triks\_melb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/3be4f8/32.png) [@triks\_melb](https://community.mp3tag.de/u/triks_melb)
#### Post date: [August 19, 2023, 8:20am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/3 "2023-08-19T08:20:43Z")

</div>

Thank you for your response. The referenced discussion doesn't appear to offer a solution; rather, it confirms that the feature in question is unavailable and will not be added.

> the only way around it is to check the files first for integrity.and then tag only the ones that prove to be ok.

In my specific case, I encountered duplicate files within 100's of subfolders. There are 1000's of duplicates which remained hidden until I removed the track number from the filename and replaced the filename with %artist% - %title% using the %track% only in the ID3 tag.

From a logical standpoint, it would make sense for a tool like mp3tag to provide a warning in the event of overwriting or deleting such duplicates.

After alerting the user, the tool could then continue with its processes based on 1 chosen response from user.

Once complete, I would manually sort all tracks within mp3tag. subsequently, I would identify and remove the remaining duplicates that still have leading track numbers in their filenames.

Unfortunately manually checking for duplicates is impossible simply due to the number of files.

I can appreciate implementing such feature would be timely but wanted to share my user experience with MP3TAG.

---

<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: [August 19, 2023, 8:29am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/4 "2023-08-19T08:29:24Z")

</div>

> [@triks\_melb](#):
>
> I can appreciate implementing such feature would be timely but wanted to share my user experience with MP3TAG on Mac.

Thanks for your feedback and the suggestion. You're not the first to ask for that and it's on my list. In your case, an **OK for all** option might help at identifying the duplicates so I appreciate the explanation of your use case.

> [@triks\_melb](#):
>
> it confirms that the feature in question is unavailable and will not be added.

It's only the former, not the latter. And even when I say something will not be implemented, there are — thankfully — cases where I've changed my mind in the past 20+ years.

---

<div class="post-metadata">

### Author: ![triks\_melb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/3be4f8/32.png) [@triks\_melb](https://community.mp3tag.de/u/triks_melb)
#### Post date: [August 19, 2023, 8:32am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/5 "2023-08-19T08:32:17Z")

</div>

thanks Florian, perhaps as a global option at least.

---

<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: [August 19, 2023, 8:35am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/6 "2023-08-19T08:35:42Z")

</div>

I think it's better done on a per feature-invocation basis and I've already started working on such "Apply to All" options in other parts of the app.

See this one for example, when writing tags fails for a file:

 ![image](https://community.mp3tag.de/uploads/default/original/2X/5/5d894263196d305b4837b46da3feba1cbb427f15.jpeg)

---

<div class="post-metadata">

### Author: ![triks\_melb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/3be4f8/32.png) [@triks\_melb](https://community.mp3tag.de/u/triks_melb)
#### Post date: [August 19, 2023, 1:16pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/7 "2023-08-19T13:16:44Z")

</div>

Hi Florian, yes that would be perfect!

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [August 19, 2023, 1:27pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/8 "2023-08-19T13:27:17Z")

</div>

The thread I referenced wasn’t a solution, but a discussion about identifying the root cause of the error.

Especially when batch renaming files, an error like this one is a clear indication that the naming convention used likely has a flaw that causes some or all tracks to overwrite others. I would strongly caution about having a “OK to All” option in this case.

The better approach would be to take a step back and identify what is causing the repeated condition, and correct that first. The last thing you would want is to have 18k files become 1 if you were to inadvertently use a fixed naming convention that tells mp3tag to set all files to the exact same folder and file location. Or to have a bunch of duplicate files created that will then require further work to identify and clean up.

This is just my opinion of course, but with 18k tracks I wouldn’t be so quick to blindly override that error message.

---

<div class="post-metadata">

### Author: ![triks\_melb](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/t/3be4f8/32.png) [@triks\_melb](https://community.mp3tag.de/u/triks_melb)
#### Post date: [August 19, 2023, 2:02pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/9 "2023-08-19T14:02:56Z")

</div>

I think Florian hit the nail on the head.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [August 19, 2023, 3:41pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/10 "2023-08-19T15:41:01Z")

</div>

> [@triks\_melb](#):
>
> I would identify and remove the remaining duplicates that still have leading track numbers in their filenames.

How would you know which file to keep? The renamed one or the one with the track number? And if there are more than 1 of these files with e.g. different track numbers - how would you determine which of these files would be the best?

Here is a longer discussion on the topic how to deal with alleged duplicates:

> [@Please include a tool / function for removing / deleting dupulicate songs (files)](https://community.mp3tag.de/t/please-include-a-tool-function-for-removing-deleting-dupulicate-songs-files/18508):
>
> Please include a tool / function for removing / deleting duplicate songs (files). I understand this product is a tag editor but it would be great to a have great duplicate song removal tool! Most are are are very good and are difficult to set-up so it works. Thx, William

I think that the critierion that ARTIST and TITLE are the same is probably not sufficiant as this would assume that the data is absoluletely correct. But even then you could have the original version, the one from the Greatest Hits album, the anthology. This does not even consider that data is missing from the tag fields like "live", or "remix" or a version that popped up years later.  
So I think that eliminating the duplicates actually requires

> [@triks\_melb](#):
>
> manual(..) checking

If an option to remember the user input should be implemented I would favour one only for "Skip all" but not as confirmation to overwrite existing files.

---

<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: [August 19, 2023, 4:08pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/11 "2023-08-19T16:08:50Z")

</div>

> [@MotleyG](#):
>
> I would strongly caution about having a “OK to All” option in this case.

> [@ohrenkino](#):
>
> I would favour one only for "Skip all" but not as confirmation to overwrite existing files.

The **OK** option in the existing implementation is essentially a **Skip** , so the suggested **OK for All** is actually a **Skip for All**.

Otherwise, the above-mentioned files with the track numbers that are used for identifying duplicates would also not exist anymore.

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [August 19, 2023, 5:51pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/12 "2023-08-19T17:51:11Z")

</div>

> [@Florian](#):
>
> The **OK** option in the existing implementation is essentially a **Skip** , so the suggested **OK for All** is actually a **Skip for All**.

If skipping is the implementation, is there any plan to have a log created that would perhaps summarize the successful number of files, and also to indicate each file write that was skipped/failed? This would help to track down those that weren’t managed as expected.

For a single track it would be easy to find. For a large batch it might be more challenging.

---

<div class="post-metadata">

### Author: ![Apesville](https://community.mp3tag.de/user_avatar/community.mp3tag.de/apesville/32/15578_2.png) [@Apesville](https://community.mp3tag.de/u/Apesville)
#### Post date: [December 7, 2023, 9:40am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/13 "2023-12-07T09:40:31Z")

</div>

My music player has a duplicate feature built in, which pulls up all versions of a song to find doubles. even selects highest bit rate to keep.

But the apply to all box when ticks does not stop the **Cannot write tags to file** box jumping up when ticked & selecting skip for me. Which is annoying when you doing 90000 mp3 & have to sit next to the iMac & keep clicking skip every few minutes instead of leaving it to run.

Mac OS Big Sur version 11.7.10

---

<div class="post-metadata">

### Author: ![Apesville](https://community.mp3tag.de/user_avatar/community.mp3tag.de/apesville/32/15578_2.png) [@Apesville](https://community.mp3tag.de/u/Apesville)
#### Post date: [December 7, 2023, 1:54pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/14 "2023-12-07T13:54:13Z")

</div>

My music player has a duplicate feature built in, which pulls up all versions of a song to find doubles. even selects highest bit rate to keep.

But the apply to all box when ticks does not stop the **Cannot write tags to file** box jumping up when ticked & selecting skip for me. Which is annoying when you doing 90000 mp3 & have to sit next to the iMac & keep clicking skip every few minutes instead of leaving it to run.

Mac OS Big Sur version 11.7.10

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [December 7, 2023, 2:16pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/15 "2023-12-07T14:16:56Z")

</div>

> [@Apesville](#):
>
> But the apply to all box when ticks does not stop the **Cannot write tags to file** box jumping up when ticked & selecting skip for me. Which is annoying when you doing 90000 mp3 & have to sit next to the iMac & keep clicking skip every few minutes instead of leaving it to run.

The question that comes to mind with this is about the reason fo this error box. Are these files damaged, locked, in use, or otherwise just unavailable to the OS when the write attempt was heppening? Or is this due to an actual program issue? I would expect it is the former, as the latter has not occured for me in years of regular use.

So assuming it is one of those issues, if the program was to just blindly proceed with 90000 files, how would you know if an error occured, and with which files?

@Florian If there was a skip all feature introduced, would it be feasible to have a log file created whenever an error is encountered, so that each failure condition could be written to that log? Perhaps this would ensure that each error was documented in some way for follow-up.

---

<div class="post-metadata">

### Author: ![Apesville](https://community.mp3tag.de/user_avatar/community.mp3tag.de/apesville/32/15578_2.png) [@Apesville](https://community.mp3tag.de/u/Apesville)
#### Post date: [December 7, 2023, 2:52pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/16 "2023-12-07T14:52:56Z")

</div>

They seem to be m4a files in the main can you separate these before starting?

---

<div class="post-metadata">

### Author: ![MotleyG](https://community.mp3tag.de/user_avatar/community.mp3tag.de/motleyg/32/440_2.png) [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [December 7, 2023, 2:57pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/17 "2023-12-07T14:57:50Z")

</div>

Yes, a filter can be used for the extension type.

---

<div class="post-metadata">

### Author: ![Apesville](https://community.mp3tag.de/user_avatar/community.mp3tag.de/apesville/32/15578_2.png) [@Apesville](https://community.mp3tag.de/u/Apesville)
#### Post date: [December 7, 2023, 3:31pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/18 "2023-12-07T15:31:35Z")

</div>

Sorry being an old person where do I find the filter? Thank you

---

<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: [December 7, 2023, 4:09pm UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/19 "2023-12-07T16:09:25Z")

</div>

> [@Apesville](#):
>
> They seem to be m4a files in the main can you separate these before starting?

Can you edit them individually or does the error also appear then? If the error appears, you could export an error log via [BackLog](https://eternalstorms.at/backlog/). This might reveal more information than the error message.

> [@Apesville](#):
>
> where do I find the filter?

It's the search field in the upper right of the toolbar. You can use

`%_extension% IS m4a`

as [filter expression](https://community.mp3tag.de/t/filtering-and-searching-files-and-tags/53271).

---

<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: [January 23, 2024, 9:54am UTC](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857/20 "2024-01-23T09:54:37Z")

</div>

I've added an option to stop, skip, and rename (with apply to all) on errors when renaming files with [Mp3tag for Mac 1.8.13](https://community.mp3tag.de/t/mp3tag-for-mac-v1-8-released/61431/18).

[Next page](https://community.mp3tag.de/t/feature-suggestion-ok-to-all-when-renaming-files/61857.md?page=2)
