Re: Cover art

Ian Malone schrieb:
> 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.

You got me right. Having a specification with wordings like "based on" 
and "similar to" is not too clever and may end up with several 
incomaptible implementations. Ideally, it also specifies how to treat 
unexpected or obviously incorrect values, or what to do if redundant 
fields contain contradicting values. E.g. in case of the FLAC structure 
something like: The width/height fields in the data structure are purely 
for informational purposes and may be 0, if the value is not known. The 
values must be ignored if the actual image dimensions are different.

To be honest, the ID3V2 specification seems to be a better choice for 
defining the format of the embedded image data. Are there any reasons 
for using the FLAC struct instead of the struct defined in the ID3V2 
spec, section 4.15?

http://www.id3.org/id3v2.3.0#head-70a65d30522ef0d37642224c2a40517ae35b7155

At least after taking a brief look at it, it didn't leave just as many 
unanswered questions to me as the FLAC specification did.

It does not have the IMHO unnecessary fields for image data (widht, 
height, etc). If an implementation has a decoder for the specified image 
format, it's most likely just as easy for it to obtain the image 
parameters from the actual image data if it really needs to know it 
before attempting to decode the image. Since it cannot rely on the data 
in the struct fields to be correct, it's actually the only way to 
securely obtain e.g. the image dimensions. Also, the character encodings 
are clearly specified. It's of course not ideal that the URL encoding is 
locked to ISO-8859-1, so that it's e.g. not possible to refer to a local 
file with other characters in the file name, but it's at least better 
than not defining the encoding at all, as is the case with the FLAC 
specification.

If it's adopted, I think the Vorbis specification should however refer 
to v2.4 of the ID3V2 spec to allow UTF-8 and UTF-16 encoding of the 
description string. V2.3 only specifies UCS-2.

Tor