Native option to remove padding from FLAC files

General Discussion
#1

Hi there.
I can't believe MP3tag doesn't support removing the padding and an option to show how much padding a FLAC file has and a warning to users when removing artwork from files.

Now, this is not a call for help. I know how to show the padding in FLAC files in MP3tag and how to remove them afterward. I'd just like Florian to incorporate it within MP3tag and not worry about forgetting to remove them from within Foobar2000.

So, a recap:

  • Allow removing padding from FLAC files natively (either after the fact, or when saving tags)
  • A way to show how much padding a FLAC file has without the column trick.
  • Show a warning after removing artwork to user if padding wasn't removed and the option to do it.

Cheers.

P.S For those who don't know, you can create a column with this code and it will show the padding for all files. Right click the columns and click "Customize columns" and create a new column. Name it "Padding" (or whatever you want really) and copy this in the value field:
$div(%_tag_size%,1024)
...and click the check box "Numeric" and click OK. (Size in KB)

2 Likes
#2

Also I can't find metaflac.exe anymore. FLAC - download this doesn't have it (I dled flac-1.3.3.tar). Installing EAC also doesn't give it in the subfolders. Am I so stupid or what?

#3

You need to get flac-1.3.2-win.zip, seems like they haven't uploaded a Windows build of latest 1.3.3. At least metaflac has no changes between the two versions.

I have padding removal on my list.

#4

Curiosity question: What is padding? Extra file length beyond what the tags use? It's not automatically removed/compressed?

I did a google search, but the results are very confusing.

Thanks.

#5

Imagine you put 30 sheep into a pasture. Around this place you build a fence.
Then you sell 20 sheep. The fence remains and the space for these 20 sheep remains unused. This unused space is called padding*.
The idea is that you might buy 20 sheep again someday and therefore let this space stay as "reserved".

* (as IT term of course, not for the animals :wink:)

#6

Ok, I mostly get that (aside, my background is IT/programming, so I can follow the sheep :upside_down_face:). I guess what I'm asking is, how does padding concern us as Mp3tag users, or MP3 file users? Do all MP3 files have padding? Is it added each time I edit, or only when I change a tag for a smaller tag? I often edit images, for example from 250K to 45K. Is that space still there, unused? Should I be compressing? Is it automatic?

These are the types of questions I have. And I'm happy to research on my own, except as I said, googling this topic brings a bunch of info, most of which doesn't apply or make sense.

I have well over 25,000 MP3 files, using over 250GB of space. If I'm wasting electrons, I'd love to know it. And fix it.

Thanks!!

#7

That's easy:
Check your favorite price compare service for an external 1 TB drive. Compare that price to the value of your wasted time saving some "electrons".
I bet I know the answer...

#8

Just to add something: AFAIK Mp3tag handles padding in chunks of 2k. HD drives may have a cluster size of 4k. So there is probably ample space for padding until any saving effect is noticeable.
Ah, and yes: Mp3tag already handles padding for MP3 files. FLAC files currently get only expanded but not shrunk.

2 Likes
#9

I won't disagree. Spending time to resolve individual files is time wasted.

I was looking at it more from a long-term POV, as in... is there something I should change or set, that would keep files from wasting space on an ongoing basis.

FWIW, I keep them all on my internal laptop HD, a 2TB SSD drive.

#10

I don't see anything really important.

Just one word:
BACKUP :innocent: :wink:

#11

If you are interested how many files there are that may be a little exuberant with the padding, try the suggested utility "mp3diags". This lets you find files with "too much" padding in respect to what mp3diags thinks is too much. But this still meanders around some kilobytes and not megabytes.

2 Likes
#12

Maybe some background why there is padding in the first place: In most current formats the tags are located somewhere at the beginning of the file. That makes sense as you have quick access to the tags, no need to seek for the end, and even in cases where you e.g. only partially have downloaded the files you might already be able to read the tags.

The downside is that when you change the tags and their size changes you need to resize the entire file, which might also involve, depending on format, adjusting some offset positions stored in file. Rewriting the entire file usually is much slower then just changing a few bytes of tags.

So to work around this software writing tags usually adds some extra empty space behind the tags as reserve. So when you in a future read add some data and that fits within existing tag size + padding there is no need to rewrite the entire file. You can add some data to the tags and it will just use up the existing padding, and if you remove data it will increase the padding.

Especially when tagging larger files like FLAC you might already have experienced this: After adding a significant amount of tags saving for the first time is slower, saving the same file again with maybe only minor changes is quick.

I don't know about Mp3tag's implementation, but e.g. the Python library mutagen by default will add a padding of 1 KiB + 0.1% of the file size after the tags as default padding. It will also shrink back the padding to that size if it exceeds 10 KiB + 1% of the file size after the tags. For Mp3tag you might find some details here in the forum.

For your library this would mean roughly 0,25 GB of padding.

UPDATE: Not sure if this is still valid, but

That would mean for your 25k files roughly 50 MiB of padding, about 0.02% of your libraries size.

1 Like
#13

Thank you for your explanation.
I would like to add that the padding is added only if the current space (padding) is not big enough to cater for the tag size. Then a new 2k block is added which would be filled to some extent as the previous one is full. So the unused space would be less than the 2k block as some is being used.

1 Like
#14

Thanks, great info! I love learning behind the scenes type info. Nice job of explaining.

This happens quite often, and now I know why. Often my first edit/save is simply to update or fix the track numbers (I like them in a specific format). And even though they may already have track numbers, sometimes it takes a while to save. It never made sense that changing a format would be so slow, especially for files that already had track numbers. Now I understand why. And yes, all subsequent saves are rapido.

1 Like
#15

That's amazing news!

It's the space made into audio file to insert the image. In FLAC, it's problematic because it is not removed when the image(s) are removed. People can embedded images of several megabytes but this space is not saved when removing them.

MP3 files do not have padding by default. They'll only do if you insert an image in it. In your case, they'll have 45KB padding because of that image. If you remove said image, the padding will be removed. But that's not true for FLAC.

Yup! That's because the basic padding of 4KB (or 8KB) was removed. So, MP3tag has to make said padding to make tag editing much faster.

1 Like
#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.