# Unnecessary files are modified when editing in Extended Tags
**URL:** https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137
**Category:** Support
**Created:** [January 8, 2019, 3:07am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137 "2019-01-08T03:07:27Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@nerama](https://community.mp3tag.de/u/nerama)
#### Post date: [January 8, 2019, 3:07am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/1 "2019-01-08T03:07:27Z")
latest version tested: 2.91
what happens is that i select 100 files and go into Extended Tags (Alt-T). some files may have a particular field, and some may not. let's say 10 files have a "SOURCE" field. i select SOURCE and slick to remove it.
so at this point, when i click OK, the expected behavior is that 10 files will be modified, where the "SOURCE" field is removed, and 90 files will be left alone because they do not have a SOURCE field.
what happens is that all 100 files are modified. this is evident due to:
1. slow operation, mp3tag showing progress of x of 100 files..
2. the modified date stamp of the all files are changed, so i presume mp3tag is rewriting the tag for every file
#1 could yield a huge improvement in performance
#2 the time stamp of each file will reflect when it was "truely" modified, not just re-written with the same information
i have tried this with AAC, MP3, FLAC, and WMA extensions. the behavior is similar for all.
reproduction:
1. put 100 mp3 files in a folder
2. select ALL
3. goto extended tags (alt-T)
4. create/modify tag: COMMENT with some value, click [OK]
> > at this point all 100 files should have COMMENT field
1. select 90 files
2. same as #3
3. select "COMMENT" field and click to remove the field; verify field value is , click [OK]
> > at this point 10 files have a comment field and 90 do not
1. same as #2
2. same as #3
3. same as #7
expected behavior: modifying x out of 10
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 8, 2019, 6:03am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/2 "2019-01-08T06:03:17Z")
see e.g. here:
> [@File Modified Dates updated Unnecessarily](https://community.mp3tag.de/t/file-modified-dates-updated-unnecessarily/19340):
>
> I've noticed that if I have a group of files selected in the MP3Tag window and apply a change that only affects some, the Windows modified date/times for all the selected files are updated I had a few files that had an extended tag set wrong, and rather that search one at a time, I selected the whole folder and set the proper tag, expecting that only a few files would be modified Example: Copy a group of files to a temp folder (Comment field in all was blank) Apply MP3Tag to the folder a…
As nothing has been changed ever since, I suspect that this is a feature, not a bug.
The best way to minimize write operations is still to use a filter that pins down those files that should really be treated.
---
### Author:  [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 8, 2019, 7:40am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/3 "2019-01-08T07:40:07Z")
> [@File resaved and date changed when do nothing](https://community.mp3tag.de/t/file-resaved-and-date-changed-when-do-nothing/43578/3):
>
> Just for clarification: Mp3tag always writes metadata to the files when told so without examining first, whether saving it would result in any actual change to the file. This is by design and not considered a bug.
---
### Author:  [@nerama](https://community.mp3tag.de/u/nerama)
#### Post date: [January 8, 2019, 7:58pm UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/4 "2019-01-08T19:58:53Z")
i admit that i _assumed_ the expected behavior. it's good to know it was designed as-is.
with that said, would it make sense, as a feature enhancement, to implement a mechanism to only modify files that have changed? i propose to make it optional (like a check-box) so that default behavior can always be resumed.
this can definitely be accomplished via filtering; so it's a \>would be nice\< feature. it would be economical in the extended-tags dialogue. because filtering requires the user to remember or separately write down every field that needs to be modified. exit the ext-tag window. create a filter. select files and re-enter ext-tag window.
---
### Author:  [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 9, 2019, 6:14am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/5 "2019-01-09T06:14:47Z")
> [@nerama](#):
>
> because filtering requires the user to remember or separately write down every field that needs to be modified. exit the ext-tag window. create a filter. select files and re-enter ext-tag window.
I would say it requires planning one's work, then filter the files according to the criteria of this plan, like "add comment field with certain text where comment is missing" so the filter would be
comment MISSING
This even has the advantage that you can see whether your plan will probably work i.e. you will get any hits at all or surprisingly, you get far too many so there may be something wrong.
A workflow in which you select more files than actually required may be feasible for just a few files like e.g. in the hundreds. As soon as your collection contains 4-. 5- or even 6-digit number of files, then you have to filter anyway as otherwise it would take far too long to modify the data in just a few files but scan through the majority where nothing has to be changed.
So it is in your hand to offer MP3tag just the right amount of files for modification.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 8, 2019, 6:14am UTC](https://community.mp3tag.de/t/unnecessary-files-are-modified-when-editing-in-extended-tags/44137/6 "2019-02-08T06:14:49Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.