[Vorbis-dev] Cover art
tor-einar at jarnbjo.name
Thu Apr 2 13:59:25 PDT 2009
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?
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
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.
More information about the Vorbis-dev