# Re: Adding native FLAC padding column and removal
**URL:** https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372
**Category:** General Discussion
**Created:** [March 14, 2023, 1:17pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372 "2023-03-14T13:17:14Z")
**Posts on this page:** 10
**Page:** 2
### Author:  [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 19, 2024, 8:32am UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/21 "2024-01-19T08:32:49Z")
> [@Lebon14](#):
>
> And adding a few seconds because I removed the padding for the padding for the tags to be recreated is no biggie.
Are you sure? Because it really depends on how many FLAC files do you have.
If you change some thousands of FLAC files and they are saved on a NAS, you will have to wait several minutes or more because every file has to be completely rewritten due to the lack of free available (padding) space in your tags.
---
### Author:  [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [January 19, 2024, 9:36am UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/22 "2024-01-19T09:36:23Z")
> [@Lebon14](#):
>
> I much prefer having a single image files easy to change in the folder where my FLAC file(s) are.
Same. Which is why I remove any embedded images and then convert from flac to flac. The space taken up by the embedded image is reclaimed and only a tiny 4KiB padding remains for tag changes to retain the ability to change the tags within that 4KiB without having to rewrite the rest of the file.
> [@Lebon14](#):
>
> That can also be an optional option. Don't force your opinion on others.
That's what I wrote, is it not?
> [@Casual\_Tea](#):
>
> I think this option would be far more useful if the user could set whether to remove the padding completely (now state) or if the padding should be set to a chosen value (if possible).
I don't feel like I've forced anything on anyone. I just stated why I have the opinion concerning padding that I do. I handle 100s of thousands of songs with several users and a multitude of software that accesses my music. Keeping my library performant is paramount to me. But I also like keeping things tidy and hate wasting space. Thus: No embedded images, BUT a 4KiB padding.
Do it your way if you prefer it. Doesn't really bother me if you like waiting on every metadata change.
---
### Author:  [@Lebon14](https://community.mp3tag.de/u/Lebon14)
#### Post date: [January 19, 2024, 12:45pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/23 "2024-01-19T12:45:42Z")
> [@poster](#):
>
> Padding is not special to image files., in flacs it is only a problem because of the possible notable waste of space as Mp3tag does not clear this space after deleting embedded artwork automatically and artwort is the only tag that really needs notable space.
I know that! I was talking about the padding added by the image files only, not the basic 4096 bytes for the tags. That 4096 bytes is normal and is not the padding I want to remove at all.
> [@LyricsLover](#):
>
> Are you sure?
Yes? I'm not mass removing the padding (incl. the padding for tags) for a thousand song most of the time. It's usually by album (I'm looking at you, Bandcamp!). The re-adding of the 4096 bytes of padding for tags does really only take an extra second or two. On top of that, my files are also on a NAS. The files being on my local M2 SSD or the HDDs in my NAS really doesn't make a difference in the time it takes to re-add the 4096 bytes padding.
If, for you, it takes more time than that, I suspect you are using a old computer or something? I remember doing the same with my very old Core i7 950 and it didn't take that much longer. (I now have a Ryzen 9 5900X)
> [@Casual\_Tea](#):
>
> I don't feel like I've forced anything on anyone
To me, it read like "this option shouldn't exist because..."
Keeping the basic 4096 bytes padding would only save a second or two at best per file (again, talking on an album basis - not massive batch editing).
---
### Author:  [@MotleyG](https://community.mp3tag.de/u/MotleyG)
#### Post date: [January 19, 2024, 2:45pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/24 "2024-01-19T14:45:49Z")
@Florian Thank you for adding this new utility to remove unused padding in FLAC files after removing or adjusting large artwork. This is very helpful in cases where previously this remaining padding kept excessive file sizes for no other reason.
From the flurry of posts following your announcement of this addition, it appears there is already some heated discussion about whether removing 100% of the padding, or if leaving the standard 4k intact is preferred. So perhaps a _ **feature request** _ to enhance this new utility: have an option to remove all of the padding, or keep 4k in reserve.
---
### Author:  [@xRussianBeautyx](https://community.mp3tag.de/u/xRussianBeautyx)
#### Post date: [January 23, 2024, 2:41am UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/25 "2024-01-23T02:41:28Z")
I think that keeping a 4 KiB padding would be the sensible option for most users:
- An overhead of 4 KiB (at most) isn't much, even for a large number of files, especially with the storage capacities of TBs we have nowadays.
- The much faster file updating outweights the tiny storage overhead.
- Ah, and SSD wear (although this issue is supposed to be nonexistent).
- The format just has been designed to use padding, as the metadata is at the beginning.
For users who want to squeeze every possible byte (as I was before), they still have the possibility to achieve it on their side.
Also, keep in mind the feature built in Mp3tag is only for convenience. I mean that as manually reducing the padding is sometimes required, it should at least be easily doable. It is required as a workaround because removing embedded images leaves an huge padding. In a perfect world, we shouldn't even have to care about manually reducing the padding.
---
### Author:  [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [January 23, 2024, 3:08pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/26 "2024-01-23T15:08:30Z")
Thank you all for your feedback! I didn't expect such heated discussion for such a tiny feature, but apparently I should have put more thought into this before releasing. Thankfully, we're still in beta stage.
I'm very hesitant to add yet another configuration option. I know it's great to be able to configure the exact size of the padding, but it will result in just more configuration options โ there are also other tag formats with padding ๐ฌ
The discussion above revealed an inconsistency wrt. the new optimization feature: while writing tags, Mp3tag adds 4KB of padding in case the file needs to be rewritten. This should also be โ and it's what most feedback here shows โ the default when optimizing the padding. So I've just released [Mp3tag v3.23e](https://community.mp3tag.de/t/455), which does exactly that: if you choose **Utils โ Optimize FLAC** from the right-click context menu of FLAC files, the files will have 4096 bytes of padding after optimization.
> [@xRussianBeautyx](#):
>
> In a perfect world, we shouldn't even have to care about manually reducing the padding.
I want to address this quickly: removing padding from FLAC after, e.g., removing embedded cover art would require rewriting the file if a new cover is added. I've tried to not be smart about this, because there are many different workflows, which might be disturbed by such automatic behavior. I think you meant your comment not as a suggestion, but wanted to quickly explain for people who are wondering about that.
And maybe there is also a silent group which was very happy with the complete removal of the padding. Please raise your voice so that I know, but also please use [the workaround via metaflac](https://community.mp3tag.de/t/why-does-certain-artwork-break-windows-explorer-metadata/59995/4) for the time being.
---
### Author:  [@xRussianBeautyx](https://community.mp3tag.de/u/xRussianBeautyx)
#### Post date: [January 23, 2024, 6:59pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/27 "2024-01-23T18:59:46Z")
I just understood this padding is not empty space added to reach the desired size (the usual meaning of padding), but an overhead having the configured size (+ 4 bytes). Refs the [--add-padding](https://xiph.org/flac/documentation_tools_metaflac.html#shorthand-operations) operation.
About removing then adding again an embedded picture, the user should expect such operation to be costly. Hey, we are talking about embedding an image (and possibly large) into an audio file. So it would be better to reduce the padding when removing an image, rather than keeping the padding just in expection of this specific use case.
About the padding size, do we really need as much as 4 KiB? Its purpose is to avoid rewriting the entire file when just adding a few characters, or a few fields. Even with 512 bytes, there is plenty of space for several fieldsโฆ (beware: such discussion about the padding size would certainly become endless, better find a way to settle it)
About this:
> In a perfect world, we shouldn't even have to care about manually reducing the padding.
I just meant that, generally speaking, users should have to care only about business logic and data, not implementation details. The "padding case" here is a good example of this.
---
### Author:  [@Casual\_Tea](https://community.mp3tag.de/u/Casual_Tea)
#### Post date: [January 23, 2024, 10:32pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/28 "2024-01-23T22:32:31Z")
> [@xRussianBeautyx](#):
>
> About the padding size, do we really need as much as 4 KiB?
I think that value might stem from the fact that many file systems have a default block size of 4K. Meaning if you add 512 bytes or 4K is inconsequential as it will "consume" or "waste" one more block anyways. I don't have a source for that tho, it's just what I always thought.
> [@Florian](#):
>
> while writing tags, Mp3tag adds 4KB of padding in case the file needs to be rewritten. This should also be โ and it's what most feedback here shows โ the default when optimizing the padding.
That does sound more consistent, thanks!
---
### Author:  [@Lebon14](https://community.mp3tag.de/u/Lebon14)
#### Post date: [January 23, 2024, 11:12pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/29 "2024-01-23T23:12:26Z")
> [@Florian](#):
>
> I'm very hesitant to add yet another configuration option. I know it's great to be able to configure the exact size of the padding, but it will result in just more configuration options โ there are also other tag formats with padding
Personally, the more option the better. The padding left behind should at least be a bit configurable - like a drop down box: No padding at all (0KB - will end up being rewritten the minute something is added/modified), 4KB and 8KB.
I've seen 8KB is some files and I actually don't know if those files are old or or the tool that was used to encode the files.
Alternatively, a checkbox that says "Leave 4KB of padding when optimizing padding in FLAC files."
> [@Florian](#):
>
> I want to address this quickly: removing padding from FLAC after, e.g., removing embedded cover art would require rewriting the file if a new cover is added. I've tried to not be smart about this, because there are many different workflows, which might be disturbed by such automatic behavior.
I'd love to get the automatic behavior as well which would also take the above option into consideration. A simple checkbox would also fix this: "Automatically trim the padding of FLAC files when removing embedded artwork."
These two options would fit very well in Options -\> Tags -\> Advanced.
I'd say, for the default behavior, it should be to automatically trim the padding down to 4KB when removing artwork. My mindset is that most users _ **will not know** _ about FLAC padding not being automatically adjusted when removing artwork. That's because, for any other format, it's done automatically. But not FLAC.
Addendum: That goes without saying that the manual trim option should always stay because not all the files will have been handled with MP3tag beforehand.
---
### Author:  [@system](https://community.mp3tag.de/u/system)
#### Post date: [February 22, 2024, 11:12pm UTC](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372/30 "2024-02-22T23:12:34Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
[Previous page](https://community.mp3tag.de/t/re-adding-native-flac-padding-column-and-removal/60372.md?page=1)