[Vorbis-dev] Cover art
tor-einar at jarnbjo.name
Wed Apr 1 13:44:39 PDT 2009
Ian Malone schrieb:
> 2009/4/1 Ian Malone <ibmalone at gmail.com>:
>> 2009/4/1 Mathias Kunter <mathiaskunter at yahoo.de>:
>>>> arbitrary binary content is most likely not a valid UTF-8 sequence and may
>>>> cause current software to fail.
> To be honest software should be robust against that for security
> reasons if nothing else, but we should keep to the spec.
Sure, but the robustness may just as well be to reject the file, which
is also a kind of failure if you expected the audio to be played :)
> So what we have is base64 encode FLAC block, place in contents of
> BINARY_COVERART tag.
> On the wiki the points against the Audio Shell etc. COVERART approach were:
> * no additional information like a description about the cover
> art is provided,
This is not related to Base64 vs direct UTF-8 encoding of the data.
> * the base64 string is displayed within many tag editors as plain
> text because of their missing support for this "COVERART" field
As shown, the UTF-8 encoded data will be shown if the software treats \0
correctly as a control character and not an end-of-string marker. Trying
to display the UTF-8 encoded binary data as a string is potentially more
risky than displaying the Base64 string, since the UTF-8 string will
contain control characters.
> * it may breaks the playback on hardware players because of a
> large vorbis comment header
This is also a potential problem with the FLAC structure.
> * Old C / C++ based implementations don't display the binary data
> as string since it always starts with a zero byte at the first
> position, which is an empty string when interpreted as UTF-8.
As shown with WinAmp, the leading \0 may however cause existing software
to completely ignore the comment and remove it, if the file for some
reason is written back to disk.
> * All common picture file formats are supported (jpg, gif, whatever).
This is actually not clear from the FLAC specification. Which MIME types
is a compliant Vorbis player required to support? For some picture types
like cover art or leaflet pages, it might even be reasonable to embed a
Unfortunately, the FLAC specification is not very specific and and
allows for quite a few ambiguities and implementation specific details:
- The byte order is not clearly stated. It's only mentioned in the
METADATA_BLOCK_VORBIS_COMMENT field description, that that field uses
little-endian order as opposed to the "usual" big-endian order in other
- Why is "-->" used as a pseudo mime type to indicate that the binary
picture data contains a URL to the image instead of the registered MIME
type "text/uri-list"? Which character encoding is used for the URL?
Which protocols must be supported by a Vorbis player: http://, ftp://,
- How should the fields "width", "height", "colour depth" and "number of
colours" be set for image formats, to which they don't apply? E.g. SVG,
to which none of the fields are applicable, or "colour depth" to
bi-colour (pure black and white) image formats. Are these fields
reasonable at all, if an external image is linked from a URL, since the
image may be replaced and not match the embedded information anymore?
And at last, a specific question to Vorbis integration:
- How should multiple images be embedded? Several METADATA_BLOCK_PICTURE
structs concatenated in one comment field, or several comment fields
with the same name, each containing one METADATA_BLOCK_PICTURE struct?
Some of the picture types indicate that the image order is relevant,
e.g. leaflet pages. If each image is put in separate comment fields,
will e.g. libvorbis (or other Vorbis decoders) retain the comment field
order, so that supporting software is able to show the images in the
More information about the Vorbis-dev