search for: decoys

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

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 -

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

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

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

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:

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

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

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

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. > I suggest this because somebody has started making changes to OggPCM > Draft2. That someone is me. I've asked about this on-list

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

On 2005-11-19, Jean-Marc Valin wrote: > Not sure this is a good idea. Remember that channel_map is just an > array (unless you want to make it a map?). So if you had a > OGG_CHANNEL_SPECIAL with an id of 1000, it would force 1000 entries in > the array. True, but remember that the channel map type implied the number of entries in the table, and also that in this organization

In November 2005 the discussion on OggPCM2 died down before we got around to finalizing the channel map. I thought it would be a good time to resurrect the topic. The previous threads are at http://lists.xiph.org/pipermail/ogg-dev/2005-November/000097.html and http://lists.xiph.org/pipermail/ogg-dev/2005-November/000168.html . In draft 2 of the spec, there are two types of channel maps: a

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

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

On 2005-11-17, Erik de Castro Lopo wrote: > I did flesh out the wiki a **little** more. Is the intent clearer now? 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,

Hi, Is there any way to automatically block all traffic from IP''s that try more than X number of blocked ports for a preset amount of time? The log I get every morning seems to be getting bigger and bigger with port scans and attempts to access various services, it would be nice if these IP''s could be automatically blocked for like a week or two.. I wouldn''t want

On 2005-11-16, Jean-Marc Valin wrote: > Otherwise, what do you feel should be changed? One obvious thing that seems to be lacking is the granulepos mapping. As suggested in Ogg documentation, for audio a simple sampling frame number ought to suffice, but I think the convention should still be spelled out. Secondly, I'd like to see the channel map fleshed out in more detail. (Beware