Padding length when writing files with Picard

MusicBrainz Picard
1

I’m wondering why, when I rewrite flac files with Picard, e.g. to embed a cover art (Picard offers an option to automatically fetch resized cover art from MB and embed it into files), the padding block becomes so huge.
Consider an example:
I have a file A.flac that has the following blocks:

METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 967 bytes
  maximum framesize: 21799 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 24
  total samples: 8457984
  MD5 signature: fb67539721aab2113e63c09e437a722e
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 272
  vendor string: reference libFLAC 1.3.4 20220220
  comments: 8
    comment[0]: Copyright=P.Kreminski/V.Artyushenko
    comment[1]: file=autumn.flac
    comment[2]: title=Love, Money, Rock'n'Roll
    comment[3]: artist=The Datfeelz
    comment[4]: filename=datfeelz_love_money_rocknroll.flac
    comment[5]: ALBUM=Love, Money, Rock'n'Roll OST
    comment[6]: DATE=2022
    comment[7]: TRACKNUMBER=02
METADATA block #2
  type: 1 (PADDING)
  is last: true
  length: 4095

Notice that the padding block has a length of 4KiB.

The I add cover art to the file A, and since the size of the image exceeds the padding length, the file gets rewritten. The new file has a padding length of 42KiB:

METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 967 bytes
  maximum framesize: 21799 bytes
  sample_rate: 44100 Hz
  channels: 2
  bits-per-sample: 24
  total samples: 8457984
  MD5 signature: fb67539721aab2113e63c09e437a722e
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 272
  vendor string: reference libFLAC 1.3.4 20220220
  comments: 8
    comment[0]: FILENAME=datfeelz_love_money_rocknroll.flac
    comment[1]: DATE=2022
    comment[2]: ARTIST=The Datfeelz
    comment[3]: TRACKNUMBER=02
    comment[4]: TITLE=Love, Money, Rock'n'Roll
    comment[5]: FILE=autumn.flac
    comment[6]: ALBUM=Love, Money, Rock'n'Roll OST
    comment[7]: COPYRIGHT=P.Kreminski/V.Artyushenko
METADATA block #2
  type: 6 (PICTURE)
  is last: false
  length: 64821
  type: 3 (Cover (front))
  MIME type: image/jpeg
  description: 
  width: 500
  height: 500
  depth: 0
  colors: 0 (unindexed)
  data length: 64779
  data:
    00000000: FF D8 FF E0 00 10 4A 46 49 46 00 01 01 02 00 26 ......JFIF.....&
    00000010: 00 26 00 00 FF DB 00 43 00 05 03 04 04 04 03 05 .&.....C........
    00000020: 04 04 04 05 05 05 06 07 0C 08 07 07 07 07 0F 0B ................

    ~~~ LOTS MORE LINES HERE ~~~

    0000fce0: 9c 43 65 ea a4 40 56 ab 1c e2 72 c6 91 12 96 ae .ce..@v...r.....
    0000fcf0: 78 96 d9 49 21 85 6a b6 d8 96 ca 43 79 45 5b 6c x..i!.j....cye[l
    0000fd00: 4e 59 40 e5 17 cf 0b 22 c1 ff d9 00 00 00 00 00 ny@...."...     
METADATA block #3
  type: 1 (PADDING)
  is last: true
  length: 42291

But why? It’s undesireable, I want my paddings to be 8KiB at most. 38KiB per file is too much to waste for no reason.

2

If padding needs to be adjusted the default implementation of mutagen adds a padding of 1KiB + 0.1% of the data after the padding. Your padding indicates that there are 41267000 bytes after the padding, which is ~39 MiB, which sounds about right for FLAC.

See https://github.com/quodlibet/mutagen/blob/30f373fa6d56e1afa17d48a0c6f3e111267fbd32/mutagen/_tags.py#L43-L63

2 Likes