[vorbis-dev] my vorbis comments

[Michael Smith]

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

Yes, that's right - there IS no easy way to find out these. In fact, it's
impossible for true VBR modes (vorbis right now is true VBR. These fields
are ONLY useful for CBR or constrained VBR). Since in advance we don't know
what the average bitrate will be, we can't fill any of these in. And vorbis
streams packets out, with the header first - it doesn't (and shouldn't)
provide a way to go back and modify the header packets later. 

It would be nice to have a way to find the av. bitrate easily, but it's
just not possible with the way vorbis works. Your method (seek, divide
filesize by length) is basically correct (vorbisfile does this - it's
fairly complex, and made more so by chained streams).

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

Yes, basically a tar file is a good analogy. See vorbisfile for lots of
details on how to deal with this correctly.

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

Ok. The first page which might contain audio SHOULD be the page after the
page in which the third header packet exists. However, until last week, the
encoders didn't flush the current page after the headers. So it could be
either. You'll have to figure out which, I suppose (if you can get packets
out after the headers, but before submitting further pages, then it's the
latter (audio starts in a header page)). 

>It's the decoder.  And, what change?

Well, on the decoder side it'd be nice to deal with things either way.
However, the change I was referring to is to flush the current page(s)
after the header packets are submitted (this is on the encoder side). You
should do this. All the encoders (including encoder_example) in
branch_postbeta2 do this correctly - you should modify your encoder to match. 

Michael

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