Implementing CUE sheet support in Amarok

Abhinandan Ramprasath abhiin1947 at gmail.com
Mon Sep 16 04:19:18 UTC 2013


On Sun, Sep 15, 2013 at 11:58 PM, Matěj Laitl <matej at laitl.cz> wrote:

> On 15. 9. 2013 Abhinandan Ramprasath wrote:
> > Hi,
> >
> > After spending a lot of time staring at the code, I would like to propose
> > the following changes to implement CUE sheet support in Amarok.
> >
> > Most of the necessary CUE decoding and track splitting functions are
> already
> > available in CueFileSupport.h . It's got functions to scan for and
> validate
> > CUE sheets too. I'd like to use these functions in the collectionscanner,
> > scan for .cue files once the XML is read. To be even more precise, just
> > before/after the CollectionScanner::Track for each track is created. So
> > each child track would be treated as a separate track right from the
> > beginning.
> >
> > I was thinking of having a few additional data members in
> > CollectionScanner::Track and Meta::SqlTrack to represent child tracks and
> > to store their start times and end times.
>
> Yeah, that makes sense.
>
> > This would then be stored in the database. To do that, I'd like to do
> that
> > by adding a few columns to the track or the urls table such as, a child
> or
> > not boolean, start time and end time.
>
> Yep, this is the natural approach, however, this might lead to some
> problems.
> There are assumptions all over that (deviceid, rpath) in the urls table is
> unique for all urls. This wouldn't hold anymore.
>
> One possibility would be to change the assumption everywhere (tricky,
> perhaps
> doable).
>

This approach was the one I was planning to take.


> Second to somehow mix the start/end times into the rpath (is there a
> character
> not allowed in UNIX file paths?) and carefully treat places that use it.
>
> Third to recreate the child tracks late - after picking them up from the
> database (extremely tricky IMO).


> Another open questions:
> what should happen when you try to copy/move one child track out of Local
> Collection? What would happen if you edit the metadata? (I guess the
> change to
> title would go to the cuesheet, everything else to the underlying file).
>

If only one track has to be moved then I'll have to break the file into
tracks then move it in/out of the collection. I see no other way. Or, We
could just move the entire file with cue sheet to the new location. Editing
metadata, in my opinion, is the most tricky one of them all. I could change
them in the database alone, not commit it to the tracks or cue sheet. I had
a chat with Myriam the other day about this and she was against the idea of
amarok editing the cue sheet.


>         Matěj
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130916/52158931/attachment.html>


More information about the Amarok-devel mailing list