similar to: lacing values clarifications

I noticed that, when decoding an ogg vorbis file that was encoded with the xiph library, that the comment header and setup header are encoded on one page. Okay, the vorbis documentation says you can do this, no problem. My question is, the lacing values seem to indicate where the packet boundaries for the two of these are, is this required, or is this just a hint? Further, I'm seeing

Hi, I'm currently trying to implement the Ogg specification in pure Java from scratch. (I know, something like that does exist, but that's a rewrite from C, at least that's my impression). I'm a bit confused with the number of lacing values/segments in a page, and the maximum length a page can have. The specification says, that there can be 255 segments in a page, 255 bytes each

Hi, There is something I don't understand about the page_segment and segment_table values in the documentation. As I understand it, the segment table consist of as many bytes as specified in page_segment, PLUS one trailing byte with a value between 0 and 254. I've looked at some files that has a Comment tag so large, that it is spread over two pages. Here, the first Page Header (not the

Hi, I'm reading the logical bitstream framing doc, and I have a question about lacing values, which encode the length of a packet (I think). For example, the values 255, 255, 243 encode a length of 753. I'm wondering whether a format more like this was considered length bytes encoding 0-254 1 value in one byte 255-65534 3 one 255 + value in two bytes

Hello All, When going through the Ogg format, I have a basic question. As per the RFC the Ogg format encapsulates the logical stream. Now consider the scenario where a raw mono stream is being encoded with Opus Codec. The stream is 48KHz and the length of the stream being encoded is worth 20ms of data. This makes it 960 half words (considering 16 bit format). Now if the final output is say 100

Someone could tell me the question about the question about lacing values values of segments. I mean i know what happens about segmentation but reading ogg specs i didn't understand this lines: "We simply add the lacing values for the total size; the last lacing value for a packet is always the value that is less than 255. Note that this encoding both avoids imposing a maximum packet

How would one implement the following scheme with minimal use of resources: Every Vorbis packet should be preprocessed to a certain extent, that is, the beginning of every audio packet should be parsed and some decoding steps executed. The result of this predecode as well as the rest of the packet should then be sent as output for final processing. I have skimmed through the standard, and as far

Hello Tim I am referring to the following file https://en.wikipedia.org/wiki/File:Sample_of_%22Another_Day_in_Paradise%22.ogg I opened the file in a HEX editor. I do not see the string OpusHead in the packet. It starts with Oggs. Also checking the occurrence of Oggs, I see that the first packet has BOS, the next all (except last) have 00 (which is not defined in the RFC as continuation) and

hello, I am writing an OGG tag editor, but I have a problem with a part of the header. Here is a part of a file header in hex <g>: <p>00000000: 4F 67 67 53 00 02 00 00 - 00 00 00 00 00 00 01 03 OggS______________ 00000010: F2 4D 00 00 00 00 BC 1B - FB E9 01 1E 01 76 6F 72 _______________vor 00000020: 62 69 73 00 00 00 00 02 - 44 AC 00 00 00 00 00 00 bis_______________

>Searching for 'vorbis' to find the packet boundary is wrong however. >The lacing values in the Ogg page header tells you exactly where the >division is. OK, so given the fact that a page can also contain multiple packets this means that the lacing values of one page could be like the following example: 255 255 189 (something less than 255, indicating that a new packet starts

Hi all, Here are some thoughts on Vorbis framing, which may make it easier to stream Vorbis in real time. The suggested changes also move more audio data closer to the beginning of each page. A note in the Vorbis framing spec suggests a simple 'bandwidth limited' mode whereby important information is placed at the front of each page and the end of each page is discarded. When operating

Hey all, If my understanding is right, there's a serious big in vorbisfile.c, in the routine _fetch_headers(), which will only show up when comment packet spans multiple pages. The code to read the first 3 Vorbis packets ogg_stream_pagein() once, then calls ogg_stream_packetout(). The problem is that ogg_stream_pagein() only adds a single page to the ogg stream state, whereas

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

Hi all, just letting you know that I am about to submit the final version of the Ogg 1.0 file format Internet-Draft to the IETF. It is due by today (March 3, Monday - Internet Draft final submission cut-off at 09:00 ET) for the next IETF meeting and I expect they will promote it to RFC status at the meeting. Please send any last-minute changes to me. Cheers, Silvia. <p><p>

Ralph, thanks for your help. >>Since the length of the precedent identification header is fixed, this even is a fixed offset >>into the logical ogg stream. >This will work for all the vorbis-only files I've seen (because no one >pads the first packet). You should really implement a proper ogg parser, >but by all means get a hack working first. I will of course use the

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Howdy, yeah, I've finally collected all your feedback on my I-D on the Ogg encapsulation format, many thanks to all of you! Below, I've listed the changes that I have made to the previous version and the attachment contains the complete new I-D. If there are any more change requests, please send me wording proposals as it's easier to include. :) Monty, in case you are doing any

Amit Ashara wrote: > 1. Since the stream I am working with is a mono channel, what should be > the advised page_segments to use. I am using an embedded system so > keeping the flash and SRAM usage are vital for the development. The number of channels has no impact on this at all. > 2. In the OpusTag the is the libopus a mandatory field? Yes.

Amit Ashara wrote: > First Packet shall have Header Type as BOS > All subsequent Packet (except last one_ shall have Header Type as > Continuation > Last Packet shall have Header Type as EOS > > Is this correct? No, the header_type field is a property of a page, not a packet. In it, the continuation flag is used when a single packet spans multiple pages. This is required when

On Wed, Aug 13, 2008 at 3:05 AM, ogg.k.ogg.k at googlemail.com wrote: > And that's the canonical way AFAIK. Comparing times computed from > the granpos you get from pages you get from a bsearch requires good > knowledge of the codec, whereas comparing granpos can seek within > any codec. No. it's in general impossible to calculate the granulepos that corresponds to a