<div dir="ltr">Sorry forgot to cc amarok-devel<div><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">vedant agarwala</b> <span dir="ltr"><<a href="mailto:vedant.kota@gmail.com">vedant.kota@gmail.com</a>></span><br>Date: Thu, Oct 30, 2014 at 8:30 PM<br>Subject: Re: Draft SoK Proposal<br>To: Nitul Datt <<a href="mailto:nitul1991@gmail.com">nitul1991@gmail.com</a>><br><br><br><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Oct 30, 2014 at 6:48 PM, Nitul Datt <span dir="ltr"><<a href="mailto:nitul1991@gmail.com" target="_blank">nitul1991@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey!<br>
<div><div><br>
On 10/30/14, vedant agarwala <<a href="mailto:vedant.kota@gmail.com" target="_blank">vedant.kota@gmail.com</a>> wrote:<br>
> On Thu, Oct 30, 2014 at 3:41 AM, Nitul Datt <<a href="mailto:nitul1991@gmail.com" target="_blank">nitul1991@gmail.com</a>> wrote:<br>
><br>
>> Hey!<br>
>><br>
>> On 10/29/14, vedant agarwala <<a href="mailto:vedant.kota@gmail.com" target="_blank">vedant.kota@gmail.com</a>> wrote:<br>
>> > Then do that.<br>
>> ><br>
>> > When you post a draft proposal on the mailing list post the entire text<br>
>> as<br>
>> > plain text rather than a link to a doc. Easier to read and comment in<br>
>> line.<br>
>><br>
>> This is a draft of my proposal to implement cue sheet support in<br>
>> Amarok. Suggestions are welcome, especially in the implementation and<br>
>> timeline sections.<br>
>><br>
>> Introduction<br>
>> At present Amarok does not provide support for cue sheeted music in<br>
>> the collection. If implemented correctly, this feature would allow for<br>
>> the independent playback of individual songs stored in a single audio<br>
>> file.<br>
>><br>
> Nice!<br>
><br>
>><br>
>> Project Goals<br>
>> Provide support for cue sheeted music in collections, solving a number<br>
>> of bugs in the process.<br>
>><br>
> List the bugs (maybe also with reference links)<br>
><br>
>><br>
>> Implementation<br>
>> The amarokcollectionscanner utility must first search whether a given<br>
>> file has an associated cue sheet with the same name but .cue<br>
>><br>
> grammar: s/but/with<br>
><br>
>> extension, failing which all cue files in the same directory must be<br>
>> checked for a matching FILE attribute.<br>
>> Individual tracks with all necessary metadata, must be created as per<br>
>> the directions in the cue sheeted file.<br>
>><br>
><br>
> You mean a TrackPtr object? Try and put some source code from Amarok code<br>
> base. "created" how?<br>
><br>
><br>
>> To support the playback of a single track in such a file, I propose to<br>
>> use BoundedPlaybackCapability in the EngineController as each track in<br>
>> a cue sheeted file has a specific  start and end time within the file.<br>
>> A lot of existing code dealing with cue sheets may be reused, namely<br>
>> the CueFileSupport class.<br>
>><br>
><br>
> You really need to expand on implementation details. For inspiration have a<br>
> look at some accepted GSoC proposals. (But do not spend much time on it)<br>
><br>
>><br>
>> Timeline<br>
>> Nov 5th - Nov 15th<br>
>> I plan to go through the relevant parts of the codebase ie the<br>
>> collectionscanner, EngineController and also the existing cuesheet<br>
>> related classes.<br>
>> Nov 16th - Nov 22nd<br>
>> I plan to go through the implementation of cue sheet support in other<br>
>> qt based music players like qmmp and clementine.<br>
>><br>
><br>
> Do not plan to "go through" code for such a long time. You will end up<br>
> going through a lot of code. Implement alongside "going through".<br>
><br>
><br>
>> Nov 23rd - Dec 1st<br>
>> I propose to make the necessary changes in the collectionscanner<br>
>> during this period.<br>
>> Dec 2nd - Dec 7th<br>
>> This period is meant as a buffer for any spillovers from the previous<br>
>> weeks.<br>
>> Dec 8th - Dec 15th<br>
>> I plan to implement the creation of tracks from the single cue sheet<br>
>> file.<br>
>> Dec 16th - Dec 26th<br>
>> During this period I shall be busy with my semester exams and will<br>
>> thus be confined to reviewing and testing my code.<br>
>><br>
> you dont review your own code<br>
><br>
>> Dec 27th - Jan 7th<br>
>> During this period, I plan to implement the necessary changes to<br>
>> ensure the correct playback of individual tracks in the file.<br>
>> Jan 8th - Jan 16th<br>
>> I plan to test my changes and make sure the entire implementation is<br>
>> correct.<br>
>> Jan 17th - Jan 31st<br>
>> I plan to use the last 2 weeks to make any modifications as suggested<br>
>> by the community and review and document my code.<br>
>><br>
><br>
> good timeline.<br>
><br>
>><br>
>><br>
>> I'm awaiting your response as I have to submit this by Oct 31, 12:00 am<br>
>> UTC.<br>
>><br>
>> ><br>
>> ><br>
>> > Regards,<br>
>> > Vedant.<br>
>> ><br>
>><br>
>> --<br>
>> Regards,<br>
>> Nitul Datt<br>
>><br>
><br>
> Some more questions you (and me as well) need to answer:<br>
><br>
> * How will the tracks be grouped in the Amarok playlist and collections.<br>
<br>
</div></div>From what I have understood, the individual songs in the cue sheeeted<br>
file should be treated as ordinary tracks. Alll such tracks from a<br>
single file will have the same url but different names and start and<br>
stop times which will be incorporated from the cue sheet.<br></blockquote><div><br></div></div></div><div>My initial thought was the same. Okay lets do this.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> * seems like you are implementing only for SQL collection (as<br>
> collectionscanner runs only for it). -correct me if I am wrong. Is this<br>
> okay?<br>
<br>
</span>Yes. Are you proposing something else as well?<br></blockquote><div><br></div></span><div>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?</div><div><br></div><div>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.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have made the necessary changes to the proposal as per your suggestions.<br>
<span><br>
<br>
Introduction<br>
At present Amarok does not provide support for cue sheeted music in<br>
the collection. If implemented correctly, this feature would allow for<br>
the independent playback of individual songs stored in a single audio<br>
file.<br>
<br>
</span><span>Project Goals<br>
Provide support for cue sheeted music in collections, solving a number<br>
</span>of bugs in the process. These bugs ([1], [2], [3]) have been marked as<br>
regressions.<br>
<br>
Implementation<br>
The amarokcollectionscanner utility must first determine whether a<br>
given file has an associated cue sheet with the same name but with a<br>
.cue extension, failing which all cue files in the same directory must<br>
be checked for a matching FILE attribute. The appropriate additions<br>
must be made to the CollectionScanner::Scanner::doJob() slot. For this<br>
I propose to make use of existing code provided in the CueFileSupport<br>
class, which will return the path of the cue sheet, if found, taking<br>
the url of the audio file as argument.<br>
<span>Individual tracks with all necessary metadata, must be created as per<br>
</span>the directions in the cue sheeted file. I propose to create a list of<br>
TrackPtr objects pointing to TimeCodeTracks. I have found an<br>
implementation of this in the CueFileSupport class as well. The<br>
metadata will be used to play the individual songs from the same file.<br>
<span>To support the playback of a single track in such a file, I propose to<br>
use BoundedPlaybackCapability in the EngineController as each track in<br>
a cue sheeted file has a specific start and end time within the file.<br>
</span>EngineController already implements something similar for single songs<br>
in a long podcast by using a capability object to indicate a bounded<br>
playback track.<br>
<span>A lot of existing code dealing with cue sheets may be reused, namely<br>
</span>the CueFileSupport class. This class has implemented a number of<br>
methods to deal with some of the above issues. I propose to reuse and<br></blockquote><div><br></div></div></div><div>Good idea.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
polish this code. It will also require testing to see whether the<br>
existing implementation is correct.<br></blockquote><div><br></div></span><div>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. </div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
<br>
Timeline<br>
Nov 5th - Nov 15th<br>
I plan to go through the relevant parts of the codebase ie the<br>
collectionscanner, EngineController and also the existing cuesheet<br>
</span>related classes. During this time I shall also implement changes to<br>
the collectionscanner and see if the existing cue sheet related code<br>
needs modification.<br>
<span>Nov 16th - Nov 22nd<br>
I plan to go through the implementation of cue sheet support in other<br>
</span>qt based music players like qmmp and clementine. This will help in<br>
determining whether improvements can be made to the basic cue sheet<br>
related methods.<br>
<span>Nov 23rd - Dec 1st<br>
I propose to make the necessary changes in the collectionscanner<br>
during this period.<br>
Dec 2nd - Dec 7th<br>
This period is meant as a buffer for any spillovers from the previous weeks.<br>
Dec 8th - Dec 15th<br>
I plan to implement the creation of tracks from the single cue sheet file.<br>
Dec 16th - Dec 26th<br>
During this period I shall be busy with my semester exams and will<br>
</span>thus be confined to testing my code.<br>
<span>Dec 27th - Jan 7th<br>
During this period, I plan to implement the necessary changes to<br>
ensure the correct playback of individual tracks in the file.<br>
Jan 8th - Jan 16th<br>
I plan to test my changes and make sure the entire implementation is correct.<br>
Jan 17th - Jan 31st<br>
I plan to use the last 2 weeks to make any modifications as suggested<br>
by the community and review and document my code.<br>
<br>
<br>
</span>[1] <a href="https://bugs.kde.org/show_bug.cgi?id=231187" target="_blank">https://bugs.kde.org/show_bug.cgi?id=231187</a><br>
[2] <a href="https://bugs.kde.org/show_bug.cgi?id=233282" target="_blank">https://bugs.kde.org/show_bug.cgi?id=233282</a><br>
[3] <a href="https://bugs.kde.org/show_bug.cgi?id=233283" target="_blank">https://bugs.kde.org/show_bug.cgi?id=233283</a><br>
<span><br>
--<br>
Regards,<br>
Nitul Datt<br>
<br>
><br>
> Regards,<br>
</span>> Vedant.<br>
><br></blockquote><div><br></div><div><br></div></div></div><div>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.</div><div><br></div><div><br></div><div>Good luck!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Vedant.</div><div><br></div></font></span></div><br></div></div>
</div><br></div></div>