search for: syreeni

...nt. The specification of any > format or protocol has mandatory and recommended sections (not > "features"); MUST and SHOULD respectively 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

...ion 1) from the OggPCM draft, and make my/our (with Martin Leese) suggestion (option 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

...*allow* common variances. Most of all, because: > Unless you can guarantee that you're writing streams that are only > going to be passed 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

...have the tendency to *really* overengineer stuff, which would make me a Matroska 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

...way > to wrap and describe arbitrary PCM data[1]. If you prefer to > distribute it in little endian all well and good. My thoughts exactly. 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

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:

...at's mostly true. That's also the reason why you can't -- as of now 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

...g standard with more overall support and balance, or if two, at least a better architecture 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

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

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

Sampo Syreeni wrote: > Secondly, I'd like to see the channel map fleshed out in more detail. Sampo, I did flesh out the wiki a **little** more. Is the intent clearer now? > (Beware of the pet peeve...) What is that pet peeve? > IMO the mapping should cover at least the > channel assignmen...

...ictions I suggested a couple of years ago, 3) add the multiple, preferential mapping approach because at least John Koleszar agreed with it the last 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

On 10/19/07, Sampo Syreeni <decoy@iki.fi> wrote: > On 2007-10-19, Martin Leese wrote: > > OggPCM Draft3 > > Draft 3 is obviously a joke. Draft 2 is what most of the people agreed > upon the last time around, with the channel maps left unfinished. Draft > 1 was abandoned by most people in favour...

On 14/02/2008, Sampo Syreeni <decoy@iki.fi> wrote: > On 2007-12-30, Timothy B. Terriberry wrote: > > > In any format that is to be used on both, it is always better to pick > > one and stick with it. > > Then recommend one single format. Nobody *has* to support all of the > features present, ye...

Am Freitag, den 27.08.2010, 20:51 +0300 schrieb Sampo Syreeni: > On 2010-08-27, Ralph Giles wrote: > > >> My question to you, What advantages has ogg vs matroska. > > > > They're both free containers, and there isn't a significant > > performance difference, so either one works from a free media > > perspectiv...

Sampo Syreeni <decoy at iki.fi> wrote: ... > [I]n > well-designed and matched protocol environments, if you expect to see > some array of differing protocols, you will also see an easy way of > discerning those protocols from each other. Before engaging in any sort > of decoding endeavor. &g...

Am Samstag, den 28.08.2010, 01:01 +0300 schrieb Sampo Syreeni: > On 2010-08-27, Alexey Fisher wrote: > > > Doing one thing seem to be good reason. User normally see just file > > name say bla.ogg or bla.mkv . [...] > > Yes, that might be a benefit as well. But an unexpected one: in > well-designed and matched protocol environmen...

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

.... >> I think this is a good idea, but it may be wise to stop at stereo and >> not provide a preference for any of the 4+ channel formats. > > 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