SoK Project Query

[Nitul Datt]

On 11/24/14, vedant agarwala <vedant.kota at gmail.com> wrote:
> On Mon, Nov 24, 2014 at 5:56 PM, Nitul Datt <nitul1991 at gmail.com> wrote:
>
>> On 11/24/14, vedant agarwala <vedant.kota at gmail.com> wrote:
>> > Hello Nitul,
>> >
>> > I am not thoroughly familiar with the code but here is my suggestion:
>> >
>> > The CollectionScanner should find files and represent them. So if it
>> finds
>> > a track it represents it as such. You should have a one Track object
>> > representing a track and a new CueSheet (or similar) class object to
>> > represent a cue sheet.
>> >
>>
>> Won't that make two entries for the same file, ie one for the music
>> file and one for the corresponding cue sheet, since the music file
>> will be scanned as such and the cue sheet as well? The solution to
>> this seems to be that we only store the cue sheet file and not the
>> corresponding track. This seems like a better approach than what I was
>> trying earlier. What do you think?
>>
>
> I thought that a cue sheet is a separate file. Anyway, you are right: only
> one object should represent one file. So we should have just a CueSheet
> file.
>
>
>>
>> > But when these files are shown in the Database collection/playlist etc.
>> in
>> > amarok they should be shown as completely different (according to the
>> music
>> > file and cue sheet) files (i.e. different TrackPtr 's should be created
>> for
>> > each).
>> >
>>
>> Yes, that may be achieved using timecode tracks. I haven't been able
>> to find how timecode tracks are represented in the database though.
>>
>> > The thing that I haven't figured out is that how will amarok "dissect"
>> > the CollectionScanner::Track
>> > if it is a cue-sheeted track. Can you place some link in the
>> > CollectionScanner::Track
>> > to the corresponding CollectionScanner::CueSheet without modifying it?
>> > Or
>> > when the CollectionScanner::CueSheet is accessed by Amarok, it should
>> > dissect the CollectionScanner::Track into many TrackPtr 's.
>> >
>>
>> I'll look into it.
>>
>> > It really depends on how the information fed by the collection scanner
>> > to
>> > amarok is parsed by amarok. Look into and figure it out.
>> >
>> > Ask me again if needed.
>> >
>> > And, always 'cc' amarok-devel. Maybe someone would help you. Even if
>> > they
>> > don't, they will be glad to know how the amarok community is bonding
>> > and
>> > growing.
>> >
>> > Regards,
>> > Vedant.
>> >
>> > On Sun, Nov 23, 2014 at 10:41 PM, Nitul Datt <nitul1991 at gmail.com>
>> wrote:
>> >
>> >> Hey!
>> >>
>> >> I've run into a bit of a roadblock and require your guidance. How
>> >> should I represent the individual tracks in a cue sheeted file? At
>> >> present, the collection scanner does not include start and end times
>> >> for regular tracks. The existing cue sheet related code creates
>> >> timecode tracks for the individual songs in a cue sheeted file. That
>> >> being said, should I thus create a new CollectionScanner::TimcodeTrack
>> >> class or make changes to the existing CollectionScanner::Track class?
>> >>
>> >> --
>> >> Regards,
>> >> Nitul Datt
>> >>
>> >
>>
>> --
>> Regards,
>> Nitul Datt
>>
>
> Try and keep things on schedule. You wasted quite some time initially
> "going through code".

Wasn't quite sure how to proceed.

> I still don't have any reviewable code.
>

Will do.


> Regards,
> Vedant.
>


--
Regards,
Nitul Datt