Draft SoK Proposal

[Nitul Datt]

On 30 Oct 2014 20:30, "vedant agarwala" <vedant.kota at gmail.com> wrote:
>
>
>
> 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.
>

Ok. I'll keep that in mind.

>>
>>
>> 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.
>>

Ok. I thought it was mandatory to do so.

>>
>>
>> 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!
>

Thanks for your help!

> -Vedant.
>
>

--
Regards,
Nitul Datt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20141031/c9cf8285/attachment.html>