Block is too long to write

OliveChicago · 2018-01-31 15:49:15 UTC

Is this a limitation of the file format, Picard and its various resources, or a bug?

D: 09:25:36 Saving file u’D:\FLAC-Rips\They Might Be Giants\Flood\02 They Might Be Giants - Birdhouse In Your Soul.flac’
E: 09:25:37 Traceback (most recent call last):
File “picard\util\thread.pyo”, line 46, in run
File “picard\file.pyo”, line 210, in _save_and_rename
File “picard\formats\vorbis.pyo”, line 220, in _save
File “mutagen_util.pyo”, line 152, in wrapper
File “mutagen_util.pyo”, line 123, in wrapper
File “mutagen\flac.pyo”, line 857, in save
File “mutagen\flac.pyo”, line 154, in _writeblocks
File “mutagen\flac.pyo”, line 137, in _writeblock
error: block is too long to write

D: 09:25:37 Updating file <File u’02 They Might Be Giants - Birdhouse In Your Soul.flac’>

Vanilla file is 23 MB. Embedding the associated art work will add about 150MB to the FLAC, bringing the total package to about 200 MB.

Ya’ll might be saying “That’s insane!!” And I’d agree 100 times over. Traditionally what I’ve done is grab all of the highest quality artwork for a track using Picard. Then in MediaMonkey I’d reduce anything larger than 1500 x 1500 and embed into the track.

This is the first time I’ve ever encountered this situation.

Side note / Related question: I looked around a bit but it seems to me that Picard and it’s various scripts and plugins do not offer a resize routine. Am I correct?

Zas · 2018-01-31 16:47:35 UTC

The error is emitted by mutagen:

github.com

quodlibet/mutagen/blob/master/mutagen/flac.py#L137


    size = len(datum)
    if size > cls._MAX_SIZE:
        if block._distrust_size and block._invalid_overflow_size != -1:
            # The original size of this block was (1) wrong and (2)
            # the real size doesn't allow us to save the file
            # according to the spec (too big for 24 bit uint). Instead
            # simply write back the original wrong size.. at least
            # we don't make the file more "broken" as it is.
            size = block._invalid_overflow_size
        else:
            raise error("block is too long to write")
    assert not size > cls._MAX_SIZE
    length = struct.pack(">I", size)[-3:]
    data.append(code)
    data += length
    data += datum
    return data


@classmethod
def _writeblocks(cls, blocks, available, cont_size, padding_func):
    """Render metadata block as a byte string."""

github.com

quodlibet/mutagen/blob/master/mutagen/flac.py#L96




_distrust_size = False
"""For block types setting this, we don't trust the size field and
use the size of the content instead."""


_invalid_overflow_size = -1
"""In case the real size was bigger than what is representable by the
24 bit size field, we save the wrong specified size here. This can
only be set if _distrust_size is True"""


_MAX_SIZE = 2 ** 24 - 1


def __init__(self, data):
    """Parse the given data string or file-like as a metadata block.
    The metadata header should not be included."""
    if data is not None:
        if not isinstance(data, StrictFileObject):
            if isinstance(data, bytes):
                data = cBytesIO(data)
            elif not hasattr(data, 'read'):
                raise TypeError(

https://tickets.metabrainz.org/browse/PICARD-400

github.com/quodlibet/mutagen

flac: fix save() failing in case we recovered a too large flac image block. (Fixes isse #226)

In case the file contains a flac image block which has a invalid block size
and the containing data is larger than what can be contained in a picture block
we successfully load the file since we ignore the block size and use the
picture size instead. When saving, this will fail as we want to write
the correct block size back which is in this case too large. Instead
remember the incorrect block size in case the real block size was
too large and save it back as is. This allows us to save everything we load
and write invalid flac files only if the source was invalid is well.

by lazka on 02:44PM - 04 Jul 15

changed 2 files with 74 additions and 8 deletions.

Embedding such huge image is very likely to cause issues, not only in Mutagen or Picard, but in most apps.
Plus “That’s insane!!”

OliveChicago · 2018-02-01 05:36:50 UTC

It is insane for sure.

Am I correct in my findings though? There is nothing for Picard that can size album art?

rdswift · 2018-02-01 06:02:30 UTC

The only thing that I am aware of is an option for only grabbing the 500 x 500 px images from the CAA. That won’t help with other sources though.

Another option might be to have Picard save the downloaded artwork files to the output folder rather than embedding them right away. I couldn’t tell from your first note, but you may already be doing that as part of your MediaMonkey process.

OliveChicago · 2018-02-01 08:18:23 UTC

Short answer for the tl;dr viewers:

I try to keep my album art no lower than 1000x1000. Overkill on a phone? Yep. But if you start playing tracks on a TV, that 300 x 300 CD cover starts looking a bit jaggy. If I can’t readily find something 500, I start scouring the internet. If what I get is over 1500 x 1500, I resize to that and then let MM package it all together.

Speaking of album art… If Picard could ever query this site (http://www.coveralia.com) 5 million thumbs up. Sooooo many of the albums there are complete scanned inserts and media, as sometimes even promo stuff that comes tossed in the case.

Long-winded

Picard is the only tool that I am aware of that has a simple, clean, yet flexible method for grouping tracks into complete albums and iconing them with colors reflecting the albums various states of completion.A novel concept in the age of streaming, but I digress.

MediaMonkey is a steal when I think about what they ask for a gold license when compared to everything you get in return. Not just from the actual program itself, but also what the many contributors bring ways of the various add ons.

I could stomach my way through the clunky methods offered for tag fixing and album art gathering, but in MediaMonkey, at least that I’ve been able to find, is there a single glance that tells me is this album is a complete album or not.

Zas · 2018-02-01 09:50:32 UTC

If this site was providing a clear webservice API for doing so, may be someone could implement it as a plugin.
If this site had clear informations about cover art and how they related to each album, and the process used to verify this…
If this site was actually using MusicBrainz as backend, it would be even simpler.

Note: this site uses iTunes as source for digital cover arts (see Aviso legal) but doesn’t provide any information about the rest (well, i don’t read spanish, so i may be wrong).

You could implement a plugin for Picard able to use this site as source for cover art, but, at first glance, matching MBID to releases on this site is the problem, as they don’t provide enough informations to do it properly. One would have to do “fuzzy” matches, based on title/artist/format/year.

About size of cover art, currently CAA propose 3 sizes: original size (which can be anything), thumbnail limited to 500x500px, thumbnail limited to 250x250px
There were some discussion about supporting bigger thumbnails : https://tickets.metabrainz.org/projects/CAA/issues/CAA-88

aerozol · 2018-02-02 08:52:50 UTC

I have it as big as possible, but use a player that pulls the cover from the album folder. No need to duplicate the data into every file imo

OliveChicago · 2018-02-02 15:35:25 UTC

That bit about fuzzy matches makes a lot sense. I guess I never thought about it much past the brainless “Find my cover art” button clicking. Probably also explains why I appreciate the results from finer tools like Picard over many of the other.

Thank you sir!

OliveChicago · 2018-02-02 15:42:06 UTC

What do you do for a situation where you are grabbing various tracks from various artists and various albums for a playlist to be tossed on your phone?