Re: GNOME GSoC 09 question

[Easwar Hariharan <meindian523 gmail com>]

On Mon, Mar 16, 2009 at 10:09 AM, Alexandre <airmind gmail com> wrote:
> Hi,
>
> I'm guessing you are not in the Gnome SOC list, so I'm sending this to you
> directly. I'm sending to the Rhythmbox list as well, where you asked about
> this some time ago.
You guessed right,but I have now subscribed.
>
> I have some experience writing Python plugins for Rhythmbox, so I'm hoping I
> can help you a bit.
>
> On Sun, Mar 15, 2009 at 3:06 PM, Adam Schreiber <sadam clemson edu> wrote:
>>
>> Reposting reply to list.
>>
>> >> 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.
>> >>
>
> You are going to have problems implementing a separate plugin for this using
> Python. The Rhythmbox internals is not entirely exposed in Python and the
> Last.fm streaming plugin is written in C. You are going to have difficulties
> interfacing with the Last.fm plugin in Python, or you'll end up rewriting
> the Last.fm streaming code in Python to do all you want.

Insurmountable difficulties as in enough difficulties to prevent me
from completing the project during SOC,or difficulties which can be
worked around with a bit of brain wracking?

>
>>
>> >> 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.
>
> First, are you sure you want to detect the better bitrate to choose which to
> play? I know it sounds cool, but in the end you are going to have a lot of
> trouble and the advantadges are really small. For instance, how do you know
> the Last.fm streaming bitrate? Unless you guess it, you are going to need to
> start the streaming just to know it's bitrate, and you can just sample a few
> bytes, because just as you said VBR can mess the calculations. So you'll
> waste bandwidth, and will make it take longer for the user to start
> listening to the song.

Well,I was planning to assume that Last.FM streams in CBR.....

> And as I said, Last.fm streaming code is inside the C plugin, which is not
> exposed in Python. You will have to mess with the C plugin, either directly
> implementing the code in C, or trying to expose an API out of the plugin
> (very hard to do IMHO).
> The Last.fm plugin source code is in
> http://svn.gnome.org/svn/rhythmbox/trunk/plugins/audioscrobbler/ if you want
> to take a look.

I have the source for RB,though I have to admit I understood zilch of it.

>
> Whetever you choose to detect bitrates or not, you'll still need to know
> which song Last.fm is trying to play and then put the disk song on the queue
> instead. In theory it is possible for you to detect this with Python, but it
> will give you a lot of work.
>
>>
>> >
>> >> 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?
>
> I think it is work enough, I just dont think it is worth it.

Alexandre,could we discuss this on IRC?Then maybe I will get a better
understanding of the stuff involved.If it's okay with you,please ping
me(easwar/meindian523) on #rhythmbox(or the GNOME SOC channel,if there
is one)

>
> Can I give another suggestion instead? You could make a plugin that takes
> any Last.fm feed (such as http://www.last.fm/api/show?service=285) and
> generates playlists with the Rhythmbox database. This would allow playing
> local music with data from Last.fm, giving an experience close to Last.fm
> stations without the streaming. And this could be implemented entirelly as a
> Python plugin, probably as a Rhythmbox source, with some nice GUI on top.
> I would really love if these (http://www.last.fm/api/show?service=301 and
> http://www.last.fm/api/show?service=329) APIs would be accessible that way.

Hmm,the services themselves look interesting,specially the loved
tracks one.What I think I might have a problem with is with
implementing it as a RB source,IIRC,RB is written in glade(that's what
a programmer friend told me),plugin looks easier.

Regards,
Easwar
Registered Linux user #442065