similar to: Sample-granularity file length and editing whitepaper

Hello Martin, > how a number of samples with no defined size is translated into 8, 16, or 32 bit values in my buffer Although I do not know in detail about the actual implementation of libvorbis, most of the decoders should internally produce single-precision (32bit) floating point values, or 32bit integers as the result of PCM decoding. They are downcast to PCM samples with 8bit, 16bit, or

Hi, I seem to have found a bug with seeking in opusfile in some situations, though this might be better directed to the ogg list. I?ve included a short description below and a test case C program that describes it more detail (comments) and reproduces the issue when used with a file which contains packets that have been split over a page boundary (less common than I thought). The test program is

Hi Arc, illi, I think it would be advantageous if we take the emotion out of this discussion , so let's just argue technically. My experience with xiph is that we are a very friendly community and trying to help each other and listen, so let's keep that culture up. I think we all agree: it is a good idea to have an media mapping for ogg for uncompressed PCM. As for what is required in a

Thanks. If decoding from the last packet on the previous page works, I may have to do that. But I was hoping to avoid it. Yes, I may be seeking a lot. A packet spanning multiple pages shouldn't be a problem for me, because I'm only adding index points that represent the beginning of a packet. But does this actually happen for Vorbis? (Aside from large header packets) The large blocks

This thread reminded me of Ralph's LCA presentation entitled "Seeking is Hard". <http://xiph.org/~giles/> Not sure if it contains anything you don't already know, but worth a mention. - Josh On 2015-5-20 06:55 , Madison Link wrote: > Thanks. > > > > If decoding from the last packet on the previous page works, I may have > to do that. But I was

I have the following problem. Be an encoder application (station) and a decoder application (receiver). If I feed the vorbis encoder with 'n' pcm samples in the station I want to know how many pcm samples will be decoded in the receiver if I feed the decoder with the encoded output. The ogg_page_granulepos is right for the purpose? I read the documentation about the ogg_page_granulepos

Hi, If this is true: "Granule Position Information in Ogg Header is a hint for the decoder and gives some timing and position information." So say if granule position is 10000, it means that 10000 PCM samples are encoded in this page approximately. If this is true we can neglect this information, it will not effect the decoding right(but might effect for streaming)? Ravi

I have a technical question about the vorbis granule position, but I would like to put the question into context. When a ogg vorbis stream is ripped using wget, fetch, or streamripper under Linux or FreeBSD, the resulting file has problems both with granule position and with a missing EOS. I think I can figure out how to add an EOS, but is there a way to determine the granule position in a stream

Hey all, friendly ping :) Any help is much appreciated. On Thu, Jun 18, 2015 at 6:56 PM, Chris Cunningham <chcunningham at chromium.org > wrote: > Hi Vorbis-Dev, > > I'm investigating various WebM/Vorbis bugs in chromium. AFAIK muxing > Vorbis inside of WebM does not have an official specification, so I'm using > ffmpeg's implementation to try to answer 2

Hi, I've now got another way of encoding granule (oh, not *again*, I hear you cry). I believe it's an improvement over the existing "generic" method, so I'll outline it here for your consideration. Again, it's different from what Skeleton can handle, but it's a simple superset and would be easy to add to Skeleton (and liboggz). It is also compatible with other

Hi Vorbis-Dev, I'm investigating various WebM/Vorbis bugs in chromium. AFAIK muxing Vorbis inside of WebM does not have an official specification, so I'm using ffmpeg's implementation to try to answer 2 questions: 1. Under what circumstances is it valid to find WebM Blocks containing Vorbis data with zero duration? (This would mean the next Block in the Cluster has the exact

Thanks Silvia for your response :-) It's good to get constructive discussion on this, and I've been hoping to have exactly this kind of criticism re: OggPCM for some time. On Wed, Nov 09, 2005 at 10:21:04PM +1100, Silvia.Pfeiffer@csiro.au wrote: > > Data pages are identified to be part of a logical bitstream through their > serial number, so don't need any additional

Hi, do you still think you need all this, if you are allowed to have equal granulepos on subsequent pages? Conrad. On 18/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com> wrote: > Hi, > > I've now got another way of encoding granule (oh, not *again*, I hear > you cry). I believe it's an improvement over the existing "generic" > method, so

Apple File System Guide is released. https://developer.apple.com/library/prerelease/content/documentation/FileManagement/Conceptual/APFS_Guide/GeneralCharacteristics/GeneralCharacteristics.html >Nanosecond Timestamp Granularity > >APFS supports 1 nanosecond timestamp granularity, which improves >upon the 1 second timestamp granularity of HFS+. >Compatibility > >You can share

Hi, I have this idea: It can be useful to have for each frame two variables stored in bitstream that will hold information about starting and ending position of \"valid\" samples in the frame. With these additional information it will be possible to do simple editing (like cutting or concatenating two streams) without decompressing/recompressing at sample-granularity. Simple example

+ more asan folks, please CC them to the code reviews. Also please make sure llvm-commits is CC-ed (cfe-commits for clang changes) On Tue, Oct 31, 2017 at 2:29 PM, Walter Lee <waltl at google.com> wrote: > I've prepared a preliminary set of patches that makes ASan work with > 32-byte shadow granularity, and I would like to get some feedback on > those patches as well as my

I've prepared a preliminary set of patches that makes ASan work with 32-byte shadow granularity, and I would like to get some feedback on those patches as well as my general plan. Some background: I am porting ASan to the Myriad platform. I'm looking to break up that port into components that may be useful/relevant to other platforms -- the first of those pieces is the ability to use a

The one remaining caller of set_limit, the PnP BIOS code, calls into the PnP BIOS, passing kernel parameters in and out. These parameteres may be passed from arbitrary kernel virtual memory, so they deserve strict protection to stop a bad BIOS from smashing beyond the object size. Unfortunately, the use of set_limit was badly botching this by setting the limit in terms of pages, when it really

The one remaining caller of set_limit, the PnP BIOS code, calls into the PnP BIOS, passing kernel parameters in and out. These parameteres may be passed from arbitrary kernel virtual memory, so they deserve strict protection to stop a bad BIOS from smashing beyond the object size. Unfortunately, the use of set_limit was badly botching this by setting the limit in terms of pages, when it really

I am deeply sorry about the corrupt message just being sent; there seems to have been a compatibility issue with my mailer and my browser. This is an identical copy of the previous message: Hello Martin, Vorbis encoders are lossy, which is in a sense equivalent to converting the sample size of the raw PCM stream into something that would result in the desired bitrate. The "sample size"