similar to: WinXP GUI problem (PR#8018)

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 of draft 2. So what is "OggPCM"? I started this thread

On 2007-12-30, Ian Malone wrote: > Really it's pretty trivial and hardly taxing on the processor either. > As far as I can tell the OggPCM standard was designed to provide 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

On 2008-02-14, Conrad Parker wrote: > I tend to disagree with your sentiment. 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 -

I've tried to solicit discussion on this point in the past, but now I'd like the press the issue for a bit. I'd like to remove the less well developed mapping header (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

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

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

On 10/21/07, Ivo Emanuel Gon?alves <justivo@gmail.com> wrote: > On 10/21/07, Martin Leese <martin.leese@stanfordalumni.org> wrote: > > Either "OggPCM" or "OggPCM Draft2" needs > > to be deleted. It really doesn't matter which, > > but I would suggest that "OggPCM" takes the > > big sleep. Just give time for me (or Sempo)

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 > perspective. [...] Personally I would add the following points/bullets: * Ogg has a lesser semantic burden, so that e.g. embedded

> 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 2017-11-01, Jean-Marc Valin wrote: > I'm not sure, but my best guess would be "because MP3's window is very > leaky and MP3 has to waste a lot of bits in the LF because of that". > It could also be just the MP3 encoder being silly, or other things. Was the original poster speaking about the SILK or the CELT derived mode? Because at least wrt SILK (and the rest of

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 assignments possible in WAVE files, the most common Ambisonic > ones, and perhaps some added

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 environments, if you expect to see some array of differing protocols, you will also see an easy way of discerning those protocols from each

I just noticed when using 2.6.1, 2.6.2 (2008-02-08), 2.6.2pat (2008-02-21 r44582), and 2.6.2pat (2008-03-24 r44975) on my poor old Celeron D330 (2.6 GHz; 3.5 years old) running Windows XP, that the mouse cursor appears to be redrawn more sluggishly when the pointer is over R windows graphics devices than over the R console window or other applications' windows. The slowdown seems to start only

> 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

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:

Full_Name: Rob Cranfill Version: 2.8.1 OS: Windows XP SP2 Submission from: (NULL) (130.76.32.19) Using the Windows installer for 2.8.1, partway through the process there is a dialog that looks something like this: ---------------------------------------------- Display Mode Do you prefer the MDI or SDI interface? ------- Please specify MDI or SDI, then click Next. (*) MDI (one big

Jean-Marc Valin wrote: >>I'm also not entirely sure that the coding chosen for the channel >>definitions is the best one. Typically we'd expect each type of channel >>map to contain all and nothing but 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

Hi Gents, I need to get the control limits from qcc function. As follows: qcc(MDI, type = "xbar.one") Call: qcc(data = MDI, type = "xbar.one") xbar.one chart for MDI Summary of group statistics: Min. 1st Qu. Median Mean 3rd Qu. Max. 0.3266 0.4249 0.4371 0.4333 0.4451 0.4858 Group sample size: 1 Number of groups: 383 Center

Below, attached, and available at the 'ifmemdsk' branch at: http://git.zytor.com/?p=users/sha0/syslinux.git;a=commitdiff;h=a975c12919bbd48739fede4ebfe099d98b87192e Review welcome! - Shao Miller ----- From a975c12919bbd48739fede4ebfe099d98b87192e Mon Sep 17 00:00:00 2001 From: Shao Miller <shao.miller at yrdsb.edu.on.ca> Date: Sat, 6 Aug 2011 05:24:46 -0400 Subject: [PATCH]

Hi Just started with WxRuby after using Fox. Very impressed by the easy binary install and I''m already liking the native look and feel on MSW. Thanks! I''m trying to create an app with a MDI Parent Frame and a full-height (docked) side panel with various controls in it. The MDIParentFrame doesn''t work properly if I put it inside another frame with a sizer, so