Cover art

I managed to find some time and implement extracting cover art from
the demo file.
I have some more questions:

> > Okay, I've basically just run this through vorbiscomment with the -a
> > flag and no tags specified, which results in re-paging (I was going to
> > write my own tool to do it, but the large initial pages make that
> > difficult without re-paging the whole stream).  Have checked that it
> > passes oggz-validate, plays and still contains the picture block.
>
> OK, I'm going to update the test file on my server.

Where can I find this file? The one at
http://wiki.xiph.org/index.php/VorbisComment#Cover_art is still the
same.

> > Well the ogg vorbis specs say that comments are UTF-8 encoded, but that makes no sense anyway when
>> placing binary data into the vorbis comment. The description of the picture within the binary data itself is also
>> UTF-8 encoded, as specified within the FLAC comment header structure at
>> http://flac.sourceforge.net/format.html#metadata_block_picture
>
> Yes it's not ideal, but I'm reasoning on the basis that all the specs
> dealing with the vorbis comment headers (or its clones in other
> formats) require the comment contents to be UTF-8 encoded.  This
> presumably means the picture description is UTF-8 encoded twice.

> I was wondering about this myself, as the proposal on
> http://wiki.xiph.org/index.php/VorbisComment didn't mention anything
> about UTF-8 encoding the binary content of the coverart structure,
> although it's done in the demo file. If not doing it, arbitrary binary
> content is most likely not a valid UTF-8 sequence and may cause current
> software to fail.

This should be mentioned explicitly for "BINARY_COVERART" on the page
http://wiki.xiph.org/index.php/VorbisComment#Cover_art.

One must also have in mind that using Microsoft's CA2W will not work
for BINARY_COVERART. It works for all other comments (text) because 0
is terminating string for both UTF_8 and for Unicode. Code which uses
CA2W for converting comments from UTF_8 to Unicode will thus have
problems with BINARY_COVERART.

>> 33%. Even if older software displays the Base64 comment value as a string,
>> it's unlikely that the comment is ignored completely, as is the case with
>> e.g. WinAmp. Not only is the BINARY_COVERART not shown in the file info
>> dialog, but it's removed from the file if other comments are edited with
>> WinAmp.

This is probably a bug that should be fixed in WinAmp. They shouldn't
allow changes in comments that are not supported by the software, but
leave them untouched.

> Completely off-message suggestion follows:
> It's things like this that really argue for the sense of doing the
> multiplexed approach...
>
> How about: FLAC picture block packets + some kind of modified FLAC bos
> to identify as a cover art stream? Compromise between quick-hack and
> technically elegant. (For those people upset by the other off-message
> suggestion that both PNG and JNG could be encapsulated following the
> MNG-Ogg format.)

Talks like this make me rethink about supporting cover art for ogg in
next Nero release. I hope that support for cover art in ogg will be
definitely standardized very soon.