Alphabetization: Part II

First, some good news: Song­bird is now in pub­lic beta! It’s amaz­ing how sta­ble things have got­ten just over the last six months. And, sig­nif­i­cant­ly, it now fea­tures a Play­back His­to­ry API, which by the looks of things allows devel­op­ers access to the entire play his­to­ry of any song in a library, some­thing that is cru­cial to the kind of deep library scav­eng­ing I’ve been pin­ing for.

Since I last wrote, every­thing I see or read seems to inspire my half-baked ideas about the bet­ter ways we can browse our unman­age­ably large music libraries. After telling a friend about these ideas, he said:

Yeah, it’s actu­al­ly real­ly frus­trat­ing. I inten­tion­al­ly keep the num­ber of artists on my iPod small so I don’t have to sort to find things I’m cur­rent­ly into.

Me too.

Then there are the peo­ple who are doing a lot of (real) work towards nov­el inter­faces like the (hypo­thet­i­cal) ones I’m describ­ing; Last.fm’s “Islands of Music” (explained here) demon­strates the kind of artist-sim­i­lar­i­ty topol­o­gy that would make brows­ing your library a more pleas­ant expe­ri­ence; Lee Byron explains in more detail how he devel­oped that Last Graph info­vis; nec­i­mal releas­es a Music Rec­om­men­da­tions exten­sion for Song­bird that promis­es to use Last.fm’s data to find with­in your library artists sim­i­lar to the one play­ing; and the Auro­ra project, part of the Mozil­la Labs con­cept brows­er series, depicts a rad­i­cal three-dimen­sion­al view of files and data with auto-clus­ter­ing, which, if applied to a music library, would be noth­ing short of incred­i­ble.

I’ve also thrown togeth­er a piti­ful lit­tle mock-up of what Song­bird might look like when you start it up with the kind(s) of exten­sions I’m hop­ing for:

The two core com­po­nents depict­ed are the Start Page and the Time­line View. The Start Page I feel would be seri­ous­ly valu­able, one of the ideas behind all these blath­er­ings of course being that one doesn’t always have a des­ti­na­tion in mind when open­ing their music library. The Start Page would offer a num­ber of con­ve­nient “jump­ing-off” points, pulling you into your library to explore it fur­ther — by artist sim­i­lar­i­ty, maybe, or by play his­to­ry prox­im­i­ty, after just a cou­ple clicks.

The Time­line View is a zoomable time­line, shown here zoomed to a dai­ly view. Zoom­ing out could show you albums played with­in recent weeks; then months, quar­ters, etc. These albums might be sort­ed by Peri­od­i­cal Impact, some­thing I explained in depth here; essen­tial­ly they would be sort­ed not by the raw num­ber of times they were played with­in any giv­en peri­od, but by how dis­tinct they were to that peri­od.

Even these mea­ger ideas are leagues ahead of what’s avail­able, and I’m not even a data ana­lyst. Just imag­ine how a library’s play his­to­ry data could be exploit­ed by some­body trained in these things.

Last.fm Seasonal Impact Indices

Everyone’s expe­ri­enced that thing where you’re lis­ten­ing to some­thing, and you think to your­self, “Holy shit does this remind me of fall 2004.” How strong­ly cer­tain music is cor­re­lat­ed with cer­tain peri­ods of your life depends on many things, includ­ing but prob­a­bly not lim­it­ed to when you first heard it, when you first liked it, and when your lis­ten­ing to it was most high­ly con­cen­trat­ed. So, for instance, in my case, most Destroy­er albums will recall times and places that are vague at best, and that depend most­ly upon first expo­sure rather than con­cen­tra­tion — this as a result of the fact that I lis­ten to every Destroy­er album all the time, approx­i­mate­ly.

Blueboy’s Uni­sex, on the oth­er hand, will prob­a­bly always remind me of the win­ter of 2006–7, as I lis­tened to it for the first time that sea­son, nine addi­tion­al times with­in that sea­son (rack­ing up about 150 tracks lis­tened, accord­ing to Last.fm), and vir­tu­al­ly nev­er again once spring hit.

Ever since I began sub­mit­ting lis­ten­ing data to Last.fm in Novem­ber of 2004, I’ve won­dered whether I’d ever enjoy direct access to all those num­bers. Then came Last.fm Extra Stats, mer­ci­ful­ly col­lect­ing all my lis­ten­ing data for me in a tab-sep­a­rat­ed file that can be pulled into Excel and manip­u­lat­ed to my heart’s con­tent. Here, as a small exam­ple of the data, are my top ten artists (by tracks lis­tened) from win­ter 2006–7, along with total lis­tens for each artist (since Novem­ber 2004) (now that I’m final­ly get­ting around to pub­lish­ing this post, all the fol­low­ing data is very old):

Win­ter 2006–7
Artist Win­ter (S) ↓ Total (T)
Trans Am 163 163
Blue­boy 148 163
The Luck­smiths 69 105
Ratatat 50 126
The Moldy Peach­es 49 51
White Flight 36 41
Tele­vi­sion Per­son­al­i­ties 35 35
Beach House 35 64
Revolv­ing Paint Dream 32 58
RJD2 31 52

Now for some method­ol­o­gy. Con­tin­ue →

Alphabetization Is Not Fit for Music Libraries

Wikipedia’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 vocalist’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 →

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

Hotness 1.6.c.1

Total­ly war­rant­ed sub­ver­sion­ing!

My for­ay into MP3Toys was ulti­mate­ly short-lived, brought to a halt when I found what peo­ple were doing with Sin­gle Col­umn Playlist for foo­bar, par­tic­u­lar­ly the playlist-embed­ded album art. Back in the foo­bar sad­dle, I also gave in and tried out the “offi­cial” Play Count com­po­nent, which I had avoid­ed for so long because it didn’t sup­port %FIRST_PLAYED%, and because I wasn’t sure I want­ed my play­back sta­tis­tics only kept in the data­base — even though writ­ing them to the files posed a lot of trou­ble as well. Turns out, play­back sta­tis­tics stored by the offi­cial com­po­nent are less sen­si­tive to changes to the files it’s keep­ing track of than the unof­fi­cial one, which means I only have to be a lit­tle care­ful to keep all my stats intact, while being able to play and track files that I’m still seed­ing.

This, along with the invalu­able $cwb_datediff() func­tion pro­vid­ed by Bowron’s new foo_cwb_hooks com­po­nent, called for a rewrite to the hot­ness code, which had been stag­nat­ing in some mar­gin­al­ly com­pat­i­ble 1.5 ver­sion since May. After severe­ly trim­ming the code down and robust­ing things up, I thought of a new and total­ly non-arbi­trary way to soft­en the blow hot­ness scores receive when songs are played. I hat­ed see­ing them leap to 100 every time, and this new soft­en­ing method makes so much sense, uti­liz­ing exist­ing base­line cal­i­bra­tions to keep things a lot more inter­est­ing. How any­body tol­er­at­ed the old method is beyond me.

Any­way, here it is.

I also dug up a lot of old screen­shots this week and I’m plan­ning a nos­tal­gia-fueled ret­ro­spec­tive in the near future.

Verbal Timestamps for fb2k

Last week I spent some time devel­op­ing this algo­rithm in fb2k’s title­for­mat­ting script to trans­late numer­i­cal time­stamps (YYYY-MM-DD HH:MM:SS) into nat­ur­al Eng­lish text (“Fri­day Evening”).

verbal timestamps screenshot

It’s pret­ty cool. So, uh, here it is. Con­tin­ue →