<p dir="ltr"><br>
On 30 Oct 2014 20:30, "vedant agarwala" <<a href="mailto:vedant.kota@gmail.com">vedant.kota@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Thu, Oct 30, 2014 at 6:48 PM, Nitul Datt <<a href="mailto:nitul1991@gmail.com">nitul1991@gmail.com</a>> wrote:<br>
>><br>
>> Hey!<br>
>><br>
>> On 10/30/14, vedant agarwala <<a href="mailto:vedant.kota@gmail.com">vedant.kota@gmail.com</a>> wrote:<br>
>> > On Thu, Oct 30, 2014 at 3:41 AM, Nitul Datt <<a href="mailto:nitul1991@gmail.com">nitul1991@gmail.com</a>> wrote:<br>
>> ><br>
>> >> Hey!<br>
>> >><br>
>> >> On 10/29/14, vedant agarwala <<a href="mailto:vedant.kota@gmail.com">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>
>> 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>
><br>
><br>
> My initial thought was the same. Okay lets do this.<br>
>  <br>
>><br>
>><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>
>> Yes. Are you proposing something else as well?<br>
><br>
><br>
> 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?<br>
><br>
> 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.<br>
>  </p>
<p dir="ltr">Ok. I'll keep that in mind. </p>
<p dir="ltr">>><br>
>><br>
>> I have made the necessary changes to the proposal as per your suggestions.<br>
>><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>
>> Project Goals<br>
>> Provide support for cue sheeted music in collections, solving a number<br>
>> 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>
>> Individual tracks with all necessary metadata, must be created as per<br>
>> 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>
>> 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>
>> 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>
>> A lot of existing code dealing with cue sheets may be reused, namely<br>
>> 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>
><br>
><br>
> Good idea.<br>
>  <br>
>><br>
>> polish this code. It will also require testing to see whether the<br>
>> existing implementation is correct.<br>
><br>
><br>
> 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. <br>
>></p>
<p dir="ltr">Ok. I thought it was mandatory to do so. </p>
<p dir="ltr">>><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. 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>
>> 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. This will help in<br>
>> determining whether improvements can be made to the basic cue sheet<br>
>> related methods.<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 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>
>> thus be confined to testing my code.<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 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>
>> [1] <a href="https://bugs.kde.org/show_bug.cgi?id=231187">https://bugs.kde.org/show_bug.cgi?id=231187</a><br>
>> [2] <a href="https://bugs.kde.org/show_bug.cgi?id=233282">https://bugs.kde.org/show_bug.cgi?id=233282</a><br>
>> [3] <a href="https://bugs.kde.org/show_bug.cgi?id=233283">https://bugs.kde.org/show_bug.cgi?id=233283</a><br>
>><br>
>> --<br>
>> Regards,<br>
>> Nitul Datt<br>
>><br>
>> ><br>
>> > Regards,<br>
>> > Vedant.<br>
>> ><br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
> Good luck!<br>
></p>
<p dir="ltr">Thanks for your help! </p>
<p dir="ltr">> -Vedant.<br>
><br>
></p>
<p dir="ltr">--<br>
Regards, <br>
Nitul Datt<br>
</p>