[vorbis-dev] Metadata streams

[Aaron Plattner]

On Wed, Apr 11, 2001 at 04:18:44PM -0700, rillian at telus.net wrote:
> Because you can also chain ogg bitstreams, in practice this isn't much 
> of a limitation. If you need to add a new substream "in the middle" you 
> can just finish off the current streams and then restart a new bundle 
> that includes the additional track. Players should be able to handle 
> this without significant glitching.

Ok.  Although, it seems to me that if you write your player in a modular way it
should be able to handle new streams even if they don't start in a bundle.  And
players that can't handle multiplexed streams should simply ignore the pages
anyway.  I fail to see how this adds all that much complexity.  At least you
have to check page serial numbers and discard ones you don't want, and at most
you have to keep a table of decoder plugin states.  A decoder that deals with
multiple streams has to keep internal state ANYWAY, so it might as well be
modular and extensible.

It's not really that big of a deal, but I thought it'd be neat to be able to
embed arbitrary auxillary streams along with the audio/video streams.  An
example would be coverart for an album, where each image is in its own stream.
These streams would be interleaved with the audio streams, even if one audio
stream ends and another begins.  Otherwise, you have to either cram the rest of
an image at the end of a stream, or wait until the next stream to start the next
image.  This wouldn't be all that useful for files, but it'd be good for
streaming because the auxilliary streams could be generated on the fly and the
user wouldn't have any gaps in the music.

Just my $0.02  :)

> An excellent point, but the other half of this is that if we don't 
> provide test streams with multiple tracks, implementors won't have 
> anything to test against. Not an argument against fixing the vorbisfile 
> side, but that's not entirely sufficient.

Yeah, good point.

-Aaron Plattner


<HR NOSHADE>
<UL>
<LI>application/pgp-signature attachment: stored
</UL>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: part
Type: application/octet-stream
Size: 233 bytes
Desc: not available
Url : http://lists.xiph.org/pipermail/vorbis-dev/attachments/20010411/afbb6a45/part.obj