Tag: software

Karmic is still just “Linux for human beings.”

Man I wrote this a long time ago. Resign­ing now to the fact that I won’t fin­ish it.

Even a cou­ple years ago, video edit­ing was­n’t con­sid­ered an essen­tial part of a desk­top, for most users. It was the realm of pro­fes­sion­als and hob­by­ists who could afford the nec­es­sary hard­ware to transcode video in less than an hour.

But after the advent of YouTube, ade­quate proces­sors, and ubiq­ui­tous cam­eras — in phones, mon­i­tors, and now on the iPod nano — every­body feels that it’s their right to add scrolling text and wipes to their lit­tle movies. And right­ly so; video edit­ing soft­ware has long been expen­sive and dif­fi­cult for a rea­son. But it’s almost 2010, and that should­n’t be the case any­more. It’s no longer too much to expect to be able to put a title and a fade-out on a video where you com­plain about your hair, even if it is a triv­ial indul­gence. You don’t need to know HTML to run a blog; why should you need to learn script­ing lan­guages and FFm­peg switch­es to run a vlog?

Steve Jobs was famous­ly mis­tak­en in think­ing that the next step for per­son­al com­put­ing at the turn of the cen­tu­ry was video edit­ing, until it took a back­seat while Nap­ster made dig­i­tal music and the iPod the most promi­nent tech­nolo­gies of this decade. And as all that went on, proces­sors got out­ra­geous­ly fast, and hard dri­ves got out­ra­geous­ly large, even in “low-end” sys­tems. iMovie exist­ed, but has only recent­ly become famil­iar and com­fort­able to large num­bers of peo­ple. Microsoft­’s answer to iMovie, “Microsoft Win­dows Video Edi­tor 1.3” or what­ev­er it must have been called, was fee­ble, bug­gy, and went unused as most PC own­ers had to work hard to derive any­thing of val­ue from it; iMovie, mean­while, prac­ti­cal­ly asked Mac own­ers to use it. It’s my under­stand­ing that Microsoft­’s video edi­tor has improved late­ly, but I don’t know for sure.

Any­way, so here we are, with video edit­ing tak­en for grant­ed by some, and indig­nant­ly demand­ed by oth­ers. And, while we’re at it, a rel­a­tive­ly large migra­tion toward Ubun­tu. 8.10 Intre­pid was a land­mark release, 9.04 fol­lowed suit, and 9.10 is becom­ing unequiv­o­cal­ly the most antic­i­pat­ed Lin­ux dis­tri­b­u­tion by the gen­er­al pop­u­lace ever. Even in its beta form it’s being called “almost per­fect,” and gen­er­al­ly her­ald­ed every­where not only as a tri­umph of open-source, but as a tri­umph of oper­at­ing sys­tems peri­od.

There’s more to life than hard, ster­ile prag­ma­tism, and if you think oth­er­wise, you are cold and dead and nobody will ever love you.

So!, with all these peo­ple work­ing to make Lin­ux acces­si­ble, sure­ly they’ve got some decent video edi­tor up their sleeves? Well — as is a typ­i­cal answer from most Lin­ux users — yes and no. There is Cinel­er­ra, which is very pow­er­ful and enjoys a wide user base, but even its man­u­al admits to its Lin­ux her­itage, that “Cinel­er­ra is not intend­ed for con­sumers.” I can attest to this. In addi­tion to Cinel­er­ra I’ve down­loaded just about every video edi­tor there is for Lin­ux, from Avide­mux to Kden­live to Kino to PiTiVi. All of them either crash in Ubun­tu, are ter­rif­i­cal­ly com­pli­cat­ed, or lam­en­ta­bly sim­ple. Sim­ply put, there is no “iMovie for Lin­ux.”

But this is pre­cise­ly what Mark Shut­tle­worth is shoot­ing for with Ubun­tu. Or, rather, it’s a good metaphor for what he’s shoot­ing for — to make Lin­ux not mere­ly eas­i­er to use than oth­er dis­tros, but to be invit­ing to peo­ple who don’t even know what Lin­ux is. This is why Ubun­tu’s slo­gan — “Lin­ux for human beings” — has become so obso­lete. Of the things that Lin­ux pro­vid­ed when the Ubun­tu project began in 2004, Ubun­tu now pro­vides them in a more acces­si­ble way than they’ve ever been pro­vid­ed, and if a per­son has heard of only one Lin­ux dis­tro, it is like­ly to be Ubun­tu.

Now, how­ev­er, with Shut­tle­worth explic­it­ly tak­ing aim at Apple, Ubun­tu’s slo­gan — not mere­ly for mar­ket­ing pur­pos­es, but for the under­ly­ing vision of the project as a whole — needs to evolve. “Lin­ux for human beings” begins with the premise of Lin­ux, and qual­i­fies it with the promise of ease-of-use. In order to gain the sig­nif­i­cant mar­ket share that Shut­tle­worth wants to see, and to prop­er­ly ori­ent Ubun­tu’s devel­op­ers toward that end, the “Lin­ux” part of Ubun­tu needs to be sec­ondary. What must instead be empha­sized is that it is a pow­er­ful, easy, fun, and free oper­at­ing sys­tem that hap­pens to use a Lin­ux ker­nel.

These things are becom­ing increas­ing­ly true, but, as much as I am impressed by it, I can’t in good con­science say that Karmic ful­fills the ulti­mate­ly desired promise of Ubun­tu. Karmic is still just “Lin­ux for human beings.”

At the same time, nev­er before has this promise been more clear­ly with­in view. Sev­er­al hugehuge — things have hap­pened recent­ly, or are hap­pen­ing, to take Ubun­tu beyond its cur­rent sta­tus as mere­ly the best Lin­ux dis­tro, from an eccen­tric “third-par­ty can­di­date” to a gen­uine com­peti­tor. Aside from its huge­ly increased hard­ware sup­port out-of-the-box (which, bra­vo), I’m tempt­ed to argue that the improved font ren­der­ing in Jaun­ty is the sin­gle most impor­tant step in increas­ing Ubun­tu’s appeal — and fur­ther that any­body who dis­agrees with me is hope­less­ly out of touch with the real world.

Lin­ux users pride them­selves on with­stand­ing the most bru­tal of com­put­ing envi­ron­ments, but it’s that kind of ego­tism that, if unchecked, will pre­vent Lin­ux from ever gain­ing on the desk­top. If you think pret­ty wall­pa­pers are a friv­o­lous waste of your disk space, that’s your pre­rog­a­tive — but if you think that it was a bad deci­sion for Canon­i­cal to include them in Karmic, giv­en all that they’re try­ing to accom­plish, then you’re not pay­ing atten­tion. There’s more to life than hard, ster­ile prag­ma­tism, and if you think oth­er­wise, you are cold and dead and nobody will ever love you.

Alphabetization Is Not Fit for Music Libraries

Wikipedi­a’s arti­cle on alpha­bet­i­za­tion explains:

Advan­tages of sort­ed lists include:

  • one can eas­i­ly find the first n ele­ments (e.g. the 5 small­est coun­tries) and the last n ele­ments (e.g. the 3 largest coun­tries)
  • one can eas­i­ly find the ele­ments in a giv­en range (e.g. coun­tries with an area between .. and .. square km)
  • one can eas­i­ly search for an ele­ment, and con­clude whether it is in the list

The first two advan­tages are things you almost nev­er need to do with music libraries. And the third has been sup­plant­ed by now-ubiq­ui­tous search box­es: if you know what you’re look­ing for, you search; and if you don’t, an alpha­bet­ized list is not the way to find it.

Web vision­ary Ted Nel­son (<mst3k>Dr. Ted Nelson?</mst3k>) has been para­phrased as point­ing out that “elec­tron­ic doc­u­ments have been designed to mim­ic their paper antecedents,” and that “this is where every­thing went wrong: elec­tron­ic doc­u­ments could and should behave entire­ly dif­fer­ent­ly from paper ones.” If the fold­er metaphor is inad­e­quate for dig­i­tal doc­u­ments, no won­der it’s so piti­ful at han­dling music. The prox­im­i­ty between pieces of music in a library should least of all be based on the first let­ter in a band’s name – it’s as arbi­trary as sort­ing them by the vocal­ist’s month of birth – yet this is how it’s uni­ver­sal­ly done.

Music library orga­ni­za­tion needs to be re-thought from the ground up. We need to con­sid­er how it is that peo­ple used to lis­ten to music before it was all on their iTunes. How are your CDs orga­nized (or dis­or­ga­nized) on your shelf? How are they orga­nized in your head? What is it that prompts you to lis­ten to what you lis­ten to when you lis­ten to it? And how can we use com­put­ers to adopt and enhance these ways of think­ing, rather than forc­ing us to think like com­put­ers? Con­tin­ue →

foobar2000 Is Dead or Dying: Part 1

Orig­i­nal­ly writ­ten June 30, 2007.

There’s always been a sig­nif­i­cant fac­tion of foobar2000 users whose pri­ma­ry attrac­tion to the play­er is its appear­ance, or rather the lev­el of con­trol giv­en to its users over its appear­ance. In its infan­cy, with the stan­dard (and still default) UI, very lit­tle was pos­si­ble — the main win­dow con­sist­ed sole­ly of a tabbed playlist and sev­er­al func­tion­al tool­bars — but peo­ple nev­er­the­less took a lot of pride in mak­ing it their own, and some impres­sive things were done with rel­a­tive­ly min­i­mal flex­i­bil­i­ty. It was in the stan­dard UI that users began exper­i­ment­ing with album-lev­el pre­sen­ta­tion, choos­ing not to repeat redun­dant­ly the artist and album name on each line of the playlist, but to use the sec­ond, third, and some­times fourth lines to dis­play oth­er info, such as year, label, genre, replay­gain info, etc. Each of these cus­tomiza­tions was unques­tion­ably unique, but most of the broad details of the inter­face were con­sis­tent and inescapable.

The Columns UI com­po­nent began as an exper­i­ment in allow­ing for mul­ti­ple columns with­in the playlist dis­play, emu­lat­ing the Win­dows Explor­er “Detail” view (and many oth­er Win­dows pro­grams), with sorta­bil­i­ty via click­able col­umn head­ings. Even­tu­al­ly Columns UI added a side­bar and, lat­er, pan­els, allow­ing the whole foo­bar win­dow to be split up indef­i­nite­ly into pan­el-based com­po­nent dis­plays, the playlist view­er becom­ing just anoth­er one of these. This grant­ed much greater flex­i­bil­i­ty, allow­ing users to tai­lor the inter­face even more pre­cise­ly to their needs. You could now dis­play album art as promi­nent­ly as you want­ed, or not at all; your entire library tree could be embed­ded with­in the main win­dow, rather than tucked away in a pop-up; and with the track­in­fo pan­el’s excep­tion­al­ly lax (by that era’s stan­dards) styl­iza­tions, the per­son­al­iza­tion of your foo­bar became even more addic­tive, and, more impor­tant­ly, reward­ing.

Many seemed hell-bent on con­coct­ing the most gar­ish pre­sen­ta­tions imag­in­able: giant goth­ic blue-on-black cus­tom fonts, deep-red 200-px-tall spec­trum ana­lyz­ers, all, of course, cou­pled with cus­tom OS “vis.”

While some still pre­ferred the puri­ty and ele­gance of the stan­dard UI, the per­son­al­iza­tions made pos­si­ble by Columns UI were inar­guably func­tion­al ones, for the most part. Fonts, col­ors, dis­tri­b­u­tion of pan­els, and a rudi­men­ta­ry method of text align­ment were real­ly as far as you could go. At the core of all the boast­ed screen­shots was a rec­og­niz­able struc­ture, all slight vari­a­tions on the theme of playlist+trackinfo+albumlist+albumart. Out­side of dis­play­ing album art, there was noth­ing pro­found­ly new that Columns UI allowed you to do — rather, Columns UI gave you more con­trol over how you did what you need­ed to do.

Con­tin­ue →

Windows XP SP3

Microsoft pub­licly released Win­dows XP Ser­vice Pack 3 yes­ter­day, which means that it should appear in your list of avail­able updates. To grab your own stand­alone copy of the update, down­load the EXE or the ISO direct­ly from Microsoft. Life­hack­er also has a tuto­r­i­al on get­ting SP3 onto a Win­dows install disc to save your­self loads of trou­ble lat­er. Read what Ars Tech­ni­ca, Life­hack­er, and Wired have to say about the upgrade.

This ser­vice pack was rumored in Novem­ber (by Wired and CNET, among oth­ers) to offer a 10% boost in speed, but who knows under what con­di­tions it’ll actu­al­ly be notice­able. And all this amidst protests against Microsoft­’s plan to stop sell­ing XP this sum­mer. Even John Dvo­rak, whose columns I’ve been read­ing since ado­les­cence, hates Vista:

You’re not sup­posed to deliv­er a new oper­at­ing sys­tem that’s been in devel­op­ment for more than four years yet per­forms worse than the pre­vi­ous OS. Per­for­mance should be at the top, not the bot­tom, of the to-do list. You get the sense that Microsoft just piles code on top of code and some­where in the mid­dle of it all is MS-DOS 1.0.

I’ll say.

Songbird 0.5

Song­bird 0.5 was released last week, and, while not tech­ni­cal­ly incon­sis­tent with claims that its RSS pars­ing had been “improved,” I was dis­ap­point­ed to see that two of my three pod­cast sub­scrip­tions still aren’t com­ing through. The prob­lem has been migrat­ed to a new bug tick­et.

There’s also a new “Media Views” fea­ture, which looks promis­ing. As of now the only add-on to take advan­tage of this is a sim­ple tag-cloud library view, but I imag­ine things could get real­ly elab­o­rate there. Their line, “Tired of music play­ers that look like spread­sheets?”, has me antic­i­pat­ing all kinds of inno­v­a­tive brows­ing envi­ron­ments; pic­ture a nav­i­ga­ble mood-clus­ter ter­rain, or a pannable, zoomable, click­able his­to­ry wave­graph. I’m seri­ous­ly con­sid­er­ing teach­ing myself enough XUL to be able to write a hot­ness add-on.

Amaz­ing­ly, 0.1 was first released over two years ago. And their releas­es have code-names like Bowie and Eno? Who knew.

Some day, Songbird will:

  • have a prop­er Cov­er­Flow clone that does­n’t lag or rely on Java (like AlbumAp­plet), and that allows for cus­tom loca­tions of art on the dri­ve.
  • mon­i­tor fold­ers for new music.
  • have an inte­grat­ed Bit­Tor­rent client that puts music from track­ers direct­ly into your library.
  • jump to the loca­tion in a page where the cur­rent­ly play­ing mp3 was found.
  • prop­er­ly rec­og­nize all XML pod­casts (a known issue).
  • allow you to browse by when albums were added, when they were played (not just last played, but over their entire his­to­ry), and by hot­ness.
  • sub­mit to Last.fm.

And on that day…

Firefox 3 Rendering Improvements

Fire­fox 3 is sched­uled to be released lat­er this fall; I haven’t real­ly been fol­low­ing its devel­op­ment, but one thing I have heard about and am excit­ed about is its (or, more accu­rate­ly, Gecko’s) new graph­ics library, Cairo.

Cairo Image Resizing

First I heard that it would resam­ple rather than sim­ply rescale images, as demon­strat­ed in the image above (via Acts of Voli­tion).

Lat­er I learned that it will also ren­der fonts more smooth­ly. I enjoy the soft way pages look in Safari for Win­dows, the result of a dif­fer­ent ren­der­ing engine, WebKit, so this is some­thing I’m real­ly look­ing for­ward to. Here’s an exam­ple of Cairo’s font ren­der­ing, as seen in Camino 1.2+ for Mac, via hicks­de­sign:

Cairo Font Rendering

There are very spe­cif­ic rea­sons for the inten­tion­al dif­fer­ences in these approach­es to font ren­der­ing. It’s a mat­ter of per­son­al pref­er­ence, and I think my pref­er­ence will be for Cairo. Some are floored by the supe­ri­or­i­ty of WebKit, and design­er Jef­frey Zeld­man makes a sol­id, objec­tive case for it; oth­ers are hor­ri­fied.

Final­ly, Geck­o’s non-stan­dard CSS attribute -moz-bor­der-radius, a pre­cur­sor to CSS3’s bor­der-radius attribute, will make image-less round­ed div cor­ners easy and pret­ty (via Acts of Voli­tion):

Cario Border Radius

I would have post­ed screen­shots of my own, but I don’t trust these alpha builds not to eff things up.

FFmpeg Quality Comparison

Flash video is so great.

Any­way I used to use Medi­a­Coder to con­vert to flash video, but when it gave me errors, and refused to tell me the specifics of those errors, I took it old school to the com­mand prompt with FFm­peg (which Medi­a­Coder uses any­way). This gives you a lot of use­ful info about the source file you’re encod­ing, such as audio sam­pling rate, frame rate, etc.

Want­i­ng to find a bal­ance between pic­ture qual­i­ty and stream­a­bil­i­ty, I began encod­ing a short length of AVI video at dif­fer­ent com­pres­sion lev­els. FFm­peg calls this “qscale” (a way of rep­re­sent­ing vari­able bitrate qual­i­ties, much like LAME’s ‑V para­me­ter), and the low­er the qscale val­ue, the bet­ter the qual­i­ty. The avail­able qscale val­ues range from 1 (high­est qual­i­ty) to 31 (low­est qual­i­ty). Going worse than a 13 qscale pro­duces unac­cept­ably poor qual­i­ty, so that’s as low as I went for the pur­pos­es of this test.

I encod­ed 3:14 min­utes of an AVI, resiz­ing it to 500×374 pix­els, and encod­ing the audio at 96kbps and 44.1KHz, which sounds fine, and is a neg­li­gi­ble part of the ulti­mate file size, so going low­er would­n’t be very ben­e­fi­cial. Plus I find that good audio can cre­ate the illu­sion that the whole thing is of high­er qual­i­ty. Poor audio just makes it sound like “web video.”

Here are the results, cour­tesy of Google Spread­sheets:

FFmpeg quality vs. filesize chart

The file­size, of course, goes down as qual­i­ty goes down. And the loss in file­size also decreas­es, not just in amount, but in per­cent­age as well, as indi­cat­ed by the red line. For instance, the val­ue of the red line at qscale 3 is 33.97%, which means that in going from qscale 2 to qscale 3, 33.97% of the file­size is shaved off.

How­ev­er, because these loss­es are not per­fect­ly expo­nen­tial, I knew that there had to be qscale val­ues that were more “effi­cient,” in a sense, than oth­ers — val­ues that, despite being high, and caus­ing a low­er change in file­size than the pre­vi­ous step in qscale, still caused a com­pa­ra­bly large change in file­size. For instance, still look­ing at the red line, you’ll notice that going from 2 to 3, as I said, shaves off 33.97% of the file­size, while going from 3 to 4 only shaves off 23.93% of the file­size; and that is a 29.56% decrease in change-in-file­size, which is a rel­a­tive­ly large cost. We want the change-in-file­size to remain as high as pos­si­ble for as long as pos­si­ble.

Now, if you fol­low the red line from 4 to 5, you’ll see that that’s a 20.32% loss in file­size, which is pret­ty close to our pre­vi­ous 23.93% loss in file­size in going from 3 to 4. In fact, we’ve only lost 15.09% of change-in-file­size from the pre­vi­ous step. So these are the val­ues we real­ly want to exam­ine: change in change-in-file­size, rep­re­sent­ed by the orange line.

This is nowhere close to expo­nen­tial, nor does it fol­low any pre­dictable decline. It darts around, seem­ing­ly at ran­dom. And we want to catch it at its low­est val­ues, at points that rep­re­sent changes in qscale that were near­ly as effi­cient as the pre­vi­ous change in qscale. So the most desir­able qscale val­ues become, quite obvi­ous­ly, 5, 9, and 11.

What this means is that if qual­i­ty is your pri­ma­ry con­cern (and you’re not crazy enough to encode at qscale 1), go with 5. qscale 5 turns 3:14 min­utes of video into 30.62MB, which requires a down­load rate of 157.84KB/s to stream smooth­ly. qscale 11 will give you about half the file­size, and require a down­load rate of 77.37KB/s. But, because that’s the lev­el at which pic­ture qual­i­ty real­ly begins to suf­fer, and because most peo­ple don’t real­ly mind buffer­ing for a few sec­onds ini­tial­ly, I’m prob­a­bly going to stick with qscale 9, whose videos take up 91.58 kilo­bytes per sec­ond, and which is by far the most effi­cient qscale any­way, with only a 4.92% change in change-in-file­size.

One caveat: This whole exam­i­na­tion pre­sup­pos­es (as far as I can tell) that if it were pos­si­ble to mea­sure and chart the changes in the actu­al per­ceived visu­al qual­i­ty of videos encod­ed at these qscale val­ues, the curve would be per­fect­ly geo­met­ric or expo­nen­tial, with no aber­ra­tions sim­i­lar to those above, and with all extrap­o­lat­ed delta curves show­ing no aber­ra­tions either. Giv­en that, it might be eas­i­er to believe that every step you take through the qscale is of equal rel­a­tive cost, and that there are no “objec­tive­ly prefer­able” qscale val­ues. But that is a lot more bor­ing.