Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Metadata padding and (NTFS) file system block/cluster size (Read 2580 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Metadata padding and (NTFS) file system block/cluster size

I got curious and tried a web search without becoming any wiser:

Would it be straightforward for tagging software to pad to total file size = an integer number of file clusters?
(Yes it will take up an integer number of clusters sure, but you get my drift: if the file uses N clusters, then the padding is the maximum number of bytes that permits N.)

Is this even done routinely among applications that I even might be using?
Or are file systems more complex than that, with file system metadata etc making total size less predictable?
 

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #1 –
Most tags are before the audio data, so you need your padding inside the file, which is not file system dependent then.

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #2 –
The program could round up from a minimum to 4 kB and account for the common block size. If you have large clusters now but copy your files to another disk, then the padding wouldn't be optimal anymore. Usually the amount of data stored in all files comprising an album is similar, either all have artwork or lyrics or they don't. So there is no use to having one with 2 kb and another with 32 kb. If you have small files with sound effects where this amount of padding data can add up to a significant fraction, you can afford to have zero or minimal padding in the first place.

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #3 –
Quote from: spoon on
Most tags are before the audio data, so you need your padding inside the file, which is not file system dependent then.
That is precisely why you use padding in the first place.

I am sure you are able to calculate padding size = N*4096-(heading size + tags size + audio size) - if it really is that simple. Is it?

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #4 –
Quote from: Porcus on
I am sure you are able to calculate padding size = N*4096-(heading size + tags size + audio size) - if it really is that simple. Is it?
In order to pad tags before audio, you need to know exact audio size beforehand... but generally you cannot.
So, If you really want it, you need two-pass process. You encode whole audio first, then create new file, write tags and pad them, append audio copying from the first file.
I don't think it deserves.

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #5 –
Quote from: nu774 on
In order to pad tags before audio, you need to know exact audio size beforehand... but generally you cannot.
Why not, if you already have a file?

If you are reading a stream and putting it to a file, then sure. But a typical tagger considers a file which has audio and maybe tags - and then you know audio, don't you?

As for whether it is warranted ... if some piece of software already has a functionality to reclaim padding, then yes it is.

Re: Metadata padding and (NTFS) file system block/cluster size

Reply #6 –
Oh, I missed your point, sorry. I was considering of encoders.
Quote
Would it be straightforward for tagging software to pad to total file size = an integer number of file clusters?
When there is not enough room in the existing padding and a complete rewriting is required, then it might make some sense.