search for: quadraphonics

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.

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

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

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

I just recently found that opus_multistream_encode_float is returning -1 (OPUS_BAD_ARG) with the libopus 1.1 build but works just fine with the libopus 1.0.1 and libopus 1.1-beta builds. I tried using opus_multistream_encoder_create and opus_multistream_surround_encoder_create. Tried with coupled and uncoupled quadraphonic and uncoupled stereo encodes. I'm dynamically loading the libopus

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

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 Fri, Nov 11, 2005 at 09:13:01AM +1100, Erik de Castro Lopo 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? It's not about what's now, it's about what could be, and nobody has been able to make good predictions, except your logic here: > If

On Wed, Jun 4, 2014 at 4:31 PM, Timothy B. Terriberry <tterribe at xiph.org> wrote: > Alpha Thinktink wrote: >> max_data_bytes=-11 > > That value is passed in by you. I also don't think passing such a value > would have worked in earlier releases. It indicates the size of the > buffer you are passing to the encoder to receive the encoded output. Actually, I'm

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

This patch to opus-tools adds optional support to WavPack lossless format as input to opusenc. Like support to FLAC, it depends on an external library, libwavpack, and may be disabled on configure. Lucas Clemente Vella (1): Reading input from WavPack files. Makefile.am | 7 +- configure.ac | 37 ++++++++ src/audio-in.c | 71 ++++++++------- src/opusenc.c | 19 +++- src/opusenc.h

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

The Wine development release 1.7.34 is now available. What's new in this release (see below for details): - Support for surround sound in DirectSound. - Better text run support in DirectWrite. - Many HTML engine fixes. - More support for WBEM objects. - A few more C/C++ runtime functions. - Various bug fixes. The source is available from the following locations:

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

The Wine development release 1.9.11 is now available. What's new in this release (see below for details): - Better support for long URLs in WinInet. - Various Direct3D 11 improvements. - Down-mixing support in DirectSound. - Some cosmetic improvements in desktop mode. - Various bug fixes. The source is available from the following locations:

Hi All, Please find below an updated Vorbis-RTP Internet Draft document for review and discussion at the Xiph IRC meeting on Saturday. The changes in this version have been: Codebook caching mechanism Expanded SDP parameters Expanded MIME section Expanded introduction Packet loss section Minor tweaks and clarity changes to text There are probably some minor tweaks to the formatting needed