[Vorbis-dev] Cover art

[Goran Markovic]

> Yes, please ignore that last bit; it is really about next generation
> stuff for general Ogg cover-art, but the Vorbis-I format (i.e. Ogg
> Vorbis files) is quite rigidly fixed, so the comment tag approach
> you're pursuing is the one that's needed.  What you've already
> implemented is not wasted as the only thing I can really see changing
> is exactly how the FLAC picture block is placed in the tag contents.

The problem is writing of cover art to ogg files. To support writing
of cover art, cover art format should be standardized as soon as possible.
Nero doesn't want to create files with cover art that in future will not be
supported by other software or hardware.

> Is the possibility of linking the art provided by the FLAC structure
> (I can't see it in the format) or was it supposed to be an alternative
> use for the COVERART tag?

It is defined in FLAC structure:
"The MIME type may also be --> to signify that the data part is a URL
of the picture instead of the picture data itself."

> 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"?

FLAC picture block is based on APIC frame in ID3v2. From there come definitions
of picture type and this "-->".

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

In FLAC picture big-endian order is used.

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

I would prefer several comment fields, each containing one picture.
It is much easier for handling.
Order for same cover art type is of course important.

> I've just updated it on my server. You can now get the new re-paged ogg file
> (from Ian Malone, thanks) from http://www.audioranger.com/with_coverart.ogg
> The old one is also still available at
> http://www.audioranger.com/with_coverart_old.ogg

Great! Thanks!
As expected extracting the cover art from the new file works without
any changes in the source code :)

> If you're going to use the flac metadata format, I'd suggest being
> explicit about that in the tag name, with FLAC_PICTURE or
> FLAC_METADATA_BLOCK, etc. instead of a generic COVERART tag. Do you
> propose to include the block header with the internal length, or just
> the picture block?

Hmmm. Another new proposal. Who is responsible here for setting standard?
Who can guarantee that it will not change (unless of course at some point
some big problems arise)?

> If I'm right then the score currently stands at: base64 encoded FLAC
> metadata block in a tag named 'METADATA_BLOCK_PICTURE'.

'METADATA_BLOCK_PICTURE'? Why? Why not stick to 'BINARY_COVERART'
I guess software and hardware players should be checked
again with this new encoding.

P.S. Sorry if I answered something that was already answered by others.