>From looking at the code, it looks like the first vorbis header in a stream isalways placed in its own page. It also looks like maybe the audio data (i.e., the stuff after the headers) is maybe also supposed to begin on a new page. Is this part of the spec? I notice, though, that the second and third headers share a page, at least in one .ogg I looked at. It seems like it would be easier for tools which manipulate the comment or codebook headers if each of these headers was required to be placed on its own page. Any thoughts on this? --Mike -- Mike Coleman, mkc@mathdogs.com http://www.mathdogs.com -- problem solving, expert software development --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
At 02:07 AM 4/25/01 -0500, you wrote:>>From looking at the code, it looks like the first vorbis header in astream is>always placed in its own page. It also looks like maybe the audio data(i.e.,>the stuff after the headers) is maybe also supposed to begin on a new page. >Is this part of the spec?Correct. The first packet must be on a page by itself (this is true for all ogg streams, and is enforced by libogg). The requirement that the audio data begin on a new page was added later, it wasn't there originally. It's needed because otherwise streaming is overly complex. Playback works regardless. This has to be done by the encoder, because this requirement is specific to vorbis, not to ogg in general. I believe this change was made prior to beta 3.>I notice, though, that the second and third headers share a page, at least in >one .ogg I looked at. It seems like it would be easier for tools which >manipulate the comment or codebook headers if each of these headers was >required to be placed on its own page. Any thoughts on this?As someone who has written many (most?) of the available tools to manipulate vorbis files in such ways, I feel qualified to answer this. It'd make it _very_ slightly easier, but not significantly so - so it's not worth changing the spec for this. It only makes the simple case slightly simpler - and since one has to implement the complex case anyway (where the packet doesn't fit onto one page - common for the codebooks, less common but very possible for the comments), it's not a great help. 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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, Apr 25, 2001 at 02:07:34AM -0500, Mike Coleman wrote:> >From looking at the code, it looks like the first vorbis header in a stream is > always placed in its own page. It also looks like maybe the audio data (i.e., > the stuff after the headers) is maybe also supposed to begin on a new page. > Is this part of the spec?Yes to all three questions.> I notice, though, that the second and third headers share a page, at least in > one .ogg I looked at. It seems like it would be easier for tools which > manipulate the comment or codebook headers if each of these headers was > required to be placed on its own page. Any thoughts on this?Well, more than that, neither the second or third header is currently guaranteed to occupy only a single page (together or each). I'll probably limit both, temporarily for Vorbis I, to one page max, but it won't stay that way in the long run. Write the code to always run. Convenience isn't always a virtue. Monty --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.