search for: sampo

Full_Name: Sampo Etelavuori Version: 2.1.1 OS: Windows XP Submission from: (NULL) (130.188.8.10) After exporting for example jpeg files using the GUI the GUI gives me a default option of saving even ordinary scripts in jpeg-format and doesn't let me change the format at least easily. I have also some strange...

...the channel definitions typically >>used with that map type, in some order. For example L, C, R, Ls, Rs and >>LFE for 5.1. If so, all we're really trying to encode is the >>interleaving order. >> 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 [OGG_CHANNEL_FRON...

> Yes. Channel map type tells us what the primary interpretation of the > stored signals is. Channel definitions are there to tell which stored > channel corresponds to which abstract channel in the type. Channel > conversions define downmixes to secondary formats, as they do in MLP, > and might end up being ignored unlike the channel map. I think the channel conversion will

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 i...

...vide a 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

...entiment. 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

...r (option 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

...nse to *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

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:

...nally 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

In one of the last monthly meetings it was decided that OggPCM is ready and all it needs is an implementation (for instance, in ogg123). The problem is that nobody seems available to do it. If either Martin or Sampo would like to work on it, I believe nobody will oppose. CMML and Skeleton implementations are far more urgent right now, though. I have changed the main page in the XiphWiki to link to Draft2 as the "official" OggPCM. Hope that helps. -Ivo

...quot;OggPCM" takes the > > big sleep. Just give time for me (or Sempo) to > > copy over recent changes. > > Alright. Just tell me when and what page to delete. No action required. I updated Draft2 and then made "OggPCM" a #REDIRECT to "OggPCM Draft2". Sampo and I can now mess with Draft2. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web: http://members.tripod.com/martin_leese/

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

> 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 >...

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

...And that'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

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 a...

...plexing 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

...restrictions 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