Draft SoK Proposal

[Nitul Datt]

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.

> * 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?

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
polish this code. It will also require testing to see whether the
existing implementation is correct.


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