Fwd: Draft SoK Proposal

Thu Oct 30 16:04:01 UTC 2014

Sorry forgot to cc amarok-devel

---------- Forwarded message ----------
From: vedant agarwala <vedant.kota at gmail.com>
Date: Thu, Oct 30, 2014 at 8:30 PM
Subject: Re: Draft SoK Proposal
To: Nitul Datt <nitul1991 at gmail.com>

On Thu, Oct 30, 2014 at 6:48 PM, Nitul Datt <nitul1991 at gmail.com> wrote:

> Hey!
>
> On 10/30/14, vedant agarwala <vedant.kota at gmail.com> wrote:
> > On Thu, Oct 30, 2014 at 3:41 AM, Nitul Datt <nitul1991 at gmail.com> wrote:
> >
> >> Hey!
> >>
> >> On 10/29/14, vedant agarwala <vedant.kota at gmail.com> wrote:
> >> > Then do that.
> >> >
> >> > When you post a draft proposal on the mailing list post the entire
> text
> >> as
> >> > plain text rather than a link to a doc. Easier to read and comment in
> >> line.
> >>
> >> This is a draft of my proposal to implement cue sheet support in
> >> Amarok. Suggestions are welcome, especially in the implementation and
> >> timeline sections.
> >>
> >> Introduction
> >> At present Amarok does not provide support for cue sheeted music in
> >> the collection. If implemented correctly, this feature would allow for
> >> the independent playback of individual songs stored in a single audio
> >> file.
> >>
> > Nice!
> >
> >>
> >> Project Goals
> >> Provide support for cue sheeted music in collections, solving a number
> >> of bugs in the process.
> >>
> > List the bugs (maybe also with reference links)
> >
> >>
> >> Implementation
> >> The amarokcollectionscanner utility must first search whether a given
> >> file has an associated cue sheet with the same name but .cue
> >>
> > grammar: s/but/with
> >
> >> extension, failing which all cue files in the same directory must be
> >> checked for a matching FILE attribute.
> >> Individual tracks with all necessary metadata, must be created as per
> >> the directions in the cue sheeted file.
> >>
> >
> > You mean a TrackPtr object? Try and put some source code from Amarok code
> > base. "created" how?
> >
> >
> >> To support the playback of a single track in such a file, I propose to
> >> use BoundedPlaybackCapability in the EngineController as each track in
> >> a cue sheeted file has a specific  start and end time within the file.
> >> A lot of existing code dealing with cue sheets may be reused, namely
> >> the CueFileSupport class.
> >>
> >
> > You really need to expand on implementation details. For inspiration
> have a
> > look at some accepted GSoC proposals. (But do not spend much time on it)
> >
> >>
> >> Timeline
> >> Nov 5th - Nov 15th
> >> I plan to go through the relevant parts of the codebase ie the
> >> collectionscanner, EngineController and also the existing cuesheet
> >> related classes.
> >> Nov 16th - Nov 22nd
> >> I plan to go through the implementation of cue sheet support in other
> >> qt based music players like qmmp and clementine.
> >>
> >
> > Do not plan to "go through" code for such a long time. You will end up
> > going through a lot of code. Implement alongside "going through".
> >
> >
> >> Nov 23rd - Dec 1st
> >> I propose to make the necessary changes in the collectionscanner
> >> during this period.
> >> Dec 2nd - Dec 7th
> >> This period is meant as a buffer for any spillovers from the previous
> >> weeks.
> >> Dec 8th - Dec 15th
> >> I plan to implement the creation of tracks from the single cue sheet
> >> file.
> >> Dec 16th - Dec 26th
> >> During this period I shall be busy with my semester exams and will
> >> thus be confined to reviewing and testing my code.
> >>
> > you dont review your own code
> >
> >> Dec 27th - Jan 7th
> >> During this period, I plan to implement the necessary changes to
> >> ensure the correct playback of individual tracks in the file.
> >> Jan 8th - Jan 16th
> >> I plan to test my changes and make sure the entire implementation is
> >> correct.
> >> Jan 17th - Jan 31st
> >> I plan to use the last 2 weeks to make any modifications as suggested
> >> by the community and review and document my code.
> >>
> >
> > good timeline.
> >
> >>
> >>
> >> I'm awaiting your response as I have to submit this by Oct 31, 12:00 am
> >> UTC.
> >>
> >> >
> >> >
> >> > Regards,
> >> > Vedant.
> >> >
> >>
> >> --
> >> Regards,
> >> Nitul Datt
> >>
> >
> > Some more questions you (and me as well) need to answer:
> >
> > * How will the tracks be grouped in the Amarok playlist and collections.
>
> From what I have understood, the individual songs in the cue sheeeted
> file should be treated as ordinary tracks. Alll such tracks from a
> single file will have the same url but different names and start and
> stop times which will be incorporated from the cue sheet.
>

My initial thought was the same. Okay lets do this.

>
> > * seems like you are implementing only for SQL collection (as
> > collectionscanner runs only for it). -correct me if I am wrong. Is this
> > okay?
>
> Yes. Are you proposing something else as well?
>

It should for all collections that can have cue sheets. Like if I insert a
pen drive/MTP device with cue sheets. Are we solving for such collections
as well?

But as you have mentioned later, we are fixing regressions so lets not
worry about supporting other collections for now. That can be a "secondary
goal"- to be pursued if time permits.

>
> I have made the necessary changes to the proposal as per your suggestions.
>
>
> Introduction
> At present Amarok does not provide support for cue sheeted music in
> the collection. If implemented correctly, this feature would allow for
> the independent playback of individual songs stored in a single audio
> file.
>
> Project Goals
> Provide support for cue sheeted music in collections, solving a number
> of bugs in the process. These bugs ([1], [2], [3]) have been marked as
> regressions.
>
> Implementation
> The amarokcollectionscanner utility must first determine whether a
> given file has an associated cue sheet with the same name but with a
> .cue extension, failing which all cue files in the same directory must
> be checked for a matching FILE attribute. The appropriate additions
> must be made to the CollectionScanner::Scanner::doJob() slot. For this
> I propose to make use of existing code provided in the CueFileSupport
> class, which will return the path of the cue sheet, if found, taking
> the url of the audio file as argument.
> Individual tracks with all necessary metadata, must be created as per
> the directions in the cue sheeted file. I propose to create a list of
> TrackPtr objects pointing to TimeCodeTracks. I have found an
> implementation of this in the CueFileSupport class as well. The
> metadata will be used to play the individual songs from the same file.
> To support the playback of a single track in such a file, I propose to
> use BoundedPlaybackCapability in the EngineController as each track in
> a cue sheeted file has a specific start and end time within the file.
> EngineController already implements something similar for single songs
> in a long podcast by using a capability object to indicate a bounded
> playback track.
> A lot of existing code dealing with cue sheets may be reused, namely
> the CueFileSupport class. This class has implemented a number of
> methods to deal with some of the above issues. I propose to reuse and
>

Good idea.

> polish this code. It will also require testing to see whether the
> existing implementation is correct.
>

By testing we generally a dedicated test suite. Amarok uses Google-mock and
google-test. Did you mean writing such tests? Seems beyond the scope of
this project.

>
>
> Timeline
> Nov 5th - Nov 15th
> I plan to go through the relevant parts of the codebase ie the
> collectionscanner, EngineController and also the existing cuesheet
> related classes. During this time I shall also implement changes to
> the collectionscanner and see if the existing cue sheet related code
> needs modification.
> Nov 16th - Nov 22nd
> I plan to go through the implementation of cue sheet support in other
> qt based music players like qmmp and clementine. This will help in
> determining whether improvements can be made to the basic cue sheet
> related methods.
> Nov 23rd - Dec 1st
> I propose to make the necessary changes in the collectionscanner
> during this period.
> Dec 2nd - Dec 7th
> This period is meant as a buffer for any spillovers from the previous
> weeks.
> Dec 8th - Dec 15th
> I plan to implement the creation of tracks from the single cue sheet file.
> Dec 16th - Dec 26th
> During this period I shall be busy with my semester exams and will
> thus be confined to testing my code.
> Dec 27th - Jan 7th
> During this period, I plan to implement the necessary changes to
> ensure the correct playback of individual tracks in the file.
> Jan 8th - Jan 16th
> I plan to test my changes and make sure the entire implementation is
> correct.
> Jan 17th - Jan 31st
> I plan to use the last 2 weeks to make any modifications as suggested
> by the community and review and document my code.
>
>
> [1] https://bugs.kde.org/show_bug.cgi?id=231187
> [2] https://bugs.kde.org/show_bug.cgi?id=233282
> [3] https://bugs.kde.org/show_bug.cgi?id=233283
>
> --
> Regards,
> Nitul Datt
>
> >
> > Regards,
> > Vedant.
> >
>

So it seems that we have what we need and you can publish this proposal.
You have a lot of time to implement this. Let's make it complete in every
way.

Good luck!

-Vedant.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141030/8f85dc45/attachment-0001.html>