> is coverart a header-type content or a time-aligned type content?
> > Well, it's collection-level metadata, so it doesn't belong in
files
at all. :)
Well right, but the problem is that external coverart files are unhandy (broken
links!!, streaming...)
Users therefore want to embed them most times, as you can tell from other audio
file formats: the majority of cover art is embedded, not linked.
>As usual it comes down to what people are willing to support.
Since MP3 and FLAC have well-supported standards about cover art, why not simply
adopting this for OGG too? Placing the binary coverart structure from
http://flac.sourceforge.net/format.html#metadata_block_picture within a vorbis
comment would have the following benefits:
--> Easy to use for developers since the identical (or similar) structure is
also used by FLAC and MP3, which means that chances are good that people and
software programmers are willing to support this.
--> The cover art can either be linked or embedded within the stream.
--> All common picture file formats are supported (jpg, gif, whatever)
--> Many different picture types are supported (front cover, back cover...)
The only possible problem is support of existing software / hardware players.
Since it would be stored within a vorbis comment, incompatible software could
try to display this binary tag as text comment. However, if you check the
specification of the coverart tag structure you can see that the first three
bytes of this tag are always 0 because of unused bytes. This would mean that all
C-based applications wouldn't display this "string" anyway because
it terminates at the very first position with a \0 sign.
What do you think?
-m
