Fwd: GSoC draft application
vedant agarwala
vedant.kota at gmail.com
Thu Apr 25 04:05:45 UTC 2013
Hello,
Below is the email I sent to amarok-devel but there was no reply. It
must've slipped through. Could you please have a look at my application
before I can submit it.
And, I want to ask, what is meant by "ffmpeg + libofa to Phonon +
chromaprint (library to compute AcoustIDs) Viability of Phonon for this
task needs to be verified" in the GSoC idea page for "Amarok: improving and
modularizing tag
guessing"<http://community.kde.org/GSoC/2013/Ideas#Project:_Improving_and_modularizing_tag_guessing>?
I know currently libofa is used to compute audio fingerprints, ffmpeg is
for audio/video streaming, Phonon is incapable to computing
fingerprints/AcoustIDs, and chormaprint should be used to create AcoustIDs
that will be sent to MusicBrainz for identification of the audio file.
Thank-you,
Vedant.
---------- Forwarded message ----------
From: vedant agarwala <vedant.kota at gmail.com>
Date: Wed, Apr 24, 2013 at 4:32 PM
Subject: Re: GSoC draft application
To: amarok-devel <amarok-devel at kde.org>
*
Hello,
I want to do the project Improving and modularizing tag
guessing<http://community.kde.org/GSoC/2013/Ideas#Project:_Improving_and_modularizing_tag_guessing>for
this year's Google Summer of Code. I request the amarok community to
review my project proposal before I submit it.
I'm a first timer for GSoC so any suggestions/comments will be very helpful.
Thank-you in advance,
Vedant.
application------>
Name: Vedant Agarwala
Email Address: vedant.kota at gmail.com
Freenode IRC Nick: vedant
IM Service and Username: xmpp-google: vedant.kota at gmail.com
Location (City, Country and/or Time Zone): Kolkata, India GMT+5.30
Proposal Title: Improving and modularizing tag guessing
Motivation for Proposal / Goal: Currently, Amarok “guesses” tags of music
files through the MusicBrainz web service using either existing tags or
MusicIP audio fingerprints. This method, however, is somewhat outdated.
MusicBrainz is phasing out MusicIP in favour of AcousID and other methods
of guessing tags have emerged. The aim of this project is to create an
abstract base class for tag guessing that can be suitably inherited by
other classes that aim to guess tags.
Implementation Details:
-
Creating a generic framework for tag getters: The project requires a
documented directory (say "TagGetters") containing abstract classes (like
"Controller" and "Provider", similar to the existing “StatSyncing”).
Sub-directories will be created under this directory that will implement
the abstract classes. The existing musicbrainz directory will be ported
into such a sub-directory and it will use the newly created framework.
Later on, more sub-directories can be created that follow this
implementation and aim to guess tags.
-
Rewriting MusicBrainz tag getter: Existing MusicBrainz code will be
re-written according to the framework above. Currently, libofa is used to
create the music fingerprint that is sent to MusicBrainz. Now, chromaprint
(library to compute AcustIDs) will be used. AcustIDs will be send to
MusicBrainz (for better identification of the audio file).
-
Creating Last.fm tag getter: Create the Last.fm tag getter. First the
tag based service will added and then, depending on time, the fingerprint
based service might be added.
-
A better GUI: The existing button- Get tags from MusicBrainz- will be
replaced by "Get tags from the following services: " followed by QGroupBox
containing names of the features. Getting tags from the individual services
will run in parallel and results will be displayed as soon as they are
fetched- probably by a TagGetterController. This list will persist in
memory so that if the user closes the dialog and then reopens it, tags
won’t have to fetched again (until Amarok restart). The user can choose the
best tags from the generated list.
-
A GUI for getting tags of multiple songs simultaneously: Its a feature
by which tags for multiple tracks (if not the entire local collection) can
be changed. Getting tags requires too many user clicks as of now,
especially for multiple tracks. To solve this, a "tag getter wizard" will
select the best tags for every track (perhaps by comparing results of
different services and generating a score for each). Best ones are written
to files without user approval but in a reversible way. Earlier tags will
be saved to database and can be reversed/changed anytime in both ways- 1)
for individual tracks 2) through a list showing the changed tags.
Tentative Timeline:
Bonding Period ( May end to mid June): Decide on finer points. Like,
details of the generic framework of tag getters, how the end-user GUI will
look like, whether or not to use a “wizard” to guess tags for many songs,
etc. Talk to my mentor and refine the implementation based on his/her
suggestions.
June-
<--- GSoC commences--->
week 3: Make the directories and start writing the abstract classes.
week 4: Finish writing the abstract classes of the generic framework.
July-
week 1: Polish, make cmakelists for, write make tests and compile the
written abstract classes.
week 2: Re-write the MusicBrainz tag getter according to the framework
week 3: Add the features (like using AcoustID) to this MusicBrainz tag
getter
week 4: Compile and run the new MusicBrainz (displaying results in the old
UI itself)
<--- Mid term --->
August-
week 1: Write the new GUI code and “TagGetterController”. Run MusicBrainz
tag getter in this fashion
week 2: Write the Last.fm tag getter (as many features as possible)
week 3: Finish writing and test the Last.fm tag getter
week 4: Test the Last.fm and MusicBrainz tag getter together in the new GUI
September-
week 1: Make the tag getter wizard GUI and code to backup tags to database
week 2: Test the new wizard. Write tests to make sure that new tag getters
follow the framework
<--- suggested “pens down” --->
week 3: Improve documentation. Fix bugs that have been discovered over the
weeks
<--- firm “pens down” --->
week 4: Improve the efficiency of the wizard by testing and tweaking.
October-
week 1: Do some code cleaning and fix bugs so that the new framework and
features can be pushed into the master branch.
Other Obligations: I have no other obligations. I can easily spent about 50
hours a week (7 to 8 hrs a day in slots of 2 to 3 hrs, one each in the
afternoon, evening and at night) coding; since summer vacations will be
going on till mid July. Even after college starts, very few classes are
held in the beginning of the semester and the college teachers make
exceptions for GSoC students. So, I can continue to code 50 hours a week
(with a similar schedule) even up till September.
About Me: I am currently in my second undergraduate year in National
Institute of Technology, Durgapur, India, studying Computer Science and
Engineering. I have experience coding experience with C/C++, Java
(including Android and making GUI using Java swing) and web services. I
have submitted 3 patches (JJ bug-fixes one each for Rekonq and Amarok as
well as a improved formatting patch for Amarok) and 2 more are under review
(both JJ bug-fixes for Amarok).
I love coding for open source. I’m sure working with a mentor who is
virtually present won’t be a problem. I have interacted (mainly with Matej
a.k.a. Strohel on IRC) over IRC, the amarok mailing list, reviewboard and
also the KDE bug tracking system. During the work period code can easily be
shared via github. If it is possible, meeting a mentor face to face will
obviously be much more helpful. I have worked with my college seniors in
this fashion who have introduced me to Linux and Open-Source. Countless
times I have been to their rooms for advice and to solve my problems.
After GSoC I plan to become an active developer for Amarok and also for
other projects of KDE.
Junior job link: Bug 140198 - JJ: feature request: option to selectively
disable submitting certain tracks/albums from collection to
last.fm<https://git.reviewboard.kde.org/r/109283/>
*
On Wed, Apr 24, 2013 at 3:55 PM, Matěj Laitl <matej at laitl.cz> wrote:
> On 24. 4. 2013 vedant agarwala wrote:
> > Hello,
> > I want to do the project Improving and modularizing tag guessing for this
> > year's Google Summer of Code. I request the amarok community to review my
> > project proposal before I submit it: Link to Application I'm a first
> timer
> > for GSoC so any suggestions/comments will be very helpful.
>
> Hi, please include the proposal inline as plain text in the mail so that we
> can easily comment with context.
>
> Matěj
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130425/0e938b4c/attachment-0001.html>
More information about the Amarok-devel
mailing list