Re: Cover art

2009/4/2 Mathias Kunter <[email protected]>:
>

>> The FLAC block is definitely unclear. [...]
>
> As already posted before, it bases on the ID3v2 tag. To clarify:
>

It might be, but if I had to guess what Tor-Einar is getting at, it's
that the wiki currently says FLAC block, with a vague mention of
similarities to ID3V2 and the FLAC block spec itself only mentions
ID3V2 regarding the APIC picture type.  So far as Xiph standards go
all we can do is set out a clear specification, if something is widely
enough used and established an RFC can be submitted.  The point of all
this apparently tedious discussion is that someone wanting to actually
implement the thing can look at what's on the wiki and know what they
need to do, what bits they should support, what extra they might want
or be able to do and what the best way to handle errors or
inconsistencies is going to be.

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

I'd suggest conforming writers MUST write correct values to these
fields, readers MUST NOT expect it to be accurate, but MAY still
decode the binary data if it does not match them.  I think a decoder
might have quite valid reasons for not decoding the picture on the
basis of either the dimensions given by the FLAC block not being
supported or halfway through decoding finding that the image does not
match what it expected.

I guess your 'vorbis-compliancy' comment means the file should still
play even if the picture block has problems and that's probably the
right approach.

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

Following ID3V2 the link would be ISO-8859-1. Relative URLs are by
definition the same protocol type as the source document (here that
would be file://, though not for streaming Ogg, one of the reasons I
think this should be left somewhat open for the time being) and do not
include the protocol type in the URL.  Hence "picture.png" and
"../picture.png" are relative links whereas "file://picture.png" can
only be an absolute link.  Again I think leave this unspecified for
the time being except to strongly recommend against retrieving remote
protocols, make retrieving it a MAY and again SHOULD NOT actually
expect the link target to exist.  That ISO-Latin bit is annoying, but
not much can be done I think as this is the section which would most
benefit from handing off to ID3V2 handling routines.

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

We can't really mandate the order of comments being preserved without
updating the vorbiscomment spec itself, but they do get preserved by
the comment libraries I've seen and really I doubt there will be very
many people who every find there is a problem here.  A note to the
effect that this is the mechanism relied on for picture ordering
should be sufficient.

>
>
>>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" :-)

Anyone editing a field called METADATA_BLOCK_PICTURE filled with a
base 64 string isn't going to be stopped because it has binary in the
name. I like the idea of tying it to the data type, not least because
it makes googling for it easier.

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

Whoever is willing to lay this all out clearly in the wiki and provide
necessary code for the reference library...

If no-one is keen then I'll take the vorbiscomment and ogginfo
patches.  They are lower priority than actually updating the wiki, but
I might be able to do that this evening.

-- 
imalone