Where to write CUE support code?

[Bartek-17]

Hi
Could someone please tell me where is the place in the Amarok repo that
is suitable for placing CUE support code in? I'm asking because I'd like
to help coders, but as I have never investigated Amarok's code, I don't
know where to search.

Bartek
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

Hi Bartek

As I am not sure if you are subscribed to the mailing list, I am
forwarding this to you directly as well.

About full CUE sheet support, there are really two parts to this, one
fairly simple one (as most of the code is there, it just needs to be
put together in the right way) and one quite complex one.

The simple part is loading a CUE sheet from a file and having it show
up as individual tracks in the playlist. Right now, it shows up as a
single track with bookmarks in it, but I wrote some code a while back
that can make a standalone track out of a part of a longer track,
bounded by 2 bookmarks (technically just bounded by any two
timepoints, although in the ui they are currently created by marking
two bookmarks in the bookmark manager and selecting the "create
timecode track" from the context menu).

So, extending this code to create a number of these timecode tracks
for each part of a cue file should be pretty simple. The source for
the timecode tracks are in src/timecode and the bookmarks are in
src/amarokurls.

The hard part is getting this stuff integrated into the local
collection so tracks defined by a cue sheet can be part of the local
collection on par with any other track. But I am guessing that
actually getting the loading of the cur files to generate timecode
tracks is a necessary first step in any case.

- Nikolaj

On Sat, Oct 3, 2009 at 9:37 PM, Bartek <bfo@...> wrote:

> Hi
> Could someone please tell me where is the place in the Amarok repo that
> is suitable for placing CUE support code in? I'm asking because I'd like
> to help coders, but as I have never investigated Amarok's code, I don't
> know where to search.
>
> Bartek
> _______________________________________________
> Amarok mailing list
> Amarok@...
> https://mail.kde.org/mailman/listinfo/amarok
>

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

> The hard part is getting this stuff integrated into the local
> collection so tracks defined by a cue sheet can be part of the local
> collection on par with any other track.

This is indeed the hardest part. Identifying CUEs will have to take
place in the scanner, and, frankly, I don't even know if the database
schema could handle abstract track urls.

Right now a local track is identified by it's unique URL, e.g.,
/home/ramblurr/Music/01-OhYea.mp3. But to support CUE tracks the
scanner will have to:\

1. Locate the CUE when scanning
2. Parse the CUE into timecode tracks
3. Enter the split tracks into the database.

So a CUE track's url might look something like
/home/ramblurr/Music/01-OhYea.mp3;path_to_cue;begin_point1;end_point1

Casey
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

Some splitting logic can be borrowed from apps closely working with cue:

k3b
QShnToolSplit - http://www.qt-apps.org/content/show.php/QShnToolSplit?content=110373
Flacon - http://www.kde-apps.org/content/show.php/Flacon?content=113388

2009/10/14 Casey Link <unnamedrambler@...>

> The hard part is getting this stuff integrated into the local
> collection so tracks defined by a cue sheet can be part of the local
> collection on par with any other track.

This is indeed the hardest part. Identifying CUEs will have to take
place in the scanner, and, frankly, I don't even know if the database
schema could handle abstract track urls.

Right now a local track is identified by it's unique URL, e.g.,
/home/ramblurr/Music/01-OhYea.mp3. But to support CUE tracks the
scanner will have to:\

1. Locate the CUE when scanning
2. Parse the CUE into timecode tracks
3. Enter the split tracks into the database.

So a CUE track's url might look something like
/home/ramblurr/Music/01-OhYea.mp3;path_to_cue;begin_point1;end_point1

Casey

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

[Simon Bühler]

> 1. Locate the CUE when scanning
this code already exists

> 2. Parse the CUE into timecode tracks
this is also present

> 3. Enter the split tracks into the database.
thats the big part left ...
 
> So a CUE track's url might look something like
> /home/ramblurr/Music/01-OhYea.mp3;path_to_cue;begin_point1;end_point1

wouldn't it be better to add a cue sheet table, throw in a forein key to the
local track entry (fk_cuesheet_id, can be null)  and avoid string splitting in
rpath completly?
The cue sheet table can contain also a uniqueid per cue sheet track so when a
typo in the title or the cue sheet times are edited inside the amarok gui, the
metadata can be synced easily with the cue sheet content or just be kept in
amarok db if the cue sheet is not writable when playing from cd/dvds storage.

anyway, i'm looking forward to working cue sheet support, its been a long time
(too long ) without

_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

>> 1. Locate the CUE when scanning
> this code already exists
>
>> 2. Parse the CUE into timecode tracks
> this is also present

Yup. That, along with the generating of bookmarks was my doing in
porting the cue support from Amarok 1.4. Since then I haven't had time
to continue working on it.

> wouldn't it be better to add a cue sheet table, throw in a forein key to the
> local track entry (fk_cuesheet_id, can be null)  and avoid string splitting in
> rpath completly?

Yes, I'm just hesitant to make database changes. But your description
should work, though I haven't investigated fully.

> anyway, i'm looking forward to working cue sheet support, its been a long time
> (too long ) without

Thank you :D I can stop feeling guilty about leaving it half assed.

Casey
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

On Wed, 14 Oct 2009 11:30:22 -0400, Casey Link <unnamedrambler@...>
wrote:
>> anyway, i'm looking forward to working cue sheet support, its been a
>> long time
>> (too long ) without
>
> Thank you :D I can stop feeling guilty about leaving it half assed.
>
> Casey

*If* you're going to (or if you already did) clone a repository @
gitorious for your work on the cue sheets, please let me know. I'd be more
than happy to test stuff since I can't wait for cue support in Amarok 2. I
guess 85% of my collection exists of VA albums which exists of 1 mp3 / cue
sheet per CD. :)

--
Met vriendelijke groet / With kind regards,
Eelko Berkenpies
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok

> *If* you're going to (or if you already did) clone a repository @
> gitorious for your work on the cue sheets, please let me know. I'd be more
> than happy to test stuff since I can't wait for cue support in Amarok 2. I
> guess 85% of my collection exists of VA albums which exists of 1 mp3 / cue
> sheet per CD. :)

I'm sorry that was a typo... I'm looking forward to have someone else
work on it. I have no time in for the foreseeable future.

Casey
_______________________________________________
Amarok mailing list
Amarok@...
https://mail.kde.org/mailman/listinfo/amarok