On Tue, Mar 07, 2006 at 12:10:57PM -0500, Monty wrote:> On Wed, Mar 01, 2006 at 10:36:38PM +0000, Ian Malone wrote: > > I assume what this all means is there's no desire for any kind of stop- > > gap libvorbisfile that does the "vorbis out of any otherwise valid Ogg > > stream"[1], and that anything along these lines will wait until Oggfile. > > Well, vorbis-only vorbisfile is what we're talking about. What Sylvia > mentioned was that we need to decide what to do if there's more than > one concurrent Vorbis stream but we're still talking about the > Vorbis-only case. > > > [1] The motivation for this would be to allow current players to play > > Annodexed Ogg Vorbis without noticing. > > Yes, there are a few applications that boild down to that (eg, playing > only the audio from an A/V file in general).Monty, (afaik) Ian is working towards patching libvorbisfile to read the first vorbis logical bitstream in an Ogg file, eg. to allow playing just the audio from a theora+vorbis file. ie. libvorbisfile continues to handle vorbis only, the change in behaviour is that it would no longer fail on files which are not vorbis-only. Do you have anything against this? Conrad.
Conrad Parker wrote:> On Tue, Mar 07, 2006 at 12:10:57PM -0500, Monty wrote: > >>On Wed, Mar 01, 2006 at 10:36:38PM +0000, Ian Malone wrote: >> >>>I assume what this all means is there's no desire for any kind of stop- >>>gap libvorbisfile that does the "vorbis out of any otherwise valid Ogg >>>stream"[1], and that anything along these lines will wait until Oggfile. >> >>Well, vorbis-only vorbisfile is what we're talking about. What Sylvia >>mentioned was that we need to decide what to do if there's more than >>one concurrent Vorbis stream but we're still talking about the >>Vorbis-only case. >> >> >>>[1] The motivation for this would be to allow current players to play >>>Annodexed Ogg Vorbis without noticing. >> >>Yes, there are a few applications that boild down to that (eg, playing >>only the audio from an A/V file in general). >> > (afaik) Ian is working towards patching libvorbisfile to read the first > vorbis logical bitstream in an Ogg file, eg. to allow playing just the > audio from a theora+vorbis file. > > ie. libvorbisfile continues to handle vorbis only, the change in behaviour > is that it would no longer fail on files which are not vorbis-only. >Pretty much, thanks for translating (although 'working towards' is a rather strong phrase). Yep, Vorbis out of A/V, Vorbis out of Annodexed audio (I recently pointed someone looking to do bookmarking on an audio stream at Annodex), Vorbis out of hypothetical Vorbis + metadata. Barring logical impossibilities I can do the simple bit: extending vorbisfile to pick out a vorbis stream from each link in a chain (but I won't have a free weekend to look at it for at least a month). Re-reading Monty's email: when you talk about vorbis-only vorbisfile and the concurrent vorbis stream case do you mean vorbisfile will need to be able to choose? I'd been thinking (as above) about cases where there is a Vorbis stream in with other stuff, the first two examples are realities. The obvious applications for multiple concurrent Vorbis streams are the same as for DVD: multiple languages, commentaries, scores (possibly needing mixing). Deciding what to play needs application involvement; how much should vorbisfile be able to do, and how much should wait until oggfile (and how much should be left to media players that understand all the complexities involved)? -- imalone
----- Original Message ----- From: "Ian Malone" <ibmalone@gmail.com> To: <ogg-dev@xiph.org> Sent: Friday, March 10, 2006 8:42 AM Subject: Re: [ogg-dev] oggfile, skeleton and vorbis tools> Re-reading Monty's email: when you talk about vorbis-only vorbisfile and > the concurrent vorbis stream case do you mean vorbisfile will need to be > able to choose? I'd been thinking (as above) about cases where there is > a Vorbis stream in with other stuff, the first two examples are > realities. The obvious applications for multiple concurrent Vorbis > streams are the same as for DVD: multiple languages, commentaries, > scores (possibly needing mixing). Deciding what to play needs > application involvement; how much should vorbisfile be able to do, and > how much should wait until oggfile (and how much should be left to media > players that understand all the complexities involved)? >Re: multiple audio tracks, there are quite a few ogm files out there with multiple vorbis streams, typically the default language is first. So if you made vorbisfile drop unknown streams, these are potential files people might try to play with it. The other case, i have a few such files for testing, is two audio streams designed to play concurrently. For example a dj type scenario... intentionally playing two files over the top of each other. An even more useful case is for example an online stream, where the music is in one stream, and the dj/announcer can voiceover in the other stream... i've got a few test files like this also. Vorbis+Vorbis and Speex+Vorbis examples. I think somewhere i've got a file that plays four songs simultaneously, even though this file is not particularly useful, it was just a good test to see how my directshow filters would handle it. Another scenario where this would be useful might be having different instruments in each track. Obviously neither vorbis file nor a player can tell whether the file author intended for the streams to play at the same time or be alternates... or even more complicated would be groups that are alternates, ie either play these two together, other wise play these two together... or always play this one with the music, and choose one from voiceover streams to play concurrently with the music. VLC for example will let you choose an audio stream, however there is no option for playing them at the same time. This is something we might want to extend skeleton to support, i know we've talked about this kind of thing before. So that skeleton can provide some kind of mapping as to how the various streams relate to each other. Cheers, Zen.