search for: 025e

...order to be consider "Vorbis" compliant (or let's say, to be a "correct" vorbis decoder). I am experimenting with integerized libvorbis and the decoder delivers the audio data as following, (and compare with the floating point version below). $ tail audioout-int.txt 0290670 025e 085c 02cf 0895 0349 08b2 039e 087d 0290680 03ab 07df 03a0 0738 03de 06d6 0458 069f 0290690 04f2 066b 05c3 061a 069d 05cd 0784 057b 02906a0 0865 052e 095d 050e 0a46 04f2 0b0e 04f2 02906b0 0bd0 0505 0c9c 0552 0d48 059f 0dd7 05ec 02906c0 0e88 0675 0f77 0747 1045 07ec 10b0 083f 02906d0 1111 0895 1190 0...

...ctively for IETF and W3C stuff. Then why not make the common endianness MUST and the rest of it SHOULD? That was my sentiment, after all... -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

...sed within a single architecture, allowing both formats > is always worse. ...some people *are* able to guarantee that. Why hinder them? -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

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

...lover, yet then I have a persistent bad feeling about that tendency because that's "not the internet way". I would *love* to learn about some further/finer points, and of course counterpoint. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

...rchitecture for them both. I would hate to relinguish a standard I originated if it ever came to that. But this sort of situation really does tell you that you should do it for the common internet welfare. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

...st time around and nobody objected, and 4) cover as many of the special cases, nits, canonicalization issues, and so on, as I can think of. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

...y. On a related note, comments on the reworked channel mapping headers would be appreciated. I think they're finally in workable shape. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Ian Malone wrote: > This is all well and good but OggPCM is in an Ogg transport > stream, so that needs to be unpacked anyway. Fair enough. Since the ogg pages (which I beleive are 4k) need to be unpacked anyway, there is little harm in having to (possibly) do endswapping as well. Erik -- ----------------------------------------------------------------- Erik de Castro Lopo

...tion 2) the definitive one. If anybody objects, let's discuss it on-list. If not, I think it wouldn't be too bad of an idea if I made the proper adjustment to the OggPCM spec in, say, 30 days time. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-50-5756111, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

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

...b id_auth[1] : 00 [2005/12/14 16:37:50, 5] rpc_parse/parse_prs.c:prs_uint8(582) 025c id_auth[2] : 00 [2005/12/14 16:37:50, 5] rpc_parse/parse_prs.c:prs_uint8(582) 025d id_auth[3] : 00 [2005/12/14 16:37:50, 5] rpc_parse/parse_prs.c:prs_uint8(582) 025e id_auth[4] : 00 [2005/12/14 16:37:50, 5] rpc_parse/parse_prs.c:prs_uint8(582) 025f id_auth[5] : 05 [2005/12/14 16:37:50, 5] rpc_parse/parse_prs.c:prs_uint32s(898) 0260 sub_auths : 00000015 087e60f9 5a3924ad 6dd83d7d 000006bb [2005/12/14 16:37:50, 7] rpc_parse/pa...

...s. > > I think a default mapping would be needed just to help for the > conversion header. I'm not sure I understand this part. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Hi, The Xiph Wiki contains the four pages: OggPCM OggPCM Draft1 (with Talk page) OggPCM Draft2 OggPCM Draft3 Can I suggest that this be reduced to just one (or maybe two) pages. I suggest this because somebody has started making changes to OggPCM Draft2. My guess is that this is not desirable. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web:

...up a representative list of channel types for the enumerations, put in some context about the different choices we've made, and so on. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Hallo all, euphoria with cheese, the project i working on, i needed to make decision about codecs and containers we use. I'm clearly not expert in this. After the euphoria about vp8/webm going slowly to the end, i see advantages what theora has against vp8. Seems like theora perform better on LoEnd hardware. Even x264 with good optimisation work not really good on slow Athom. My question to

...at least -- make do with just one single coding concept at all bitrates and with all utility signals: doing it the empirical way leads to things like OPUS which just happen to work much better in practice. -- Sampo Syreeni, aka decoy - decoy at iki.fi, http://decoy.iki.fi/front +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Hi All, What is the status of the oggpcm project? I'm investigation solutions to the following problem: losslessly encode double-precision mutli-channel timeseries data in a format that is compatible with free (libre) internet streaming technologies and that permits diverse metadata to be encoded with the stream. flac isn't suitable because it only supports integer data, lossy

Hi! I have some MP3 audio material which is basically speech with some background noises, essentially > 120Hz and < 5kHz. I had the idea to reduce the file size by recoding the material to Opus at 56kbps. Unfortunately the result is a file sampled at 48kHz much larger than the original. I hope you agree that it does not make sense to create a file larger than the original (MP3). Of course

...ot quite sure what the overall spatial distribution of the surround field is supposed to be. Hopefully I can find something concrete on it. -- Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111 student/math+cs/helsinki university, http://www.iki.fi/~decoy/front openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2