[xiph-commits] r13247 - websites/xiph.org/minutes/2007

[sping at svn.xiph.org]

Author: sping
Date: 2007-07-12 07:53:21 -0700 (Thu, 12 Jul 2007)
New Revision: 13247

Added:
   websites/xiph.org/minutes/2007/xiphmeet_20070711.txt
Modified:
   websites/xiph.org/minutes/2007/
Log:
#xiphmeet log of 2007-07-11


Property changes on: websites/xiph.org/minutes/2007
___________________________________________________________________
Name: svn:ignore
   + .project


Added: websites/xiph.org/minutes/2007/xiphmeet_20070711.txt
===================================================================
--- websites/xiph.org/minutes/2007/xiphmeet_20070711.txt	                        (rev 0)
+++ websites/xiph.org/minutes/2007/xiphmeet_20070711.txt	2007-07-12 14:53:21 UTC (rev 13247)
@@ -0,0 +1,661 @@
+[01:23] * Now talking in #xiphmeet
+[01:23] * Topic is 'Xiph.Org meeting channel | http://wiki.xiph.org/index.php/MonthlyMeeting200705'
+[01:23] * Topic set by kfish on Wednesday, 16 May 2007 at 08:04:12
+[01:23] * Statistics: 0 Ops, 8 Users (Total: 8)
+[01:23] * You are now known as sping_afk
+[02:01] * Atamido__ has quit IRC ("ChatZilla 0.9.78.1-rdmsoft [XULRunner 1.8.0.9/2006120508]")
+[04:03] * jchris (n=jchris at c-24-21-172-232.hsd1.or.comcast.net) has joined #xiphmeet
+[05:36] <jmspeex> I won't be able to make it to the meeting.
+[05:36] <jmspeex> However, I don't have much to say on anything on the agenda, except for OggPCM.
+[05:38] <jmspeex> About OggPCM, all I have to say is "this is too trivial to be worth much debate. If someone isn't happy about some aspect of it, they should propose changes now. Otherwise, I'd consider it done".
+[05:48] <jmspeex> Can someone paste the above when the topic comes up during the meeting?
+[06:03] * xiphmont (n=xiphmont at c-71-232-6-34.hsd1.ma.comcast.net) has joined #xiphmeet
+[06:03] * xiphmont has changed the topic to 'Xiph.Org meeting channel'
+[06:03] * xiphmont (n=xiphmont at c-71-232-6-34.hsd1.ma.comcast.net) has left #xiphmeet ("Leaving")
+[07:12] * xiphmont_ (i=xiphmont at nat/redhat/x-7f3751a8455e863b) has joined #xiphmeet
+[07:16] * illi_vanilli (n=illimina at c-67-183-114-157.hsd1.wa.comcast.net) has joined #xiphmeet
+[08:01] * _Ivo (n=adelaide at al-217-129-159-126.netvisao.pt) has joined #xiphmeet
+[08:02] <_Ivo> morning
+[08:05] * Atamido (n=atamido at cpe-70-116-0-240.austin.res.rr.com) has joined #xiphmeet
+[08:07] <xiphmont_> hi
+[08:08] <_Ivo> howdy
+[08:08] * izx (n=izx at sprocom2.ee.cooper.edu) has joined #xiphmeet
+[08:08] <_Ivo> shall we start this?
+[08:08] <xiphmont_> yes
+[08:08] <xiphmont_> _Ivo, I assume you're happy to chair?
+[08:09] <_Ivo> I suppose so
+[08:09] <_Ivo> agenda: http://wiki.xiph.org/index.php/MonthlyMeeting200707
+[08:10] <_Ivo> the first topic would be regarding OggPCM
+[08:10] <xiphmont_> Who all are we expecting who is not here?
+[08:10] <_Ivo> and if it's feasible we start seeing some support of it
+[08:10] <_Ivo> xiphmont_: I think everyone is but rillian and MSmith
+[08:10] <xiphmont_> I reviewed OggPCM a few months back and saw nothing I objected to or I thought needed addressing.
+[08:10] <xiphmont_> There has been debate over the exact design approach
+[08:11] <xiphmont_> But that's as much a personal and arbitrary design decision of a given engineering team as anything.
+[08:11] <xiphmont_> What I see there works and does what I'd expect it to.
+[08:12] <_Ivo> it seems to beat other PCM formats with more features, but my ignorance of the topic probably makes me biased
+[08:13] <xiphmont_> there has been complaint it's a little overcomplicated... eg
+[08:13] <illi_vanilli> if i remember, there is support in oggcodecs
+[08:13] <xiphmont_> why support both little and big endian storage when they're completely equivalent and trivial to convert back and forth?
+[08:14] <xiphmont_> And my take is 'their design decision is to support all the standard PCM formats directly without conversion.  That is an arbitray decision, and perfectly reasonable."
+[08:14] <jchris> on OggPCM, jmspeex left this message around 8:37PST: "this is too trivial to be worth much debate. If someone isn't happy about some aspect of it, they should propose changes now. Otherwise, I'd consider it done".
+[08:14] * kfish (n=conrad at 61.194.21.25) has joined #xiphmeet
+[08:15] <_Ivo> I agree with jmspeex
+[08:15] <xiphmont_> As do I.
+[08:15] <xiphmont_> Most objections were catalyzed by Arc is my recollection.
+[08:16] <xiphmont_> That may be an icorrect impression, but that's what I remember.
+[08:16] <xiphmont_> I have no objection to ratifying OggPCM.
+[08:16] <xiphmont_> As is, and immediately.
+[08:17] <_Ivo> kfish as just arrived -- do you have a different opinion, perhaps?
+[08:17] <_Ivo> has*
+[08:17] <kfish> _Ivo, about OggPCM? nope, no different opinion
+[08:18] <_Ivo> great
+[08:18] <_Ivo> then may we see some initial support for it in ogg123 and/or oggenc?
+[08:18] <xiphmont_> Oh, to clarify-- it's a strictly continuous stream type?
+[08:21] <_Ivo> I've never seen a PCM format being streamed, but I am not the appropriate person to reply to this.
+[08:21] <kfish> xiphmont_, from memory, yes, it's pretty simple
+[08:21] <kfish> just a number of frames per packet
+[08:21] <xiphmont_> OK
+[08:22] <kfish> actually, there's nothing in the spec about granulepos atm
+[08:22] <xiphmont_> I'm getting some motivation to finally set-in-code the whole continuous/discontinuous support distinction.
+[08:22] <xiphmont_> OK, then I can add to the Ogg mapping part of the doc.
+[08:22] <kfish> cool
+[08:22] <xiphmont_> 'All those who object are now dead or missing."
+[08:22] <_Ivo> and may they rest in peace
+[08:23] <xiphmont_> No, I want them to burn in Hell.
+[08:23] <_Ivo> shall we carry on?  the next subject is regarding OggPlay
+[08:23] <xiphmont_> Moving on.
+[08:23] <_Ivo> ha ha
+[08:23] * shans (n=shans at gaku-chan-nh.nsw.cmis.csiro.au) has joined #xiphmeet
+[08:23] <_Ivo> and I think the person working on its API just joined
+[08:24] <shans> the plugin?
+[08:24] <_Ivo> yap
+[08:24] <shans> :)
+[08:24] <_Ivo> so, what is the status of OggPlay right now?
+[08:25] <shans> well, we released a version of the plugin on www.annodex.net
+[08:25] <shans> there's still some things we could fix in oggplay itself, of course
+[08:25] <shans> but I'd like to release it soon
+[08:25] <_Ivo> great!
+[08:25] <shans> actually, I want to do a synchronised release of all of the annodex libraries
+[08:26] <shans> but yeah, close to release, definitely ready for use
+[08:26] <shans> the api not likely to change
+[08:26] <_Ivo> is it similar to what the WHATWG proposes?
+[08:27] <shans> ok, there's 2 different levels of code here, and 2 different APIs :)
+[08:28] <_Ivo> I see
+[08:28] <shans> so oggplay is a C library/API for extracting raw synchronised data from ogg files.  It provides a bunch of nice stuff for writing ogg players
+[08:28] <shans> whereas the plugin is build on oggplay and provides a javascript api to browsers
+[08:28] * lucas__ (n=chatzill at cpe-76-170-201-221.socal.res.rr.com) has joined #xiphmeet
+[08:28] <_Ivo> OK, then I was talking about the ecmascript API
+[08:29] <_Ivo> as in the reply to Silvia's message on WHATWG, http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-June/011611.html
+[08:29] * lucas__ is now known as lgonze
+[08:29] <shans> right
+[08:29] <_Ivo> welcoma, lucas
+[08:29] <_Ivo> e*
+[08:29] <shans> so there's a mapping of the whatwg features onto the plugin
+[08:29] <lgonze> hey folks
+[08:29] <shans> but the plugin provides a lot more as well
+[08:30] <xiphmont_> Hrm, I can't log into the wiki... I had an agenda item to add.
+[08:31] <_Ivo> xiphmont_: PM me and I'll add it -- it's not the best solution but..
+[08:31] <_Ivo> shans: all I want is that you guys don't end up reinventing the wheel
+[08:31] <shans> _Ivo: yeah, fair enough :)
+[08:31] <_Ivo> and duplicating work that's already been done, or make it uncompatible with what has already been done
+[08:31] <shans> _Ivo: we had a required feature set that we implemented.  It would be pretty trivial to add a whatwg mode though.
+[08:32] <shans> in fact, probably an entirely javascript task
+[08:32] <_Ivo> cool
+[08:32] <_Ivo> alright, shall we move to the next topic?
+[08:33] <_Ivo> that one being about the Oggless proposal
+[08:33] <_Ivo> it still misses the timestamp information that Conrad wanted to add
+[08:33] <_Ivo> but we can say it's pretty final, because no one else edited it further
+[08:34] <kfish> http://wiki.xiph.org/index.php/Oggless
+[08:35] <kfish> so, it's kinda a discussion about how to embedd vorbis and theora in non-ogg containers
+[08:35] <kfish> from the mplayer guys, right?
+[08:35] <kfish> and i suggested that if it's really going to describe how to do that, then it should also mention how to translate granulepos
+[08:36] <xiphmont_> Whether or not it comes from the mplayer guys, it's a reasonable thing to discuss :-)
+[08:36] <kfish> sure, just attributing the document :-)
+[08:36] <_Ivo> well, I tried to invite more mplayer folk, the VLC team, and even the matroska team
+[08:36] <_Ivo> all refused to come, it seems
+[08:37] * Kjoonlee (n=Kjoonlee at 83.233.39.161) has joined #xiphmeet
+[08:37] <kfish> what outcome would you like from that discussion?
+[08:38] <_Ivo> whatever pleases everyone
+[08:38] <kfish> eg. are projects already doing this, and in potentially incompatible ways?
+[08:38] <_Ivo> yes
+[08:38] <kfish> ok, do you have examples of that?
+[08:38] <_Ivo> I have heard of some wild warez files floating around; very few
+[08:38] <_Ivo> I never got any, though
+[08:38] <kfish> hmm
+[08:38] <xiphmont_> well, 'refused to come' and 'don't have the time/have already done it on their own, thanks' are different things.
+[08:39] <_Ivo> you have a point, sir
+[08:39] <xiphmont_> We hadn't done this till now because it really hadn't been high on our own priorities.
+[08:39] <_Ivo> let me rephrase that: no one find the time to come and discuss Oggless
+[08:39] <kfish> at the moment it feels like it is a document that isn't solving an existing problem
+[08:40] <kfish> perhaps if the existing incompatibilities were made clear, people would be more motivated to join the discussion
+[08:40] <xiphmont_> Like peeling, it *is* something a few people want-- just not enough to have made it worth the while till now.
+[08:40] <xiphmont_> And those who have really wanted it, have gone off and done spot implementation on their own.
+[08:41] <xiphmont_> If there was a clear problem with incompatable non-Ogg implementations we could reasonably help resolve... But I think the cows are already crushed under the barn doors, or however that saying goes.
+[08:41] <xiphmont_> Eg, I think it is a slightly higher priority to make is more clear how to use the codec libs without libogg.
+[08:42] <xiphmont_> That is, the bitpacker is built into libogg although it really doesn't need to be.
+[08:42] <xiphmont_> Still it is, and that gives the impression our codecs require Ogg.
+[08:42] <_Ivo> how do you suggest this to be done?
+[08:42] <xiphmont_> when really what they require is a bitpacker according to the spec.
+[08:43] <xiphmont_> JM and I discussed it on the Quebec trip
+[08:43] <xiphmont_> I think to make it clear we split libogg into libogg and libbitpack or something
+[08:43] <xiphmont_> and also rejigger the spec to seperate out the bitpacker specification into another document.
+[08:43] <xiphmont_> No *actual* changes to code flow.
+[08:44] <xiphmont_> Just how the namespace and information is presented.
+[08:44] <xiphmont_> At that point, -logg wouldn't be needed to build eg Vorbis and Theora 
+[08:45] <xiphmont_> In short, an exercise in clearing up a misperception.
+[08:45] <_Ivo> so, in theory, it's something feasable and that can be done quickly?
+[08:46] <xiphmont_> Anyway, I'm just bringing that up as something that is being handled.
+[08:46] <xiphmont_> it is on the development queue, not particularly high priority.  But in itself, a simple thing, yes.
+[08:46] <_Ivo> oh, great
+[08:47] <_Ivo> well next topic would be regarding Ambisonics
+[08:48] <_Ivo> seems like the discussion died and no one's mentioning it any more, these days
+[08:48] <xiphmont_> Well
+[08:48] <xiphmont_> I'm still building a rig.
+[08:48] <xiphmont_> I had been treating it as a long-term project of the 'I love building things' variety
+[08:48] <lgonze> :)
+[08:49] <xiphmont_> I was probably not going to be able to add much to the code discussion until then.
+[08:49] <xiphmont_> My basement contains about 200lbs of aluminum plate/rod, a cubic meter of solid oak planking, drivers, transformers, chipamps, etc.
+[08:49] <_Ivo> well, I remember that at some point someone (I think it was you) suggested that the best alternative would be to have a one library for all codecs
+[08:49] <izx> :O
+[08:50] <xiphmont_> _Ivo: meaning to do the ambisonic decoding?  
+[08:50] <_Ivo> it is a fine basement, if I ever saw one
+[08:50] <_Ivo> xiphmont_: yes
+[08:50] <xiphmont_> Yes, I think we should provide ambisonic decoding as a standalone lib, not as part of a specific codec.
+[08:51] <xiphmont_> I would expect to have my sateliites built in about two months.
+[08:52] <xiphmont_> Which reminds me, I need to find out how toxic aluminum dust is... ;-)
+[08:52] <_Ivo> that sounds dangerous
+[08:52] * izx has quit IRC (Excess Flood)
+[08:53] <_Ivo> well, I guess there won't be further developments til your rig is set and working
+[08:53] <xiphmont_> well, the new age hippie medicine freaks are on a complete anti-aluminum crusade right now, which makes it hard to get any accurate information.  OSHA/EPA/EU regulations suggest it is merely a 'nuisance dust'.
+[08:53] * izx (n=izx at sprocom2.ee.cooper.edu) has joined #xiphmeet
+[08:53] <xiphmont_> yes
+[08:53] <_Ivo> I wouldn't trust that "nuisance dust"
+[08:53] <xiphmont_> Ambisonics is still fully on my radar and I still intend it be the primary means of coupling in Ghost.
+[08:54] <xiphmont_> But there will be no further developments on my end for a little while yet, possibly not earlier than late fall/winter.
+[08:54] <izx> xiphmont: for multichannel coding?
+[08:54] <xiphmont_> yes.
+[08:54] <xiphmont_> That is a 'flight of fancy' as it were, but what I'd like to try first.
+[08:55] <xiphmont_> I'm pretty sure it can't replace normal stereo.
+[08:56] <xiphmont_> but for > stereo, I'd like to try using it as the internal surround representation.
+[08:56] <xiphmont_> But-- until I get there, I am talking out of my ass.
+[08:56] <_Ivo> Ambisonics is strange on how it works, but seems like it has a lot of potential
+[08:56] <_Ivo> anyhow
+[08:56] <izx> since multichannel would mostly be standard surround source --> standard surround speakers, depends on the R-D benefits, since the two conversions would introduce a degree of lossiness (?)
+[08:57] <xiphmont_> yes.
+[08:57] <izx> Ivo: yes, it's mesmerizing...
+[08:57] <xiphmont_> OTOH, the average surround nut is looking for a spatialization 'wow' and not fidelity.
+[08:57] <xiphmont_> the average stereo nut *is* looking for fidelity.
+[08:58] <_Ivo> it will be hard to please both groups, then
+[08:58] <xiphmont_> meh.
+[08:58] <xiphmont_> "I'm not worried.  Not yet."
+[08:58] <izx> but for surround, that adds a very interesting (and potentially lucrative) angle to the R-D at the encoder
+[08:59] <xiphmont_> oh yes
+[08:59] <xiphmont_> and decoder.
+[08:59] * shans has quit IRC ("Ex-Chat")
+[08:59] <xiphmont_> Oh, and in case you didn't already know, don't *ever* buy power tools from Sears.
+[09:00] <jchris> xiphmont_: I'm new to this, but have you listened to any DSD recordings? very high fidelity on the arrival-time, due to the sample rate. you can decode it with just a capacitor.
+[09:00] <izx> why?
+[09:00] <izx> jchris: "arrival-time"?
+[09:01] <xiphmont_> jchris: I have listened to many formats/amplifiers based on power integrals.  With a very clean power source and clock, they do indeed sound fantastic.
+[09:01] <xiphmont_> ...but it's mostly a technique in shifting what you have to get exactly right to make it sound good.
+[09:02] <xiphmont_> [we should keep moving and chat off topic in other channels]
+[09:02] <_Ivo> alright, then
+[09:02] <_Ivo> next topic is related to me somewhat
+[09:02] <_Ivo> as I proposed to change the license that I actually put in the first place
+[09:02] <_Ivo> anyone opposing wiki content to be licensed under CC-BY?
+[09:03] <kfish> what is it currently?
+[09:03] <_Ivo> CC-BY-SA
+[09:03] <kfish> why the change?
+[09:03] <izx> _Ivo: what's the reasoning behind it?
+[09:03] <_Ivo> more restrictive, doesn't allow content to be added to Wikipedia
+[09:03] <lgonze> I think that -BY is a good license for documentation.
+[09:04] <xiphmont_> ah, Wikipedia is the primary motivation?
+[09:04] <lgonze> that text is intended to be reused in a lot of different ways, and it doesn't have the same need to be viral as source code
+[09:04] <izx> just -BY makes perfect sense
+[09:04] <lgonze> or music for that matter
+[09:04] <lgonze> yes
+[09:04] <_Ivo> xiphmont_: no, SOM is, really
+[09:04] <_Ivo> but Wikipedia is a concern too
+[09:04] <xiphmont_> Wikipedia is a good reason all by itself.
+[09:04] <xiphmont_> SOMis too.
+[09:04] <kfish> who are the copyright holders on the wiki pages?
+[09:04] <kfish> i've got no problem with CC-BY, but how do we go about making the change?
+[09:05] <lgonze> what is SOM?
+[09:05] <_Ivo> I gave a one month notice to ask everyone's opinion
+[09:05] <_Ivo> lgonze: Spread Open Media
+[09:05] <lgonze> right.  thanks.
+[09:05] <_Ivo> and if nobody cares, I will simply switch
+[09:05] <_Ivo> I can't go after every single annonymous soul that contributed to XiphWiki
+[09:06] <_Ivo> the BY-SA is quite recent, too
+[09:06] <_Ivo> I added it because we had no license at all
+[09:06] <kfish> ah ok
+[09:06] <_Ivo> at first I suggested Public Domain, but then this Andrel guy
+[09:06] <_Ivo> said he wouldn't want that
+[09:06] <_Ivo> (he's a top contributor)
+[09:07] <_Ivo> so I ended up sticking BY-SA, but now realize it makes more sense to just go BY
+[09:07] <_Ivo> so nobody here opposes, right?
+[09:08] <xiphmont_> If the primary contributors agree with BY, you should go ahead and deal with objections when they arrive (if any)
+[09:08] <_Ivo> alright
+[09:08] <_Ivo> next topic is regarding Theora
+[09:08] <kfish> _Ivo, is the agenda up somewhere?
+[09:08] <_Ivo> it was supposed to be discussed back in May
+[09:09] <_Ivo> kfish: http://wiki.xiph.org/index.php/MonthlyMeeting200707
+[09:09] <kfish> ta
+[09:09] <_Ivo> since then, there was a new release of ffmpeg2theora
+[09:10] <_Ivo> which I do not know if superceds this
+[09:10] <_Ivo> (is that the word, superceds?)
+[09:11] <xiphmont_> well....it could be...
+[09:11] <_Ivo> and Ralph isn't here
+[09:11] <xiphmont_> 'preceeds, takes precedence over, renders moot.'
+[09:11] <xiphmont_> ...but I should hope not.
+[09:12] <kfish> well, there's been a few commits in the last week, and those guys aren't here atm
+[09:12] <kfish> giles, maikmerten, j at least
+[09:13] <xiphmont_> 1a: to cause to be set aside 1b: to force out of use as 
+[09:13] <xiphmont_>    inferior 2: to take the place, room, or position of : REPLACE 3: to 
+[09:13] <xiphmont_>    displace in favor of another : SUPPLANT
+[09:13] <_Ivo> maikmerten?
+[09:13] <kfish> https://trac.xiph.org/log/trunk/theora
+[09:14] <_Ivo> that maikmerten
+[09:14] <_Ivo> I guess this topic will have to be postponed
+[09:14] <_Ivo> and if neither ginger or sping_afk are here atm
+[09:14] <xiphmont_> regardless of specifics, I'd agree a libtheora release is needed.
+[09:14] <_Ivo> next topic will be about Vorbis
+[09:15] <_Ivo> oh
+[09:15] <xiphmont_> but let's leave specifics until input from those who know about them.
+[09:15] <_Ivo> Monty added the following to the agenda: We need to do a vorbis release; I spent a week going through Trac and fixing every libvorbis/libvorbisenc/libvorbisfile bug.
+[09:17] <xiphmont_> There is only one remaining bug I needed more input on, but a good fifty or so reasonably significant things got fixed throughout the encoder and decoder.
+[09:17] <xiphmont_> Including some really old ones (like the bug that was causing a crash on only one version of HPUX, etc)
+[09:18] <xiphmont_> Also, some number of malicious stream vulnerabilities got fixed (the decoder complains properly instead of crashing now) also got fixed.
+[09:18] <xiphmont_> Two or three of those bugs are actively annoying people doing 22kHz and below streaming.
+[09:18] <xiphmont_> Also
+[09:19] <xiphmont_> Libvorbisfile finally handles streams that are more than just unmultiplexed vorbis.
+[09:19] <xiphmont_> [adding that support also found a few old bugs]
+[09:19] <xiphmont_> [and doubtless added new ones.  Still, I'm pretty sure we're solidly in net benefit territory here]
+[09:20] <xiphmont_> so try hard to break the new libvorbisfile, a  release is imminent.
+[09:20] <xiphmont_> I'd also like to put out a call to our dormant Windows SDK maintainers... 
+[09:20] <xiphmont_> I'd like win32 to not be  trainwreck :-|  
+[09:21] <_Ivo> who are they, w32 maintainers?
+[09:21] <xiphmont_> I don't know that it is right now, but I don't know to the contrary and as every Microseft development system release is incompatable with thepreceeding ones....
+[09:21] <xiphmont_> _Ivo: It has been so long since a formal, binary release---- I don't know.
+[09:21] <xiphmont_> Also:
+[09:21] <xiphmont_> on the subject of win32
+[09:22] <xiphmont_> One of the previous maintainers (I don't remember which) mentioned that the .dll incompatability problems we traditionally have with win32 and binary distributions of the vorbis libs
+[09:22] <xiphmont_> has to do with using ANSI stdio, which win32 only sort of pretends to support (file descriptors aren't) and if we use the windows native primitives, our .dlls would work alot better.
+[09:23] <xiphmont_> I'd like someone to come commiserate with me about that; it's worth modifying vorbisfile if it saves outside devlopers a load of hassle.
+[09:23] <xiphmont_> That's all I have to say, pending any questions.
+[09:24] <kfish> i agree that win32 stdio support sucks
+[09:25] <_Ivo> still on the subject of vorbis, you mentioned over PM, and I think it's worth mentioning, that you intend to more often releases
+[09:26] <xiphmont_> well, there are more things on the Vorbis dev queue than just these fixes
+[09:26] <xiphmont_> I did not want to conflate new development with fixes of old bugs
+[09:26] <_Ivo> which is the sensible thing, really
+[09:26] <xiphmont_> For that reason, this should be an immediate bugfix release, followed by release of new development.
+[09:26] <xiphmont_> right
+[09:27] <xiphmont_> But that means a few releases this year, after a few years of only one or two (source only) releases.
+[09:27] <xiphmont_> It would be nice to get back to the old schedule we had when Jack (bless his heart) took on much of the release engineering tasks so that we churned out a new full build for everything every two months or so.
+[09:28] <kfish> wow, that would be awesome
+[09:28] <xiphmont_> because we actually have a level of ongoing development again that would justify it.
+[09:29] <xiphmont_> OTOH, binary releases every two months will only happen if there's release engineering.
+[09:29] <xiphmont_> And I don't want to sell that as a trivial task.  It's not hard, but it requires attention to multiple niggling threads.
+[09:29] <xiphmont_> It also requires beig friends with at least one person who owns a legit copy of a Microsoft compiler ;-)
+[09:30] <_Ivo> well, Microsoft does offer a free compiler, like a lite version of VS, or something like that
+[09:30] <_Ivo> that should make it easier to find someone
+[09:30] <xiphmont_> yes, and I'd like to see an nmake build for it.
+[09:31] <xiphmont_> but we should also have up to dave IDE project files in win32SDK/
+[09:31] <xiphmont_> BTW, could someone comment on:
+[09:31] <xiphmont_> https://trac.xiph.org/ticket/884
+[09:31] <xiphmont_> "thanks"
+[09:31] <xiphmont_> it's a mngwin ticket, but the question I asked that no one has answered is general to autotools.
+[09:32] <derf> That's a thomasvs question.
+[09:32] <xiphmont_> OK
+[09:33] <xiphmont_> Anyway, _Ivo, we may well be short on 'platforms other than linux' volunteers to do builds for binary releases.
+[09:33] <xiphmont_> and I'd like to talk with a win32 developer to deal with the dll linkage problem (file descriptors/stdio)
+[09:34] <xiphmont_> that is primarily what is holding up a libvorbis release.
+[09:34] <xiphmont_> Come end of week
+[09:34] <_Ivo> I think aoyumi works on windows
+[09:34] <kfish> xiphmont_, perhaps a mail to vorbis-dev or ogg-dev might help?
+[09:34] <xiphmont_> I may well set in motion a Linux binary / source rlease regardless.
+[09:34] <_Ivo> kfish, we can always try
+[09:34] <xiphmont_> kfish: fine idea.
+[09:34] <xiphmont_> "so obvious in retrospect'
+[09:34] <derf> xiphmont_: I've done plenty of dealing with win32 file I/O.
+[09:35] <xiphmont_> derf: sweet.  Enough to help me address this?
+[09:35] <derf> I would think so.
+[09:35] <xiphmont_> OK.  You and me hook up after this meeting/later this week then.
+[09:35] <derf> Will do.
+[09:35] <xiphmont_> I'll also ping Aoyumi.
+[09:36] <_Ivo> out of curiosity, what is sushivision?  I keep seeing new work on the SVN regarding it
+[09:36] <xiphmont_> I think we're set on libvorbis.
+[09:36] <xiphmont_> Sushivision is a graphing tool.
+[09:36] <xiphmont_> It is not one of our projects, I just use it as a development tool for projects.
+[09:36] <_Ivo> oh
+[09:37] <xiphmont_> it's meant to be a gui-interactive rapid graph/visualization panel.
+[09:37] <xiphmont_> You bolt complex sytems of equations onto it to play with them, or inject it into dsp code to watch the waveforms for debugging.
+[09:38] <_Ivo> that's handy for audio engineers, I reckon
+[09:38] <_Ivo> moving on, someone added libao to the agenda, but considering we got a new maintainer and I think even a new release that it's not an issue right now
+[09:38] <xiphmont_> as currently implemented, has turned out a little clunky.  With some time I will correct that.  Hasn't been a priority recently.
+[09:40] <xiphmont_> I see no comments on libao...
+[09:40] <_Ivo> oh no, my bad
+[09:40] <_Ivo> benjamin mentioned he would do a release
+[09:40] <_Ivo> I guess he never ended up doing it
+[09:41] <xiphmont_> Oh, and before we adjourn, I'd like to extend thanks to _Ivo for the recent organizational work he's been doing.
+[09:41] <_Ivo> gee, thanks :)
+[09:42] <_Ivo> oh there is actually a new libao release
+[09:42] <xiphmont_> We're mostly engineers who are mostly interested in only a small thread of what Xiph as a hole is doing, and we've not had many people interested in holding all the threads together.  It is much appreciated.
+[09:42] <_Ivo> http://downloads.xiph.org/releases/ao/libao-0.8.8.tar.gz
+[09:42] <_Ivo> found it
+[09:42] <xiphmont_> s/hole/whole/ ;-)
+[09:42] <xiphmont_> hee hee hee
+[09:43] <xiphmont_> "Xiph as a hole"
+[09:43] <_Ivo> thank you, I intend to continue to help out and make things work
+[09:43] <kfish> _Ivo, was the Mime types and file extensions topic discussed?
+[09:43] <_Ivo> kfish: not ye
+[09:43] <_Ivo> I was waiting to see if Silvia showed up
+[09:43] <_Ivo> yet*
+[09:43] <xiphmont_> ah
+[09:43] <_Ivo> Xiph as a hole
+[09:44] <_Ivo> we may go over the MIME/extension topic now, I guess
+[09:44] <_Ivo> there's only two left, XSPF and that
+[09:44] <xiphmont_> Oof, I dislike deprecating .ogg...
+[09:44] <kfish> ah ok, it sounded like we were finishing up
+[09:44] <_Ivo> .ogg will be working for Vorbis
+[09:44] <xiphmont_> I thought we were, we'd hit the end of the agenda
+[09:45] <_Ivo> but to avoid confusion .oga should be used for other audio stuff in Ogg
+[09:45] <xiphmont_> I understand the desire for other extensions...
+[09:45] <Kjoonlee> what about .spx?
+[09:45] <_Ivo> it shall remain .spx
+[09:45] <kfish> http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
+[09:45] <_Ivo> for compatibility reasons
+[09:45] <_Ivo> but imagine OggPCM, it would be .oga
+[09:45] <_Ivo> or Ogg FLAC
+[09:45] <kfish> xiphmont_, it doesn't deprecate .ogg, just specifies that it is for ogg vorbis I only
+[09:46] <xiphmont_> that is, strictly speaking, deprecation....
+[09:46] <_Ivo> of a kind, I suppose
+[09:46] <xiphmont_> eg, it's a well meaning retcon, but loses the point of the extension in the first place :-(
+[09:46] <kfish> well, it's more that that's what existing hw players expect
+[09:46] <_Ivo> but it was causing a lot of people headaches
+[09:46] <xiphmont_> I've come to not mind using .ogv (or something esle) for a/v ogg streams 
+[09:46] <_Ivo> and constant discussion on mailing lists (of which I'm responsible for at least two of them topics coming up)
+[09:47] <_Ivo> that's good to hear
+[09:47] <kfish> ie. there's a lot of stuff out there which will break if it tries opening a vorbis+theora file called .ogg
+[09:47] <xiphmont_> yes, because too many people were lazy about rejecting unsupported stream types.
+[09:47] <xiphmont_> .ogg was never, from the beginning, about just audio. :-(
+[09:48] <xiphmont_> and certainly not about just vorbis
+[09:48] <_Ivo> I guess it's too late to find who's to blame
+[09:48] <xiphmont_> well
+[09:48] <_Ivo> but that's the way it turned out
+[09:48] <xiphmont_> I'm not saying oga and ogv are bad
+[09:48] <xiphmont_> just that .ogg could still mean anything.
+[09:48] <xiphmont_> it hould be 'inspecific' not 'Vorbis I'
+[09:49] <kfish> would be nice, but what about existing players?
+[09:49] <xiphmont_> Anong other things, there's an only partially irrational reason for that
+[09:49] <xiphmont_> It's a bit like declaring '.mov' is only Sorenson + MACE.
+[09:49] <_Ivo> note to self: http://xiph.org/ao/ needs to be updated to reflect new release
+[09:49] <xiphmont_> .ogg is the flagship extension
+[09:50] <xiphmont_> and vorbisfile deals with non Vorbis I .ogg just fine now :-)
+[09:50] <kfish> ;-)
+[09:51] <kfish> nice timing mate
+[09:51] <_Ivo> at least we set an example
+[09:51] <_Ivo> well, before moving to the last topic, is anybody here AGAINST the final proposal for MIME Types and file extensions?
+[09:52] <_Ivo> speak now or forever be silent
+[09:52] <_Ivo> or something like that
+[09:53] <_Ivo> I guess not
+[09:53] <_Ivo> LAST TOPIC
+[09:53] <_Ivo> XSPF on Icecast
+[09:53] <_Ivo> lgonze: are you still there, mate?
+[09:54] <_Ivo> is Mike Smith the current maintainer for Icecast?
+[09:54] <xiphmont_> hey!
+[09:54] <xiphmont_> You can't call a vote when I leave to go pee!
+[09:54] <_Ivo> oops sorry
+[09:55] <xiphmont_> I'm against declaring .ogg only Vorbis audio.  That is all.
+[09:55] <xiphmont_> I do not mind suggesting .ogv for a/v files.
+[09:56] <xiphmont_> [For one thing IANA already accepted .ogg as application/ogg]
+[09:56] <_Ivo> alright, I'll inform Silvia and see if we can reach a consensus on ogg-dev mailing list regarding .ogg
+[09:56] <_Ivo> Silvia intended to change the MIME types
+[09:56] <xiphmont_> right, I was unaware of the debate.
+[09:56] <_Ivo> proposing new ones through a new RFC
+[09:56] <xiphmont_> I'll pay more attention.
+[09:57] <xiphmont_> [done]
+[09:58] <_Ivo> [Wed May 16 2007] [09:05:00] <nessy>	_Ivo: one RFC does indeed make a MIME Type endorsed by IANA
+[09:58] <_Ivo> http://xiph.org/minutes/2007/xiphmeet_20070516.txt
+[09:59] <_Ivo> anyway, discussion will go on on through mailing list
+[09:59] <_Ivo> I guess nobody from XSPF (besides me) is here...
+[09:59] <xiphmont_> :-(
+[09:59] <xiphmont_> "they are all sleepy"
+[10:00] <_Ivo> we waited two hours, and even Lucas joined, but he seems AFK
+[10:00] <xiphmont_> Lucas is sping?
+[10:00] <_Ivo> anyway, the point is that Icecast should work by default with XSPF
+[10:00] <_Ivo> xiphmont_: no, lgonze
+[10:00] <xiphmont_> ah!
+[10:00] <_Ivo> sping = Sebastain Pipping
+[10:01] <xiphmont_> right
+[10:01] <xiphmont_> should or currently does?
+[10:01] <_Ivo> it doesn't
+[10:01] <xiphmont_> ok
+[10:01] <_Ivo> so it probably should
+[10:01] <xiphmont_> agreed it should ;-)
+[10:01] <_Ivo> how feasable is that however, I have no idea
+[10:01] <xiphmont_> Anything to make icecast happier/friendlier.
+[10:01] <_Ivo> I was expecting some input from MSmith, but he ain't here
+[10:02] <_Ivo> anyone else familiar with the internals of icecast?
+[10:02] <xiphmont_> Unfortunately, not me :-(
+[10:03] <xiphmont_> It's been seven years since I even hacked on it.
+[10:03] <_Ivo> long time!
+[10:03] <xiphmont_> it is sad, yes.
+[10:04] <kfish> _Ivo, how about a mail to icecast-dev -- explain briefly what xspf is, example format, what you would like to implement
+[10:04] <_Ivo> not sad, you have other priorities
+[10:04] * Giloo (n=me at unaffiliated/gilou) has joined #xiphmeet
+[10:04] <_Ivo> kfish: I already did that
+[10:04] <kfish> what was the response?
+[10:04] <_Ivo> that would be the problem, because besides an Icecast enthusiast named Geoff
+[10:05] <_Ivo> I got no answer from any icecast hacker
+[10:05] <xiphmont_> well, you have a good reason to get up on MikeS's ass about it then.
+[10:05] <xiphmont_> Or, I could be a pest in proxy.
+[10:06] <xiphmont_> He'll probably redirect me, but there should be some internal pestary going on.
+[10:06] <xiphmont_> Yes, I made that word up.
+[10:06] <_Ivo> I will mail him directly, but if you see him on IRC, please do mention this
+[10:06] <_Ivo> pestary
+[10:06] * theneb_ (n=theneb at theneb.co.uk) has joined #xiphmeet
+[10:07] <Giloo> hmm, dunno if I should take part in the discussion here, but what's the point about icecast? :P
+[10:07] <theneb_> Hello all
+[10:07] <xiphmont_> talk about just making it in under the tape.
+[10:07] <_Ivo> hello theneb_
+[10:07] * theneb_ is now known as theneb
+[10:07] <Giloo> (and yeah, hi too ;))
+[10:07] <_Ivo> oh I got it wrong, it was a fellow named Thomas B. Ruecker
+[10:08] <_Ivo> who mentioned it was feasable
+[10:08] <xiphmont_> XSPF support in icecast.
+[10:08] <_Ivo> he tried to hack a XSLT to do the task
+[10:08] <xiphmont_> Is the current agenda item
+[10:08] <Giloo> why not talk to karlH?
+[10:08] <_Ivo> but report no success
+[10:08] <kfish> so, does icecast provide .m3u ?
+[10:08] <_Ivo> yes
+[10:08] <theneb> what is the time of the meeting in GMT?
+[10:08] <_Ivo> 06:00
+[10:08] <_Ivo> GMT 0
+[10:09] <_Ivo> it's now 8:00 UTC
+[10:09] <theneb> :P
+[10:09] <_Ivo> 09:00 in Portugal
+[10:09] <Giloo> I don't know if it's relevant here, but karlH works quite a lot on icecast by now, even if on a branch, so if you want something worked into it, it might be a good thing to ask him
+[10:09] <Giloo> 10:09 in France ;)
+[10:09] <Giloo> GMT+2
+[10:09] <_Ivo> Giloo: how may I get i touch with karlH
+[10:09] <_Ivo> in*
+[10:09] <Giloo>  /query karlH
+[10:09] <xiphmont_> karlH has been off on a branch for a long time.  MikeS is more in touch with the mainline.
+[10:09] <Giloo> karl at xiph.org
+[10:10] <xiphmont_> either is a good contact choice.
+[10:10] <Giloo> I don't know why karlH is not on the mainline version
+[10:10] <Giloo> but I think he's got mainly a technical problem about it
+[10:10] <_Ivo> it will be worth to contact him, too
+[10:10] <Giloo> (SVN access or something)
+[10:10] <xiphmont_> karlH's ability is occasionally overtaken by his enthusiasm to hear MikeS tell it.
+[10:10] <xiphmont_> I don't know if that's really the case, or if MikeS is just being a bastard.
+[10:10] <Giloo> dunno either, should ask karlH
+[10:10] * kfish has quit IRC (Remote closed the connection)
+[10:11] <Giloo> I'm running icecast-kh by now anyway, as 2.3.1 is not relevant for many purposes :)
+[10:11] <Giloo> so, yeah, contact karlH :)
+[10:11] <xiphmont_> OTOH, MikeS is in charge of mainline, and there are a number of stability reasons he hasn't merged all of karlH's work./
+[10:11] <Giloo> indeed, he's working on a branch for this precise reason
+[10:11] * kfish (n=conrad at 61.194.21.25) has joined #xiphmeet
+[10:11] <xiphmont_> rapid development often implies instability, yes.
+[10:12] <Giloo> of course
+[10:12] <Giloo> but do MikeS review actually the kh work? :)
+[10:12] <xiphmont_> yes.
+[10:12] <Giloo> nice
+[10:12] <xiphmont_> How often, I do not know.
+[10:12] <_Ivo> last time MSmith reported status of icecast: he said there would be no further developments any time soon...
+[10:13] <xiphmont_> But they are definitely in sync in general.
+[10:13] <xiphmont_> Oh?
+[10:13] <_Ivo> I hope they are
+[10:13] <Giloo> well, I don't mean to be rude anyway, but the merge between some kh code and mainline is turning a little on the Duke Nukem Forever kind of joke :)
+[10:13] <xiphmont_> well, we should probably ask MikeS again to be sure.
+[10:13] <_Ivo> <MikeS> Icecast: moribund!
+[10:13] <_Ivo> <MikeS> (but supported; just not really any active development going on, but not much needed either)
+[10:13] <Giloo> but I'm not involved in that too much, though I hack and test -kh branch, so I wouldn't know
+[10:13] <xiphmont_> ah
+[10:14] <Giloo> http://www.icecast.pwp.blueyonder.co.uk/
+[10:14] <xiphmont_> It reached a point of 'finished' like cdparanoia: It hits all the original bullet points, further development would be a new generation
+[10:14] <Giloo> in case you don't know
+[10:14] <_Ivo> xiphmont_: oh
+[10:14] <_Ivo> in that case, all's well
+[10:14] <_Ivo> more or less
+[10:15] <xiphmont_> well, if kh's is the new generation, we should start looking at that as becoming a new mainline.
+[10:15] <_Ivo> speaking of cdparanoia, the HA community shuned on it completely in favor of EAC :(
+[10:15] <Giloo> this is a kind of great idea xiphmont_ ;)
+[10:15] <xiphmont_> If the HA community is using windows, they have to use EAC anyway.
+[10:15] <Giloo> well, according to me, icecast 2.3.1 is becoming fastly irrelevant
+[10:15] <_Ivo> I reckon paranoia's available for windows too, am I wrong?
+[10:15] <xiphmont_> EAC and cdparanoia are slightly different philosophies anyway.
+[10:16] <xiphmont_> _Ivo: no.
+[10:16] <_Ivo> oh nvm, then
+[10:16] <_Ivo> I will contact kh, though
+[10:16] <xiphmont_> EAC makes use of more special hardware features, and strongly prefers the more expensive drives.  cdparanoia i intended to not trust any hardware feature, and work as well as possible with any cdrom drive.
+[10:17] <izx> xiphmont: "special hardware features" = C2 ECC?
+[10:17] <xiphmont_> that said, the world of cdrom drives has changed since the last active development of cdparanoia, and there are new things it could do that it currently does not.
+[10:17] <xiphmont_> izx: yes.  
+[10:18] <xiphmont_> When cdparanoia was written, only a few drives reported it, and they all 'made up' the data after the fact.
+[10:18] <xiphmont_> C2 ECC was completely useless until a few years ago.
+[10:18] <izx> then i'd disagree a bit on the expensive drives aspect, from experience
+[10:18] <izx> although the HA folks are fixated on Plextor
+[10:18] <_Ivo> Plextor Plextor Plextor
+[10:18] <xiphmont_> Plextor was, once upon a time, cream of the crop.  Around 2002, I started having more trouble with Plextor drives than alot of the cheapies.
+[10:19] <xiphmont_> They tried to impleemnt their own reread-correction in hardware and tended to lock up/error out long after the OS had timed out the command.
+[10:20] <xiphmont_> eg, going incommunicado for 15 minutes while locking the SCSI bus is a good way to piss off the OS/user.
+[10:20] <izx> of course
+[10:20] <xiphmont_> Matbe that's fixed now.
+[10:20] <xiphmont_> regardless, EAC started out as a very plextor-centric tool.
+[10:20] <xiphmont_> It's expaned since then.
+[10:21] <izx> didn't plextor come out with their own utility for DA extraction?
+[10:21] <xiphmont_> When I looked at it, it generally assumed that, eg, if the drive reported ECC C2 support, that the support could be trusted.  That genrally wasn't the case 'back when' and isn't always the case now.
+[10:21] <_Ivo> heck, EAC won't even be updated any longer
+[10:22] <xiphmont_> OTOH, for well matched hardware, using these features means it will in fact work better / do more than cdparanoia.  No question.
+[10:22] <xiphmont_> Oh, and cdparanoia needs to be updated to use more of the new ATAPI command set.  That's been extended too, to do things like force unit access, etc.
+[10:22] <xiphmont_> Anyway, all irrelevant to the meeting.
+[10:23] <izx> oh absolutely...my old NEC DVD-RWs (before they merged with Sony) are >95% accurate with C2, but there's the occasional ECC mismatch
+[10:23] <izx> <too lazy to switch to another channel> :)
+[10:23] <xiphmont_> I had more wacky problems with NEC drives...
+[10:23] <_Ivo> oh, I believe the meeting is mostly over anyway
+[10:23] <_Ivo> we coevered all topics
+[10:23] <xiphmont_> The old Multispins were the most amazing DAE disasters...
+[10:23] <_Ivo> and it was a fine meeting
+[10:24] <xiphmont_> I've seen drives drop stereo frames or even one sample out of a frame, but the NEC drives would drop individual *bytes* out of the 16bit stereo stream.... they would also randomly abort DMA internally.
+[10:24] <xiphmont_> yup.
+[10:24] <izx> wow
+[10:24] <xiphmont_> all done.  I should go work.
+[10:25] <_Ivo> alright then
+[10:25] <kfish> _Ivo, thanks for chairing
+[10:25] <_Ivo> anyone logged it?
+[10:25] <xiphmont_> yes, thanks _Ivo
+[10:25] <_Ivo> np
+[10:25] <_Ivo> have to go too
+[10:25] <xiphmont_> No, but I have the whole thing in scrollback if you want me to cut&paste&mail
+[10:25] <_Ivo> I can do that, too
+[10:25] <xiphmont_> OK
+[10:27] <_Ivo> alright, all done; thanks everyone for coming
+[10:27] <_Ivo> be seeing you on the mailing lists
+[10:27] <kfish> cheers, l8r
+[10:28] <_Ivo> later
+[10:28] * _Ivo has quit IRC (Remote closed the connection)
+[10:28] * kfish (n=conrad at 61.194.21.25) has left #xiphmeet ("Fish!")
+[10:29] * jchris has quit IRC ()
+[10:30] * Giloo (n=me at unaffiliated/gilou) has left #xiphmeet ("Quitte")
+[11:13] <ginger> darned I missed the meeting
+[12:15] <ginger> xiphmont_: you might want to read the following thread re file extensions: http://lists.xiph.org/pipermail/ogg-dev/2007-April/000457.html
+[12:16] <xiphmont_> ginger: will do
+[12:16] <ginger> also note that the wiki changed along with that thread :)
+[12:16] <ginger> maybe we can continue on that thread with your objections, and come to an agreement that suits all needs
+[12:17] <xiphmont_> I agreed with the position you put forth in your first message, then stopped reading the thread first time around :-)
+[12:17] <ginger> we made some changes, in particular since HW players are breaking on Ogg Theora files that have the .ogg extension
+[12:18] <ginger> and it is easier to change software than HW
+[12:18] <xiphmont_> breaking meaning refusing to play, or locking up or...?
+[12:18] <ginger> any of these things
+[12:18] <xiphmont_> well, refusing to play is fine...
+[12:18] <xiphmont_> locking up is a problem
+[12:19] <ginger> I haven't tested personally though
+[12:19] <xiphmont_> My only major problem with the Wiki position is that it effectively abandons the flagship extension to a codec that I hope to replace within a year.
+[12:19] <xiphmont_> Vorbis will eventually die, and .ogg will never be seen again.
+[12:20] <ginger> I think you may be over-optimistic :)
+[12:20] <xiphmont_> aboutthe year timeline?  Oh, yes :-)
+[12:20] <ginger> yeah :)
+[12:20] <xiphmont_> in five years?  Not overoptimistic.
+[12:21] <ginger> I guess the real question is: how much do we care about people who have an existing ogg HW player and will continue to expect .ogg files to only be Vorbis I
+[12:22] <ginger> if we don't look back, we can easily go with my original suggestion
+[12:22] <xiphmont_> I don't think it's a question of not looking back... how many people stuff .ogg files they have no idea what they are onto a HW device?
+[12:23] <ginger> hmm...
+[12:24] <ginger> http://wiki.xiph.org/index.php?title=MIME_Types_and_File_Extensions&oldid=6710
+[12:25] <ginger> this was the last wiki entry before the xiph meeting that introduced .ogx
+[12:26] <xiphmont_> .ogx?
+[12:26] <ginger> http://xiph.org/minutes/2007/xiphmeet_20070516.txt
+[12:26] <ginger> introduced .ogx
+[12:27] <xiphmont_> Ah.  I'd not even heard of the .ogx
+[12:27] <xiphmont_> I missed the May meeting
+[12:27] <ginger> ,ogx is on the current wiki page
+[12:28] <ginger> http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
+[12:28] <xiphmont_> I had read it earlier tonight and somehow completely missed the .ogx extension
+[12:28] <ginger> ok, no worries
+[12:29] <xiphmont_> But really-- I should step back and go with my earlier declaration.  I don't really want to get mixed up in this eternal argument and as such I should not be taking a position.  I will be sad to see .ogg go.
+[12:29] <ginger> I think you have valid reasons and we should consider these
+[12:29] <xiphmont_> .ogx as 'ogg multiplex' is not a stupid idea, although having like four recommended extensions is a bit much.
+[12:30] <ginger> I think a discussion should be had on the mailing list, so we can make sure we ahve considered all options
+[12:30] <ginger> four is heaps less than what mpeg has :)
+[12:30] <ginger> and our four are well thought out
+[12:30] <xiphmont_> My only concern is that the format is Ogg, but the only ogg files named .ogg are Vorbis.  Oh well.
+[12:30] <ginger> that's the majority of files out there right now
+[12:31] <xiphmont_> I still don't really want to get involved or muddle it up.
+[12:31] <xiphmont_> well, yes, right now.
+[12:31] <ginger> but we need you to stand behind the decision, too
+[12:31] <xiphmont_> Oh, I didn;t say I would sabotage or somehow suggest I didn;t like it :-)
+[12:31] <ginger> I would not want you to have to say ... this was community decision, but I don't really support it :)
+[12:31] <xiphmont_> If we decide internally this is the decision, that's the decision and I will stand behind it.
+[12:32] <xiphmont_> that was never in question.
+[12:32] <xiphmont_> Well, OK--- while Arc was around, all bets were off.
+[12:32] <xiphmont_> But Arc is no longer around.
+[12:32] <ginger> btw: .anx is turned irrelevant, too - .ogx will do for that, too
+[12:33] <ginger> it's like: .ogg and .anx are special cases of .ogx
+[12:33] <ginger> and so are .spx, .axa and axv
+[12:33] <xiphmont_> My preference would have been everything is a special case of .ogg-- but I understand the practical reason for bucking that.
+[12:34] <ginger> we really only need .ogx, .ogv and .oga - because all an application wants to know is whether it's audio or video
+[12:34] <xiphmont_> OK
+[12:34] <xiphmont_> I'm not going to argue with that, and I'll get used to it.
+[12:35] <ginger> so - you're ok with the current version then?
+[12:35] <xiphmont_> Yes, I withdraw my objections.
+[12:36] <xiphmont_> we should emphasize .ogx, .oga, .ogv moving forward.
+[12:36] <ginger> ok - just wanting to make sure the reasons are clear :)
+[12:36] <xiphmont_> BTW-- what is the story dealing with IANA on this issue.?
+[12:36] <ginger> awesome - I will go forward and change the RFCs
+[12:36] <ginger> not a big issue, I think
+[12:36] <ginger> we can just change the RFCs and let IANA know
+[12:37] <xiphmont_> ...really?  OK.
+[12:37] <ginger> I think so...
+[12:37] <ginger> haven't tried yet
+[12:38] <ginger> we'll cross that bridge when we get to it
+[12:38] <xiphmont_> "we'll burn that bridge as we cross it."
+[12:39] <xiphmont_> I have to remember I care about the engineering and not the political battles.
+[12:43] <ginger> hehe
+[12:43] * ginger was just trying to find another case where a registered MIME type was changed later
+[12:43] <ginger> wasn't successful
+[12:44] <ginger> so, we see about the reaction...
+[12:44] <xiphmont_> First time was probably the hard part.
+[12:45] <ginger> it was my learning experience