[vorbis-dev] my vorbis comments

[sbj at mit.edu]

>>1. vorbis_info:
>>  b. A function which compares two vorbis_info structs, to see if they
>>     are equivalent

>Is this really useful?

Nope.  I think you're right on this one, I take back 1.b.

>>  d. People say the info_[A-E] has approximate bitrate X, but those
>>     structs don't have the bitrate_* fields set, what's up with that?

>The bitrate_* fields are for CBR (and constrained VBR). So they aren't used
>yet (you'll see that the library doesn't use them anywhere, except to write
>and read them). The approximate bitrates are a function of the
>psychoacoustic sets and the codebooks used, at the moment. There's no
>simple way to figure out what they are just from looking at them, which is
>why the headers say what they are.

The reason I ask about this is that I think it would nice to be able
to describe the particular encoding of a vorbis file to the user.
Something like "2-channel, mid-side, 44.1kHz, approx 128bps".  Right
now the only useful info I know how to extract is rate and channels,
and maybe bitrate if I seek to the end and divide number of frames by
file size.

>>  a. I wouldn't mind if vorbis didn't use separated channel buffers,

>Not entirely sure what you mean, here. Can you clarify? If you're talking
>about how vorbis uses seperate buffers for each channel, rather than a

Yeah that's what I mean.  It's not a big issue to me at all, I was
just throwing out more comments.

[ chained streams ]

Ah, I see. So if I've got some seekable file with chained streams in
it, I should treat it basically like a tar file? :) I was running into
some confusion about how chained vorbis files map to speaker output,
and to other file formats.  I'm guessing it would depend a lot on what
the user is trying to do.

[ header problems ]

>I'm not sure I understand what you've been doing here, but it sounds like
>you're expecting the current page to end after the last header (such that
>the audio starts on a new page). This indeed should be the case (after some
>discussion a week or so back). 

Basically.  What I really want to know is the offset to the first page
which might contain audio, so I can seek to it later, if necessary.
For now I have worked around it by assuming that page is at offset 0.
Later I will look into it further, it is another non-big issue.  I was
only concerned that there was some hidden difference between
ogg_sync_pageout and ogg_sync_pageseek, such that using pageout might
possible read more pages than is really necessary.

>However, if you based your encoder off any of the sample code more than a
>week ago, then it wouldn't be doing this (flushing pages after the
>headers). You should make this change, but you might also want to deal
>correctly with files which don't do this.

It's the decoder.  And, what change?

By the way, thanks for the incredibly rapid response! And keep up the
good work.

                   jamie

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