[Vorbis-dev] Cover art

[Mathias Kunter]

>Okay, no '\0'.  It's also easier to transform with command line tools,

>which is nice for prototyping and things

Yes.


> The FLAC block is definitely unclear. [...]

As already posted before, it bases on the ID3v2 tag. To clarify:

--> The width, height, color depth, number of used colors (and for robust software, also the MIME type) is only informational. A program should never use those values to do the actual image decoding, but parse the given binary picture data instead! Those fields are useful when someone wants to display information about the included picture without decoding it, but nothing more. This has nothing to do with Vorbis-compliancy or something like that. Cleanly written programs should however write correct values to those informational fields, of course.

--> The usage of the ASCII string "-->" as (pseudo) MIME type implies that the image is linked. The link is an ASCII string. It usually only links files on the local file system either absolute or relative (for example "picture.png" or "../picture.png", as specified within ID3v2). The string usually doesn't start with "file://", but robust software should check if it's there or not. Other resource locations than the local file system are not supported by default (security issues, lacking support within other software etc.)

--> FLAC block fields are big endian (as already posted earlier).

--> Multiple pictures should result in multiple comment fields, as it is usually done within ogg vorbis. The order of the comments should be preserved, which also preserves the order of the embedded pictures then.


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

Yes.
METADATA_BLOCK_PICTURE is the name for the FLAC container. We however could also keep the BINARY_COVERART name suggestion from the wiki. When the tag names are displayed within old software, users hopefully know that they shouldn't edit a field named "BINARY_COVERART" :-)

If there aren't any further concerns, then I would say we have found a consensus. Who is responsible for updating / creating official specifications for ogg Vorbis?

Mathias