GSoC proposal review

Matěj Laitl matej at laitl.cz
Tue Apr 30 12:14:14 UTC 2013


On 28. 4. 2013 Abhinandan Ramprasath wrote:
> I hope I'm not too late with this.

Not strictly late, but we cannot reply within hours, so you may have little 
time to process the feedback.

> Also, I don't have many bug fixes to show for, I can see my chances of
> getting in are greatly hindered by it. would any bug fix in the final few days
> make a change?

Every bugfix counts - we need to know that students are capable of patching, 
building, reading code, respecting style etc.

> Implementing Unified CUE sheet and chapter support in Amarok
> 
> Implementation Details:

You lack 2 very important parts:
 * Motivation (what the current problem is? why it needs to be fixed?)
 * Project Goal (what are the deliverables you want to provide? By what 
criteria we should judge whether your project is finished?)

> The project involves making changes in both TagLib and amarok repositories.
> I would like to divide the project into 3 parts.
> 
> The first one being implementing the QtChapter support in MP4/M4A/M4B
> files.

Are you sure that this is the format used in audiobooks? The link refers to 
movies mostly. Also please clarify that Qt is quicktime here (better not 
shorten it), not Qt library.

> As per the apple docs(1) the Qt chapter support can be achieved by
> reading the “trak” atom which contains the “chap” data. This trak atom
> contains the text track which contains the chapter information. The
> indicated text track should contain a “stbl” atom ( basically a table )
> which would contain offsets to the location in the file that contain
> chapter title in the file. Reading data at these offsets give information
> about chapter titles. The time at which each each chapter marker occurs to
> can be easily calculated using the “bitrate” of the audiofile. These would
> be the changes that I would make in TagLib to support QtChapters. The
> changes in amarok include, displaying the chapter markers to the user in
> the form of bookmarks or Multi-Tracks.

This needs to be sorted out, I think we would prefer MultiTracks.

> I plan on reading the chapter
> information in amarok the same way I implemented it in the bug fix (2). I
> would like to also store the chapter information in the database as well.

Yes, that will be needed.

> The second part of the project would be to implement Unified CUE sheet
> support.

Well, the "unified" was for chapter + cue and doesn't have sense alone.

> The CUE sheet implementation is quite straightforward. CUE sheet
> contains information related to the album and the main filename and the
> time offsets at which each track occurs . The challenging part would be to
> implement this support in the database. I propose to make this change in
> the KUrl. Parts of the Url would have data about the BaseFile, Time-Offset
> and Duration of the track (after a “?” or “#” at the end, if not possible a
> new protocol?). This must be done without affecting the rest of the working
> of the app. Then these URL’s would be interpreted in the UmsCollection or
> SqlCollection classes as separate Track files. This would also enable
> storing the details of each song in the database, hence there is no need to
> access the cue file everytime.

Yeah, this makes sense. You'll also need to handle metadata changes - I guess 
changing the title would be very different from changing the album.

Are you aware that Amarok already has limited support for cue files?

> The third and last part of the project would be to implement support for
> the NeroChapter type in MP4. Since, this is not so popular, I would like to
> keep this my last part of the project. This involves more changes in TagLib
> than amarok. The chapter track information is found under the “udta” atom.
> This part of the project would be to automatically detect the type of
> chapter present in the given file and decode the chapter data and provide
> it neatly.

Makes sense, also it makes sense to keep this low-priority.

> Tentative Timeline:
> 
> June
> 
> < GSOC begins >
> 
> week 4: Community Bonding Period - Ask for improvement suggestions and get
> to know the amarok community.
> 
> July-
> 
> week 1: Create Abstract Classes in TagLib for MP4 chapter support. Start
> implementing QtChapter Support.
> 
> week 2: Finish implementing QtChapter Support in TagLib.
> 
> week 3: Design UI in amarok to display the chapter markers.

I don't there's a need for new UI, perhaps just some small tweaks. You also 
don't mention it in the implementation details.

> week 4: Modify the database and store the chapter data in it.
> 
> < Mid-term  - Complete QtChapter support in amarok>
> 
> August-
> 
> week 1: Create abstract classes for cue file support in amarok.

Well, some of them are already there, this sounds like you're unaware of it.

> week 2: Detect and decode cue file and store the information in the classes.

Should be already done.

> week 3: Implement changes in Kurl.
> 
> week 4: Make modifications in SqlCollection and other methods and classes
> that use url(TrackPtr).
> 
> September-
> 
> week 1: Make modifications in UmsCollection to support cue sheets as well.
> 
> week 2: Finish cue sheet support in amarok.
> 
> week 3: Implement NeroChapter support in TagLib.
> 
> < pens down >
> 
> week 4: Testing and resolving any bugs. Documentation.

If the documentation stands for documenting public classes and methods, then 
don't do it in batch in the last week. Do it right when you introduce/change a 
class/method!

> Do you have other obligations from late May to early August (school, work,
> vacation, etc.)?
> 
> No obligations. I am willing to work 50 hours a week,  7-8 hours everyday,
> maybe more during the weekends.

Have some rest, too! :-) Relaxed developers produce better code. ;-)

> College starts early august but should not
> be a problem. I will still be able to put in 50 hours a week by working a
> little extra in the weekends.

Hmm, this is a bit early. Are you going to have regular courses from early 
August?

> About Me:
> 
> I am a Student of SSN College of Engineering. I prefer coding in
> C/C++/Python. I was introduced to amarok when my friend suggested it after
> looking at my android app Lyricize (3). Since then I have fallen in love
> with it. I would love to make any contribution that makes music more
> enjoyable. I am also an enthusiastic web and android developer. I am a very
> big FLOSS fan. I have written scripts that predict and scrape the indian
> stock market data and avails it to developers as an API as well as
> contributions to Haiku OS.

Have you worked with any VCS systems, e.g. git?

Some experience with Qt (the library)/kdelibs?

> Am I comfortable working independently under a mentor or supervisor?
> 
> Yes. I have been an intern for the ULaw Software Foundation based in canada
> and timezones isn’t really a problem at all.

"aren't"

> After GSoC:
> 
> After GSoC I plan on continuing to fix bugs and code more features for
> amarok and taglib. I intend to learn about more file formats and improving
> support in those areas.

Otherwise this doesn't look bad, but as mentioned above, 2 mandatory sections 
and more research of existing functionality (and code) is needed so that the 
proposal doesn't look uninformed.

Cheers,
		Matěj 


More information about the Amarok-devel mailing list