It's interesting that after adding over 33 MB of padding (with flac.exe) "metaflac --list" shows no padding block at all, although the padding obviously wasn't used entirely (judging by the increase in size when embedding the images with metaflac). Also when examining the flac file with an hex editor there are still about 32 megabytes of zeros in the flac file...
When filtering seektable and picture blocks (metaflac --list --except-block-type=SEEKTABLE,PICTURE) the list output gets quite short:
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 0 bytes
maximum framesize: 0 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 126655200
MD5 signature: 00000000000000000000000000000000
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.1.4 20070213
comments: 0
Since the streaminfo block looked the same before embedding the pictures, it seems to me that flac.exe already screwed up this file when creating it with this large padding. Here the output after encoding without extra padding:
METADATA block #0
type: 0 (STREAMINFO)
is last: false
length: 34
minimum blocksize: 4096 samples
maximum blocksize: 4096 samples
minimum framesize: 1326 bytes
maximum framesize: 13798 bytes
sample_rate: 44100 Hz
channels: 2
bits-per-sample: 16
total samples: 126655200
MD5 signature: 8ed6a82d92937bab05a3e693ccedfc1f
METADATA block #2
type: 4 (VORBIS_COMMENT)
is last: false
length: 40
vendor string: reference libFLAC 1.1.4 20070213
comments: 0
METADATA block #3
type: 1 (PADDING)
is last: true
length: 65536