On Mon, Nov 24, 2014 at 5:56 PM, Nitul Datt <nitul1...@gmail.com> wrote:
> On 11/24/14, vedant agarwala <vedant.k...@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 <nitul1...@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". I still don't have any reviewable code. Regards, Vedant.
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
