[ogg-dev] Album art - requirements

[Michael Crawford]

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

Tracks downloaded from The Series Of Tubes *really* need to be
*complete*, and not require separate downloads to make a complete
item.  This is especially important when the track is distributed by a
music hosting service or eCommerce site - most don't provide *any* way
to supply cover art in a separate file.

Take mine for example - I don't yet have art in the Oggs or the FLACs,
but I do in the MP3s and AACs:

http://www.geometricvisions.com/music/

(I'll add the cover art to my Oggs and FLACs when I update my Creative
Commons license to the current version.  Quite likely that won't be
until after this discussion (hopefully) reaches a harmonious
conclusion, as it turns out to be a *lot* more work than one would
naively expect.)

>> It was my impression that it is mostly header-type content, i.e.
>> concerns the full file rather than segments of it.

That would be the case if the file only contained tracks from a single album.

> It makes sense to reference it per-chain-segment in an Ogg context.

That would be best if the file contained *multiple* albums, one per
chain.  Uncommon, I imagine, but I could see good reasons for doing
it.

> When I've suggested OggMNG (or rather OggJNG and OggPNG) for cover
> art in the past it was in that sense that it be a 'header only'
> stream, the way skeleton is.

Again, I *must* emphasize the need to support vector graphics for
high-quality printing.  A bitmap at the resolution required for
printing would be excessively large.  Screen-resolution bitmaps look
absolutely *terrible* when printed.

I favor PDF, but SVG would be acceptable if it could be compressed -
being an XML application, SVG is *very* verbose.  I recommend bzip2
for compressed SVGs, as download size is critically important for
high-traffic websites.  bzip2 is the best compressor I know of whose
format is both publicly documented and that allows Open Source
implementations - that is, it's not encumbered by patents.

Are there any better compressors, that are both documented and unencumbered?

> I'd suggest defining an album-art reference in the skeleton fishhead
> that points to such a stream. We have the OggMNG spec for embedding
> png and jpeg images already, and svg could use a similar embedding to
> what we already do with cmml. But if it is in fact header only, it
> might be reasonable to put just anything in there, including JFIF and
> PDF. As usual it comes down to what people are willing to support.

I'm quite happy to support *every* format that we can agree on in Ogg
Frog.  When it's released, it will be Free Software under the GNU GPL,
and so could serve as sample code for other implementations:

http://www.oggfrog.com/free-music-software/

(But again note there won't be anything to download until I reach
alpha, several months from now.)

> What speaks against just putting hyperlinks into the header?

What if the original website goes offline, never to return?  What does
one do if one can't connect to the Internet?  It would really be a
drag to play such a track for the very first time on a hardware player
when one is on a walkabout in Australia!

> Or a compromise solution of only allowing limited size images into the
> header with full-scale images required to be hyperlinked?

That would be OK if PDF were allowed; I don't know whether SVG would
be compact enough in the case of my album, even it if were compressed.

> 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

This gets my vote, but I suggest placing some kind of plain-text
warning just before the binary data, to inform the user that what
follows is an image.  Otherwise dumping out all the vorbiscomments as
text would be *very* confusing.

> The only possible problem is support of existing software / hardware players...
> 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.

This could easily be verified by creating a sample file then posting
it on the xiph.org website.  We could all try the track out on all the
players each of us possesses, both hardware and software, then report
back here, or record our results in the Xiph Wiki.

However, I suggest providing *four* zero-bytes at a four-byte aligned
position, to head off trouble with players that support 32-bit
Unicode.

Intrepidly,

Mike
-- 
Michael David Crawford
mdcrawford at gmail dot com

   Enjoy my art, photography, music and writing at
http://www.geometricvisions.com/
        --- Free Compact Disc ---