[Vorbis-dev] Cover art

[Ian Malone]

2009/3/31 Mathias Kunter <mathiaskunter at yahoo.de>:
>
>> 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.
>

Yes, I had to double check that the secondary headers weren't a
special case before I sent my first email.  The key point is that
granulepos = -1 means 'unset' and it should occur when that page does
not contain the end of a packet with a defined granulepos. 'Header
page' means something slightly different to 'header section'; in Ogg
the header refers to the bos packets, the pages containing them or the
collection of the bos pages at the start of a concurrent stream
(depending what level of encapsulation you're talking about).  In
Vorbis (and some of the other codecs) there are 'secondary header'
packets with granulepos=0. Header/bos packets never span pages, but
secondary header packets may and can therefore span across
granulepos=-1 pages when necessary.

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

Yes, there's no problem with the large pages and it might make sense
to do this, I was just curious how you were generating pages that size
since it can't be done in the standard Ogg library (unless you change
the page size in the source and rebuild it).


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

Thanks.

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

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.

-- 
imalone