Wiki > Main > CuesheetSupport (compare)
Difference: CuesheetSupport (r20 vs. r19)
This page aims to be the central point of the discussion about how to implement cuesheets support in Rockbox.
This feature has been requested almost since the beginnings of Rockbox (maybe I'm exaggerating a bit but it's probably not far from being true ).
There is tracker entry about it : FS#278.
There are also several forum discussions :
There are two different possible ways of implementing cuesheet support in Rockbox.
If you have any other ideas, please add them !
A music file with an associated cuesheet is viewed as a single file. The possibility to change tracks within the cuesheet is brought by the WPS (PREV and NEXT) and by a special "cuesheet viewer". The WPS should display the information (artist, title) of the current segment of the cuesheet, but the progressbar should reflect progress within the entire file, with the possibility to seek within the whole file. There should also be markers in the progressbar to indicate the location of the different segments. Skipping to the next file in the playlist could be done with a key combination like PLAY+NEXT.
This approach doesn't allow shuffling or adding the tracks separately in the Database, but to me it seems easier to implement, and cleaner too.
A cue sheet would be treated as a playlist file. Adding it would result of separately adding all of its tracks to the main playlist, allowing them to be used as if they were separate files (which includes shuffling).
I don't really like that approach because I believe cuesheets are used for a purpose that's not the same as simply obtaining gapless playback. Also it seems harder to implement in the playback code.
Is the possibility of shuffling the songs within a cuesheet possible ? a good idea ? a wanted feature ?
IMHO, cuesheets are used with files that constitute a single entity (for example live recording, DJ mixes or mixed compilations), so shuffling them doesn't really make sense. That's why I'm more in favor of the first approach (Amarok).
Should the individual tracks from the cuesheet be added to the database ?
I'll quote Llorean on this, because it reflects pretty well what I think (original post):
"As for the Tag Database, yeah there's only one file open operation instead of several, but seeking has to occur in the file to start at various points, which actually probably means more effort during playback.
Cuesheet support should in fact not be limited to CUE files (that can be separate or included in the metadata of a FLAC file). We also have to consider the possibility of extending the same system to enable support of bookmarked audio formats :
The topic was brought up on IRC and a few problems have been identified in adding cue (or any sub-track handling) into the core.
Nico and I (JdGordon?) are going about cue support in two sort of different ways, So we'll see which way works better.
cuesheet.patch: the patch
compile it and put cuesheet.rock in the viewers/ folder. to run, select your .cue file (must be int he same fodler as the associated audio file. One annoying problem is that the player may lock up if you try running a .cue file after exiting this plugin without running any other plugins first. Dont know why. (The current attachment is commitable, but I'll wait to see what Nicolas comes up with first)
cuesheet_tracklist.patch: the cuesheet viewer patch
I used Jonathan's parser as a base and, with his help, implemented a cuesheet viewer plugin which displays a list of the tracks. It allows to seek to the position of the track within the currently playing file (even if it's not the file represented by the cuesheet, but there are still some checks to make sure we don't try to seek to a position that doesn't exist). The seeking is also much faster because I added
%W% The patch is now also in the tracker : FS#6460
cuesheet_core_v4.patch: cuesheet support in the core (v4)
This time I added cuesheet support in the core. In this implementation, cuesheets behave just like regular audio files, but when they are loaded, it's actually the audio file they point to that is loaded instead. This means the file mentioned in the cue file must exist (it has to be a relative path), and the filenames of the cuesheet and the audio file are totally independent. Cuesheets can also be viewed like before (and seeking works too) by selecting them, entering the context menu, and then selecting "View cuesheet".
Changed in v2 :
Changes in v3 :
Changes in v4 :
What's left to do :
Known bugs :
OK, well i've warmed to Nico's patch and unless i'm mistaken the only big problem with this patch is its crazy memory usage. I think the bes solution is to allocate a user-specified buffer for the sub tracks at bootup so the people who want big cue's can have them, and there is very minimal waste for people who wont use cues. The edited patch I have added is a vry basic start for this. there needs more error checking and i dont know what else, but this shuold work (default is room for 10 tracks)
r23 - 07 May 2013 - 08:10:06 - PurlingNayukiRevision r20 - 31 Dec 2006 - 10:17 - JonathanGordon
Revision r19 - 27 Dec 2006 - 19:16 - EwanDavies
Copyright © by the contributing authors.