SoK Project Query

[Nitul Datt]

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?

> 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