similar to: Detecting packet lengths in Vorbis-streams

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I thought I would separate this out into a separate mail since it's not comment specific stuff -- There seem to be a couple of inconcistanies in the Ogg spec as regards to lacing values: *) "The raw packet is logicaly divided into [n] 255 byte segments and a last fractional segment of < 255 bytes." However, in the wild, I've

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

On May 3, 2011, at 4:08 PM, David A. Greene wrote: >> >> It's just that an REX prefix is required on some instructions when >> %xmm8 is used. Is it worth it to undo LICM just for that? In this >> case, probably. In general, no. > > Ah, so you're saying the regression is due to the inner loop icache > footprint increasing. Ok, that makes total sense to

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

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

HOgg 0.4.1 Released ------------------- The HOgg package provides a commandline tool for manipulating Ogg files, and a corresponding Haskell library. HOgg is in hackage, or on the web at: http://www.kfish.org/~conrad/software/hogg/ This is the fourth public release. The focus is on correctness of Ogg parsing, production and editing. The capabilities of the hogg commandline tool are roughly on

Thanks for your replys. >packets don't always begin at the >start of a page OK, since I only want to read / write the Vorbis comments, I can limit it to the Vorbis header packets. http://xiph.org/vorbis/doc/Vorbis_I_spec.html stats that the comment header always begins on the second ogg page. Since the length of the precedent identification header is fixed, this even is a fixed offset

On 15/03/07, Ralph Giles <giles@xiph.org> wrote: > On Wed, Mar 14, 2007 at 12:23:47PM +0000, Mathias Kunter wrote: > > > > In contrast to that, http://www.ietf.org/rfc/rfc3533.txt stats the following: > > "Ogg Vorbis provides the name and revision of the Vorbis codec, > > the audio rate and the audio quality on the Ogg Vorbis bos page. > > It also uses

Hello, I tried to use urca package (R) for cointegration analysis. The data matrix to be investigated for cointegration contains 8 columns (variables). Both procedures, Phillips & Ouliaris test and Johansen's procedures give errors ("error in evaluating the argument 'object' in selecting a method for function 'summary'" respectiv "too many variables,

Hi, I'm writing a little API in java that read/write ogg's comments (in the comment header), as well as reading the information header. All the "read" part is done and is working well, but I am having a little problem while coding the "write" part of the API. In the docs (I use http://www.xiph.org/ogg/vorbis/doc/Vorbis_I_spec.html#id4726648), I founded everything

Hi. I am trying to understand how to package opus-encoded data in an ogg stream to make a standards-compilant ogg/opus file. Most things are clear, but there is one thing I simply do not understand. What I do understand is that Ogg is based on pages, that each come with a fairly sizeable header (>=27 bytes). Now, I encode with a fairly low bitrate, so my opus packages are <100 bytes long.

Hi the list. I do not understand the philosophy behind numeric and integer. - 1 is numeric (which I find surprising) - 2 is numeric. - 1:2 is integer. Why is that ? Christophe

Hi all, I am a developer for embedded system and totally new to Opus and open source audio codec. I'm now using Microchip dsPIC33 to develop a decoder for Opus. I am now using sources of libopus. The first question is for calling opus_decode(), do I need to skip the header bytes of an opus file before I can input the file data to opus_decode()? Or will libopus handle this automatically?

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: >> That was my initial reaction. Splitting should have at least >> rematerialized the value just before header2. That should significantly >> improve things. This is a classic motivational case for live range >> splitting. > > Well, not really. Note there there are plenty of registers available > and no

Thanks for a very quick and very good answer. Let me just double-check one thing: > To put multiple Ogg Opus packets in an Ogg page, all you need to do is > start a new segment for each Ogg Opus packet. There can be up to 255 > segments per page. For details, see the Ogg specification: > https://tools.ietf.org/html/rfc3533 So do I understand it correctly that a decoder will

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

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

> Please try a stable version of LAME. I don't really know what to do > with this backtrace. It would also help immensely if you could > reproduce the crash reliably (eg on the same song). DEBUG: Using LAME version 3.93 (gdb) bt #0 0x402b7585 in III_dequantize_sample () from /usr/local/lib/libmp3lame.so.0 #1 0x402d1200 in ispow () from /usr/local/lib/libmp3lame.so.0 Cannot access

On May 3, 2011, at 3:23 PM, David A. Greene wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > >>>> The greedy allocator is trying to pick registers so inner loops are as >>>> small as possible, but that is not always the right thing to do. >>> >>> How does it balance that against spill cost? >> >> I added the

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