Problem with foobar custom encoder

Topic: Problem with foobar custom encoder (Read 1423 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Problem with foobar custom encoder

2022-10-02 20:26:18

I set up a custom FLAC encoder like this:

Encoder file: flac141.exe
Extension: flac
Parameters: -8 -P 4096 --ignore-chunk-sizes - -o %d

Any idea why "-P 4096" seems to be ignored? The generated FLAC files contain NO padding blocks...

Re: Problem with foobar custom encoder

Reply #1 – 2022-10-03 07:14:53

It is not ignored. You get only 4 kilobytes of padding with your custom encoder. Note that FLAC by default uses much larger padding by default on its own. If that 4 KB is not enough to store the metadata the entire file will need to be rewritten when tagged. And I think foobar2000 adds extra padding when that happens to try to prevent full rewrites in the future.

Also note that foobar2000 v1.6.6 added automatic seektable tagging for encoded FLAC files as FLACs without seektables didn't work properly everywhere. Seektables also require metadata space and the space is taken from that padding.

Re: Problem with foobar custom encoder

Reply #2 – 2022-10-03 11:10:43

It seems to me that fb2k does the following, where the italics part may be "unwanted" behaviour (and this is related to a wishlist item of mine):
(1) Appiles your -P (defaulting to 8192)
(2) Generates a seektable
(3) Writes seektable and if you have ticked off: transfers tags and calculates and writes ReplayGain, and
... and if in (3) the padding is exceeded: full file rewrite (this is expected), but
without any padding added in this stage

That makes for a wishlist item I have voiced before, but sure it is easy to wish features on other people's time. Under "When done", a checkbox for "Apply padding for front-tagged formats (FLAC, MP4, ID3v2)"
But I think a better solution would be to have it in Preferences -> Advanced, which leads me to a wishlist item I have listed before (applicable to front-tagged formats):
An advanced option to, when applying the "Optimize file layout + minimize file size" [which then could be rephrased "Optimize file layout and size"] utility - also to be applied when rewriting post encoding,
-> Padding applied [___] (enter 0 for none, to minimize file size)
-> Round up to file size of nearest [___] kibibytes (to match file system cluster size; if in doubt, enter 4)
-> [_] don't pad ID3v2 (for compatibility with buggy software)

The situation is, when rewriting a file - as opposed to encoding - FLAC will know the full length. And if the file system cluster is 4k - which is the default on NTFS (and ext3, so presumably on some NASes too), the file takes up an integer number of 4k blocks on the drive anyway, and the "rest" is wasted - so why not just calculate the waste and put it into the padding instead?

Re: Problem with foobar custom encoder

Reply #3 – 2022-10-03 12:53:46

Oh my, read once more before I post ...

* foobar2000 will know the size (in bytes, not in seconds) of the encoded file prior to padding, which makes it feasible to pad to next multiple of, say, 4096; if user requests padding of 8k and that leads to say a remainder of 706 bytes, then pad with 8192+706 = 8898 (leading to an actual padding block of 8894 in FLAC, as it takes 4 bytes to flag a padding block).
This is "costless" and will lead to fewer complete rewrites.
(However, adding pictures ... actual value added might be up to debate, the default was set in an age where yuge tags weren't that common.)

* I think this is better done in Preferences -> Advanced than in a conversion dialog. It is to occur when a full rewrite is triggered, and it applies only to tags at beginning of file, the others don't need padding (? I think? If there is an issue with ID3v1&APEv2 in combination, that is much rarer.)

Re: Problem with foobar custom encoder

Reply #4 – 2022-10-03 14:28:58

Thanks for the replies.
My (wishful) understanding was that "-P 4096" is effective on the output FLAC file (which would be big enough for some additional tags).
But unfortunately, like you explained, the 4K is applied while encoding and afterwards (over-)consumed by transferring tags from the source file, which was FLAC in my case along with a picture block of 110 KB. If I used "-P 200000", then the output file still has a padding block of some 88 KB left...

And +1 to the idea of either having an advanced tagging option or a "when done" option in the converter. And using the file system's cluster
size to "round up" is another good one with storage cost = 0.