search for: page_segments

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

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.

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

...irst lacing value (in this case out of 13) is less than 255 (190 in the example I'm looking at). *) "Note that a lacing value of 255 implies that a second lacing values follows [...] A packet of 255 bytes is terminated by a lacing value of 0." Is this value of 0 included in the "page_segments" value in the case that it occurs? i.e. is it safe to assume that the number of lacing values in the header will be equal to the number of values in the segment_table? Given the above, scanning for a value of < 255 doesn't seem to be safe. Thanks again, - -Scott - -- The fact that a...

>> 1) Is it valid to insert an "empty" page into the stream which simply contains the binary value 0 for the page_segments counter, and which therefore contains no segment table nor any packet data? I'd like to do this to produce a gapless page sequence number so that I don't have to re-number all following pages, so that I don't have to re-compute the checksums of all following pages. This is way faster....

Hello Tim Yes, I understand that mono channel has nothing to do with it, but is there any guideline or thumb rule on the value in page_segments to use Regards Amit On Mon, May 9, 2016 at 4:01 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > 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...

...native .NET ogg tagging library. It already works well for non-multiplexed ogg vorbis, ogg flac and native flac files. Concerning multiplexed files, I've got two short questions: 1) Is it valid to insert an "empty" page into the stream which simply contains the binary value 0 for the page_segments counter, and which therefore contains no segment table nor any packet data? I'd like to do this to produce a gapless page sequence number so that I don't have to re-number all following pages, so that I don't have to re-compute the checksums of all following pages. This is way faster....

..., but I have to write it with my own code and I have not found documentation until you have explained to me it. In Matroska case, libraries doesn't exist for editing Tags. Another question: which is the maximum size of an oggs stream? In the sample files with covers, one has 4335 bytes (17 page_segments) and the other one 65025 (255 page_segments). Is the size decision free? And if it's this way, why not to put the whole comments in a stream without split? Lastly I inform you, revising other programs, Easytag 2.1.6 (last revision using libraries provided) uses COVERART and COVERTARTMIME ta...

Hello Tim, Jean-Marc Thanks for the clarification. Let me study the sample OPUS file and see if my understanding is now clarified. Regards Amit On Mon, May 9, 2016 at 2:02 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Amit Ashara wrote: > >> I am referring to the following file >> >> >>

On Fri, Apr 20, 2007 at 03:10:09PM +0000, Mathias Kunter wrote: > 1) Is it valid to insert an "empty" page into the stream which simply contains the binary value 0 for the page_segments counter, and which therefore contains no segment table nor any packet data? I'd like to do this to produce a gapless page sequence number so that I don't have to re-number all following pages, so that I don't have to re-compute the checksums of all following pages. This is way faster....

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_______________

...OpusTag structure? Search always shows up Vorbis but not Opus. Regards Amit On Mon, May 9, 2016 at 4:01 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > 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. > > > ________...

Hello Tim, Jean-Marc Thanks for the inputs and the corrections. I think I understand the Ogg Opus better now and it all makes sense. There are two questions that I am left to ask. 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. 2. In the OpusTag the is the libopus a mandatory field? Regards Amit On Mon, May 9, 2016 at 2:11 PM, Amit Ashara <ashara.amit at gmail.com> wrote: > Hello Tim, Jean-Marc > > Th...

...| page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Regards, Silvia. -----Original Message----- From: ogg-dev-bounces@xi...

...| page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSb (least significant bit) comes first in the Bytes....

...| page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSb (least significant bit) comes first in the Bytes....

...| page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSb (least significant bit) comes first in the Bytes....

...| page_sequence_number | 16-19 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | CRC_checksum | 20-23 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |page_segments | segment_table | 24-27 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 28- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LSb (least significant bit) comes first in the Bytes....