[vorbis-dev] clarifications on comments spec

Scott Wheeler wheeler at kde.org
Tue Jul 1 17:22:57 PDT 2003



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 01 July 2003 10:01, Beni Cherniavsky wrote:

> http://www.xiph.org/ogg/vorbis/doc/v-comment.html is not entirely
> explicit on this.  It only says you must have one "framing bit" equal
> to 1 after the comments - what for?  The natural way to read it would
> be that if you do have the framing bit, everything after it should be
> ignored -- but it doesn't take too much squinting at it to decide to
> do anything else (like complaining) when the packet doesn't end there.
> If the intent is that such padding is legal, could this be written
> there explicitly?

Would be nice.  :-)  And I'll try to produce a test case so that this can be 
tried on current decoders.
 
> If you want to strain it, you could always keep lengthening following
> pages until you catch up with the page number of the original file, so
> that the rest can be trivially bit-copied.  This is not necessarily a
> good idea since long pages require bigger buffers (=> higher latency)
> at the decoder and reduce the fault-tolerance and seek effeciency(?).

Sounds nasty.  ;-)  Probably wouldn't be that desperate for speed; I mean I'm 
trying to get this thing optimized, but that's an uncommon enough case that I 
think I'll be happy if it just doesn't barf on it.  :-)

But the converse is a more interesting question -- what to do when you run 
across a packet that's split into 8 packets just because somebody really 
thought that 255 byte packets were really cool.  Repaginate?  Leave empty 
frames around?  Split them up just like he did?

> Besides, all such tricks require deeper tying of the comment-handling
> to the Ogg framing implementation than if you just take the Ogg
> packets abstraction as opaque to your needs.  And the later will
> be easier to adapt to parsing comments from Ogg-less RTP streams, if
> these are relevant to your TagLib.

Two points there -- if I presume that I have a streaming implementation 
(outside of TagLib) that's passing TagLib raw Vorbis packets, really this is 
pretty easy.  Right now I haven't made this particularly abstract just 
because for just parsing comments, well, basically all I need is a counter 
that can go up to 2 and about 3 calls to TagLib::ByteVector::mid(...) to get 
the comment out.  I have the benefit of not caring about anything that 
happens after that and these streams are read only, so...

Second, if dirty speed hacks will significantly improve the common case 
tagging functionality -- I'm all over it.  Whereas something like libvorbis 
has good reason to be generic since it's expected to do a lot more than 
tagging, I on the other hand just care about the meta data; that being the 
function of TagLib.

> In any case, I don't think re-paginating the file makes much
> difference if you are rwriting it completely anyway.  If you normally
> avoid this by padding, you also avoid re-pagination.

Wall-clock time, probably not since your biggest limitations will be in IO.  
But lets say you're on a big-endian system and having to byteswap every 
buffer parse, write, byteswap back and write, things start to get a little 
heavy.  Of course this could (and I may do so) be hacked for speed to use 
#ifdef'ed endian specific code at that level, but it would be nice to be able 
to avoid that.

Cheers,

- -Scott

- -- 
Audience Member: "What is the book [on CS] that you most want to read?"
Donald Knuth: "It's not `The Art of Computer Programming for Dummies.`"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/AiXhQu0ByfY5QTkRAmD9AKC7wtWF2Qd0oyLEvymUiLkFgKTpxQCffRj8
ugT1t9oyWemFMgiltxVMCD0=
=CYjm
-----END PGP SIGNATURE-----

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.



More information about the Vorbis-dev mailing list