On 30 Oct 2014 20:30, "vedant agarwala" <vedant.k...@gmail.com> wrote: > > > > On Thu, Oct 30, 2014 at 6:48 PM, Nitul Datt <nitul1...@gmail.com> wrote: >> >> Hey! >> >> On 10/30/14, vedant agarwala <vedant.k...@gmail.com> wrote: >> > On Thu, Oct 30, 2014 at 3:41 AM, Nitul Datt <nitul1...@gmail.com> wrote: >> > >> >> Hey! >> >> >> >> On 10/29/14, vedant agarwala <vedant.k...@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
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
