[Vorbis-dev] Cover art

[Tor-Einar Jarnbjo]

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 
PDF file.

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 
FLAC fields.

- 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://, 
file:// ...?

- 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 
correct order?

Regards,
Tor