[Vorbis-dev] Cover art

[Mathias Kunter]

> The granulepos 0 errors are probably due to the comment packet not being
> split up correctly (the pages carrying fragments before the end should
> be granulepos -1)

Well OK, I've reviewed my code and I actually write a granulepos of 0 to all header pages. I did this because the specification explicitly says that
"The granule position of these first pages containing only headers is zero." and "Granule Position must always increase forward or remain equal from
page to page, be unset, or be zero for a header page."

This is specified at

http://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-130000A.2
(the 4th point of the list)

and

http://xiph.org/ogg/doc/ogg-multiplex.html
(section "Granule Position", "Description", first point of the list)

It however seems that also the non-finishing *header* pages must have a granulepos of -1, I'm going to fix this within my library. I haven't been aware of that, and in my opinion the specs are misleading in that point.


> I'm a bit puzzled about the structure: how did you do the

> Ogg encapsulation?  When I try this with ogg_stream_pageout I get the
> comment packet split across 4kB pages (because that's what libogg's
> pageout aims for), your example has about 6 pages, which is what you'd
> expect for splitting the image across maximum size pages.

My tagging library actually splits the comment header across the maximum page size. I thought this would be the best behaviour to avoid re-writing the entire file: if one removes the included image again, I can
a) simply shrink the last page of the comment header without touching any other page, or
b) replace no longer needed pages with null pages so that I don't have to change the page sequence number, so that I don't have to re-compute the checksums for all pages within the file.

Or is there any reason why I shouldn't do it like this?

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

> Actually on the subject of the picture block, it's UTF-8 encoded.
> After looking at the comment header spec. again I believe this is
> correct, but it needs a note in the cover-art proposal that this is
> what happens.

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


Mathias.