similar to: OggPCM proposal feedback

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

Arc wrote: > Does endian vary widely for raw audio codecs, Well there are really only two endian-nesses, big and little. WAV is usually little endian but there is also a (very rare) big endian version. AIFF is usually little endian but also supports big endian encoding. CAF, AU, IRCAM and a number of others support both endian-nesses equally. > or would it be reasonable > to settle

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

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

Arc wrote: > However, support for (ie) 48-bit-float should not have to be created, Where are you going to find a 48 bit float? Is there an IEEE standard for that? I know some floating point DSP chips use a 48 bit float internally, but if there is more than one they are unlikely to be compatible and they certainly cannot be read by standard CPUs without having pull each value apart into

Over the weekend I chanced by the house of a quadraphile friend of mine to check it his SQ setup. For those interested, he has a fairly decent Kenwood linear turntable with what I understand is a rather pricy cartridge manufactured by some company whose name escapes me, hooked into a Fosgate Tate II SQ decoder which is likewise hooked into two X10-D buffers then finally into a Marantz receiver.

On Tue, 31 May 2016 09:41:37 -0700 Michael Graczyk <mgraczyk at google.com> wrote: > UHJ is an interesting way to preserve compatibility with non-ambisonic > playback systems. However, I have not seen it generalized to higher > orders. I expect that its popularity will decrease as HOA becomes more > and more common. If UHJ becomes popular in the future, we could > specify

Hi, > The flexibility of this does, though, encourage stuff like 96bit audio. > Anyone implementing a codec which uses this, and import/exports it, will > also write the appropriate conversion OggStream plugin which will allow > applications which only support, say, 16bit audio, to work with it. Do you think the noise in your 16bit application will sound different between a

I made a few updates to OggPCM2 http://wiki.xiph.org/index.php/OggPCM2 reflecting the latest discussions. Could everyone have a look at it and see if they agree. Otherwise, what do you feel should be changed? Anyone wants to speak in support of chunked PCM? For all those that are just tired of this mess like me, please express yourself in the new spec I created: OggPCM3

> I that this is handled pretty nicely by the "simple map" that Sampo > suggested. This is basically the same thing as the "channel map" > described on the wiki, but with the (physical,logical) channel pair > swapped. So, using the syntax from the wiki: > channel_type = OGG_CHANNEL_MAP_STEREO > channel_map [OGG_CHANNEL_FRONT_LEFT] = 1 > channel_map

On Thu, Nov 10, 2005 at 01:35:47PM -0800, Arc wrote: > > "Please don't make determination of the data format depend on > > multiple fields. Instead use an enumeration so that something > > like little endian 16 bit PCM can be specifed as OGG_PCM_LE_PCM_16 > > and big endian 64 bit doubles can be specified as OGG_PCM_BE_FLOAT_64. > >

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

(crossposted to theora-dev, since I thought some folks there might be interested) Hi all, Does anyone know of a ogg based container format that would be appropriate for holding raw AV data? I'm specifically interested in PCM audio, and uncompressed YV12 and RGB32 video. Basically looking to use it as a lightweight tool interchange format, generally muxed by mencoder and read/modified by

On Tue, Nov 08, 2005 at 04:59:33PM -0800, Arc wrote: > This is also interesting work in that, once we're done, we'll have a standard to > use for a compressed lossless format.. a FLAC for video, for editing or archival > purposes, similar to HuffYUV. Well, we're talking about an uncompressed format. OggMNG is already "FLAC for video". However, it doesn't do

Where can I find the Header file or whatever which specifies the "Mapping" flag. In feb - apr 2007, there was a lot of discussion about Ambisonics and Monty kindly stated that Mapping = 1 ; Denotes and Ambisonic file as opposed to = 0 which is 1 speaker/ 1 channel Has this been written explicitly into the standard? Which standard should I be looking at?

> I agree, which is why I wrote the OggPCM draft when we already have FLAC. > These > formats are not difficult to design or implement, and I think the added > efficiency and simplicity will more than make up for it. Which i looked at... and i'm wondering why on earth it has a sync code in the packet... that's the whole point of putting it in a container. > Now, if

List, A recent discussion over on XiphWiki is trying to decide if OggPCM should support only little-endianness or the usual combo of big and little. It started with the following statement by an user (Qqq): "Portable players are usually ARM, which is usually little-endian. The Macintosh is now little-endian. Obviously the PC is little-endian. Clearly there is a winner. It's long past

Hi all, The remaining issue to be decided for the OggPCM2 spec is the support of chunked vs interleaved data. Just so that everyone understands what we are talking about, consider a stereo file that gets stored as an OggPCM file. Within an OggPCM packet, the audio samples for the left and right channels can be stored as interleaved where the samples would be: l0, r0, l1, r1, ..... lN, rN

> True, but remember that the channel map type implied the number of > entries in the table, and also that in this organization you'll always > number the logical channels consequtively since each logical channel > indeed corresponds to an index into the array. If the channel map type > says it's a map for 5.1, there will only be 6 slots in the table no > matter how

Hi, I just checked in a fix for the bug you reported. Let me know if it works. Cheers, Jean-Marc On 05/06/14 12:41 AM, Alpha Thinktink wrote: > In debugging I saw: > opus_multistream_encoder.c > line 760 > if(!vbr) > max_data_bytes = IMIN(max_data_bytes, > 3*st->bitrate_bps/(3*8*Fs/frame_size)); > > max_data_bytes after this code becomes -2 where as