similar to: Quickie: Bitpacker endianness / OggPCM

Michael Smith wrote: > libogg has two bitpackers; a little endian one and a bigendian one. ok, I didn't see it in the docs at http://www.xiph.org/ogg/doc/libogg/reference.html and didn't look in the header file first. My bad. Is it correct to state that the oggpack_* functions use little endian order, and the oggpackB_* functions use big endian order? Is it safe to mix calls to

I have OggPCM (as currently defined) support implemented in mencoder and mplayer. I'd like to request that we settle on modifications to this header by the middle of next week or freeze the current header as the official major version 1.0, so I can get the patches cleaned up and released. We will be shipping a separate product based on this work in the near-term future, and compatability

> Unfortunately the ALSA API defines a number of formats which are > in practice extremely rare. In particular, any unsigned int format > larger than 8 bits. For instance, the only unsigned int type that > libsndfile supports is unsigned 8 bit. I expected this, it just seemed like a good starting point to get more than 7 formats on the table. Specifically I wanted to the logarithmic

On 09/02/2008, Ralph Giles <giles@xiph.org> wrote: > Yes, all that is reasonable. The original argument was that we need a > library anyway, no one noticed the function call overhead, and using > libogg simplified the embedding. > > Now, we'd like to remove libogg entirely as a dependency to avoid > confusion when using other containers, but that's an api change...

Hi all, I updated the wiki with another rev of this format. Updates include support for 43 formats in 14 coding schemes, as derived from the ALSA API. This seemed like a good way to get a list of what the formats in common use out there are, so it should be fairly comprehensive. Modifications to the "rev 2" format: 1. Expanded the 'id' field to support more than 7 formats.

Arc wrote: > Ok so we cap it to 64bit, since much more than that doesn't make sense (96bit > would be a "long double" C type) On x86 CPUs, "long double" is 80 bits. > I really don't like this idea, but I will entertain, formatting it as follows: > > ID Type Bits > 0 Int 8 > 1 uInt 8 > 2 Int 16 > 3 Int 24 > 4 Int

On Wed, Nov 09, 2005 at 05:33:37AM -0800, Arc wrote: > > Data pages are identified to be part of a logical bitstream through their > > serial number, so don't need any additional identifiers. Thus, Arc, I don't > > quite understand why you would require another 32 bits at the beginning of > > each data packet, when ogg pages are already covering that

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

In response to (and with the help of) John Koleszar I put together an early draft of OggYUV.. or rather, a list of header fields for it. http://wiki.xiph.org/index.php/OggYUV Feedback (on list or on wiki) is most certainly solicited, especially on the chroma subsampling list (how many different sampling methods do we need to reasonably support?) and if we've missed any fields to date.

I haven't actually had many questions up to now. Despite the all-encompassing CP_INSTANCE monolith, things have been relatively easy going. Now we get into real grit: First off, CBitman looks like it has endianness issues; it's packing into host-order 32 bit arrays (the comments and symbol names seem to indicate that this was originally byte-based packing code that got upped to 32 bit.

Greetings, I am building a data collection system that will ultimately have 28 channels and multi-rates up to 2 M/sec. I need some sort of lossless format framing and header system to transfer the data to a desktop PC over USB. Rather than reinvent, I looked around to see what others are using and for existing tools for testing. Surprisingly, I found few general purpose data formats that can

On Fri, Nov 11, 2005 at 07:17:53PM +1100, Erik de Castro Lopo wrote: > We're talking about a file header here. Even if the header is a kilobyte in > size, it will be completely **dwarfed** by the audio data following. So why > are you counting single bits like this? Why waste? You only have to read the header once for a stream, and libogg2 provides a convient bitpacker which can

On Wed, Nov 09, 2005 at 09:31:29AM -0800, Ralph Giles wrote: > > > > I am open to eliminating it, if it can be shown that the act of reading or > > skipping this data complicates implementation or makes it less efficient, > > however, the decidion to do so should include several people (Monty, Ralph, etc) > > who haven't joined this discussion yet. > >

On Fri, Dec 08, 2006 at 01:37:15AM -0500, Bill Johnson wrote: > Has anyone built libogg and/or liboggz using a cross compiler such as the > arm-elf GNU port? Conrad didn't mention is explicitly, but libogg also works find on arm. For a small embedded app, I'd just compile the two source files into a static library manually. If you're not using a smart linker, you may also

Michael Smith wrote: >Whilst I accept that there are many good uses for chunked data, I >think the transformation is trivial, particularly given certain >characteristics of the Ogg container. Remember, the data, if you read >an ogg stream into memory, is _already_ likely to be non-contiguous, >due to ogg's structure. It's trivial, and has insignificant additional

Ivo Emanuel Gon?alves wrote: > And IF that kind of performance can be gained in libvorbis too, the > question is, what are we waiting for? I doubt the performance gain would be that large. Theora had the fun little situation where it was thunking into the big endian version of some bitpacker functions which were one-line calls to the little endian version. Because gcc seemed to be

It's very small, maybe it could be made a separate statically linked lib ? Or some of it inlined. That said, libogg is small too, and some of the routines in there are quite small as well.

I threw a rough draft of an alternative format incorporating the comments received so far in this discussion on the wiki: http://wiki.xiph.org/index.php/OggPCM#Format Oliver, This seems to me like it would support the ambisonic requirements you mention, though it doesn't (and I imagine won't) describe the mic locations. Somebody who actually uses that info could probably define extra

On Thu, Nov 10, 2005 at 10:13:19AM +1100, Erik de Castro Lopo wrote: > > a) There is no marker to distinguish little endian data > from big endian data. The original reason for this is because Ogg makes such a matter moot, since the bitpacker in libogg2 handles endian.. however, if a "chunk" packer is made available (similar to memcpy), this becomes important since

Hi all, Siliva contacted me about this OggPCM proposal and asked me to join in. For those who don't know me, I am the main author and maintainer of libsndfile and therefore know quite a bit about how uncompressed audio is stored in sound files. However even I would not consider myself an expert; there are areas to do with channel assignments that I know I am ignorant of. I am also quite