[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