[Vorbis-dev] Cover art

[Ian Malone]

2009/4/1 Goran Markovic <skromnibog at gmail.com>:
> 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.
>

The updated file is not significantly different; it fixes a flaw in
the Ogg encapsulation which is relevant to seeking in the stream for
timepoints.  The cover art format is the same, though it now appears
it needs to be tweaked a little.

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

For reasons already covered it looks like base 64 will be the best
choice.  The representation is invariant under UTF-8 so it will not
get mangled at some point by confused processing and wont violate the
existing spec.

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

Yes, please ignore that last bit; it is really about next generation
stuff for general Ogg cover-art, but the Vorbis-I format (i.e. Ogg
Vorbis files) is quite rigidly fixed, so the comment tag approach
you're pursuing is the one that's needed.  What you've already
implemented is not wasted as the only thing I can really see changing
is exactly how the FLAC picture block is placed in the tag contents.

I think we should be able to finalize this pretty quickly.  How about
the list settles the details on the other thread, we update the wiki
and let you know once there's a consensus?  I don't think there's much
left to discus, what kind of timeframe do you have?

-- 
imalone