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.
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 <sa...@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. > >> 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. 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. 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. 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. Alexandre Rosenfeld ------------------------------ FOG - The Fellowship of the Game http://www.fog.icmc.usp.br USP São Carlos - EESC/ICMC Engenharia de Computação 06 (Computer Engineering Student)
_______________________________________________ rhythmbox-devel mailing list rhythmbox-devel@gnome.org http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
