Re: [Rhythmbox-devel] In the mood: predictive playback for Rhythmbox

["Charlotte Curtis" <c f curtis gmail com>]

On Fri, Aug 1, 2008 at 5:16 AM, Kevin Hunter <hunteke earlham edu> wrote:
> At 6:36a -0400 on Fri, 01 Aug 2008, Tino Meinen wrote:
>>> if all of the song were analyzed, it could take days to complete
>>> the library.
>
> Hmm.  Just doing some quick back-of-the-envelope calculation with the
> previously mentioned 150GB:
>
> (1 song / 4 min) * (1 min / MB) * (1,024MB / GB) * 150GB = 38,400
>
> So, at an average length of 4 minute audio files and roughly 1 MB per
> minute, the above library had roughly 38,400 songs.
>
> My first thought is that there is *no way* someone will be able to
> listen to all those songs in a reasonable amount of time.  That's
> roughly 2,560 hours, 107 days, or almost 4 months of (ostensibly unique)
> audio!  Starting with that thought, as long as your code works and can
> complete audio file analysis *faster* than the wall clock equivalent of
> listening, who cares?

That is a good point, although it is fairly processor-intensive
process - on my desktop, it makes very little difference when analysis
is running, but on my old laptop, it causes the fan to spin up and
probably chews through batteries fairly quickly, so it'd be important
to be able to pause/restart the process on demand (which is something
I've been meaning to add in anyway).

I'm starting to think it would be a good idea for the 'time analyzed'
parameter to be a user-specified variable (maybe a slider between
'speed' and 'accuracy'), although the problem there is that a song
that has had 30 seconds analyzed *cannot* be compared accurately to
one that has had a minute analyzed, so if this parameter were changed,
the whole library would have to be re-analyzed.

>>> I'm not sure that I (or anyone else just testing) would be
>>> willing to wait for that,
>
> I hear you on wanting fast turnaround time while testing.  Are there
> other parameters you could tweak?  Like quality of analysis while testing?

I could change the quality of analysis while testing, but then it
wouldn't be a particularly accurate test... something to consider
though.

> I'm also curious what the hold up is from 2,500 to 38,500 songs.  If
> 2,500 is barely measurable, 38,500 should not take that much longer, eh?
>  Does analyzing a song depend on other songs?  Maybe the slowdown isn't
> your analysis routines but your lookup process?

Yes, the slowdown is in the lookup process.  Right now it's a very
simple brute-force approach - loop through all of the feature vectors
and check against the current top match.  I thought this would be okay
since it went very quickly on my system, but I might have to start
doing some more complicated clustering or something to improve the
speed.

>> If a song could be analysed while you listen to it, then the
>> database could be improved gradually as you go through your
>> collection.
>
> This is where the "process-in-chunks and save-your-progress" methodology
> could really help.  Let it not get in anybody's way while Rhythmbox is
> executing, stop when it's not executing, and restart from where it left
> off next chance it gets.
>
> Hope my 2 cent musings are helpful.
>
> Kevin

I appreciate it very much, thank you!

On Fri, Aug 1, 2008 at 8:07 AM, Adam Zimmerman <adam_zimmerman sfu ca> wrote:
> Would it be useful to analyze a few seconds of the song at regular
> intervals, so that you get bits of the entire song? Or does it need to
> analyze a whole block to work properly?

This is a very interesting idea, and I'd have to talk to the Marsyas
devs to see what they think, and perhaps do some testing of my own.
I'm not sure if it would work since it seems like it would make it
less likely to find a good match - the chances that two sections of a
song match two other sections of a song are less than with one
section, but on the other hand, a single section may not be
representative of the song.

Now I'm just starting to ramble, so I'll sign off - thanks for all
your thoughts,

Charlotte