<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 9:49 AM, Abhinandan Ramprasath <span dir="ltr"><<a href="mailto:abhiin1947@gmail.com" target="_blank">abhiin1947@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="im">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><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>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><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><div>This approach was the one I was planning to take.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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><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></div></div></blockquote><div><br></div><div>According to the docs Hydrogenaudio( <a href="http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet">http://wiki.hydrogenaudio.org/index.php?title=Cue_sheet</a> ) and Wikipedia( <a href="http://en.wikipedia.org/wiki/Cue_sheet_(computing)">http://en.wikipedia.org/wiki/Cue_sheet_(computing)</a> ), each TRACK can have it's own TITLE and PERFORMER tag. Which would mean that I will be able to store metadata in the CUE sheet that has nothing to do with the parent.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Matěj<br>
_______________________________________________<br>
Amarok-devel mailing list<br>
<a href="mailto:Amarok-devel@kde.org" target="_blank">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></div><br></div></div>
</blockquote></div><br></div></div>