<div dir="ltr">On Sun, Sep 15, 2013 at 11:58 PM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz" target="_blank">matej@laitl.cz</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 15. 9. 2013 Abhinandan Ramprasath wrote:<br>
> Hi,<br>
><br>
> After spending a lot of time staring at the code, I would like to propose<br>
> the following changes to implement CUE sheet support in Amarok.<br>
><br>
> Most of the necessary CUE decoding and track splitting functions are already<br>
> available in CueFileSupport.h . It's got functions to scan for and validate<br>
> CUE sheets too. I'd like to use these functions in the collectionscanner,<br>
> scan for .cue files once the XML is read. To be even more precise, just<br>
> before/after the CollectionScanner::Track for each track is created. So<br>
> each child track would be treated as a separate track right from the<br>
> beginning.<br>
><br>
> I was thinking of having a few additional data members in<br>
> CollectionScanner::Track and Meta::SqlTrack to represent child tracks and<br>
> to store their start times and end times.<br>
<br>
</div>Yeah, that makes sense.<br>
<div class="im"><br>
> This would then be stored in the database. To do that, I'd like to do that<br>
> by adding a few columns to the track or the urls table such as, a child or<br>
> not boolean, start time and end time.<br>
<br>
</div>Yep, this is the natural approach, however, this might lead to some problems.<br>
There are assumptions all over that (deviceid, rpath) in the urls table is<br>
unique for all urls. This wouldn't hold anymore.<br>
<br>
One possibility would be to change the assumption everywhere (tricky, perhaps<br>
doable).<br></blockquote><div><br></div><div>This approach was the one I was planning to take.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Second to somehow mix the start/end times into the rpath (is there a character<br>
not allowed in UNIX file paths?) and carefully treat places that use it.<br>
<br>
Third to recreate the child tracks late - after picking them up from the<br>
database (extremely tricky IMO). </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another open questions:<br>
what should happen when you try to copy/move one child track out of Local<br>
Collection? What would happen if you edit the metadata? (I guess the change to<br>
title would go to the cuesheet, everything else to the underlying file).<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
        Matěj<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org">Amarok-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/amarok-devel" target="_blank">https://mail.kde.org/mailman/listinfo/amarok-devel</a><br>
</blockquote></div><br></div></div>