Fwd: GNOME GSoC 09 question

[Adam Schreiber <sadam clemson edu>]

Reposting reply to list.

---------- Forwarded message ----------
From: Easwar Hariharan <meindian523 gmail com>
Date: Sun, Mar 15, 2009 at 12:07 PM
Subject: Re: GNOME GSoC 09 question
To: Adam Schreiber <sadam clemson edu>


On Sun, Mar 15, 2009 at 7:15 PM, Adam Schreiber <sadam clemson edu> wrote:
> On Sun, Mar 15, 2009 at 5:44 AM, Easwar Hariharan <meindian523 gmail com> wrote:
>> Hi,
>> I received this email address for you from a friend on IRC,and he
>> mentioned that you are the GNOME admin for GSoC 09 and queries whether
>> ideas could be a valid GSoC project could be directed to you.Please
>> correct me if I'm mistaken,while I expound my idea.
>>
>> IDEA:
>> A plug-in for Rhythmbox to preferentially play a track from hard disk
>> than from a Last.FM stream using the bitrate metadata as a parameter
>> to determine which audio is of better quality in Python,and add it to
>> the play queue while removing it from the stream,or,in an alternative
>> idea,to allow the user to see that he has the same track on disk,and
>> decide which to play.
>>
>> BENEFITS:
>> This would ensure
>> 1]Conservation of bandwidth and
>
> Wouldn't you still be downloading the stream, but playing the file on
> disk for the duration of the song?  How would you tell Last.FM to hold
> the streaming and then later to start again with the next song?

Well,I plan to hold off the streaming,because otherwise there's no
conservation of bandwidth at all.What,IMO,makes this project big
enough is that I have no experience with real-life coding,so will
probably need some help understanding APIs and such,though I will
surely try to minimise such instances.

>
>> 2]Deliver (almost always) a better listening experience because in
>> general,IMO,tracks ripped to disk will have a higher bitrate than a
>> stream.
>> I know the audio quality would change depending on whether the track
>> was encoded using CBR,VBR or ABR algorithms and also whether it was
>> ripped using lossy or lossless algorithms,but I guess my approximation
>> is valid for quite a large number of users except the true
>> audiophiles.

<snip>

>
> I think it's possible that this project is large enough, but am not
> familiar enough with the internals of Rhythmbox to be sure.  CC'ing
> the list for additional comments.  In any case, this idea needs to be
> fleshed out before proposing because we need to be able to determine
> if you are capable of doing the proposed work.

I have already posted this idea to the Rhythmbox-devel list(zero
responses) and also spoken on the IRC channel(#rhythmbox on GIMPNet)
regarding this.If required,I can forward the IRC logs and the devel
list mail to you.The only factor I'm concerned about is that I haven't
explicitly laid out that I plan to work on this during SoC.

Also,could you point some starting areas where you think there's not
enough meat,so I can think it out and get back to you,and the RB-devel
list?

Thanks for replying,

Regards,
Easwar
Registered Linux user #442065