This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#9789 - cuesheet using MoB
Attached to Project:
Rockbox
Opened by Jonathan Gordon (jdgordon) - Monday, 12 January 2009, 14:33 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Monday, 20 July 2009, 07:19 GMT+2
Opened by Jonathan Gordon (jdgordon) - Monday, 12 January 2009, 14:33 GMT+2
Last edited by Jonathan Gordon (jdgordon) - Monday, 20 July 2009, 07:19 GMT+2
|
Detailsthis is a first attempt at moving cuesheet support closer into the playback engine instead of being a tack-on to the WPS...
first version is swcodec only.. hwcodec needs adding. What this patch does is move the actual cuesheet loading/parsing into playback/buffering. The next step is to fix the wps so the only extra stuff it needs for cuesheets is the progressbar drawing code. 
cuesheet-mob-1.patch
(11.7 KiB)
apps/cuesheet.c | 18 +++++----------- apps/cuesheet.h | 3 -- apps/onplay.c | 8 +++---- apps/gui/gwps-common.c | 33 +++-------------------------- apps/gui/gwps.c | 8 +++---- apps/metadata.c | 7 ------ apps/metadata.h | 2 - apps/playback.c | 54 +++++++++++++++++++++++++++++++++---------------- 8 files changed, 56 insertions(+), 77 deletions(-) |
This task depends upon
Closed by Jonathan Gordon (jdgordon)
Monday, 20 July 2009, 07:19 GMT+2
Reason for closing: Accepted
Additional comments about closing: a modified version of this was commited in r21978
Monday, 20 July 2009, 07:19 GMT+2
Reason for closing: Accepted
Additional comments about closing: a modified version of this was commited in r21978
This one is close to being finished... I've moved everything out of the wps that I wanted to. Playback adds a new event which is called when the cue subtrack changes which the WPS uses to do a full redraw (instead of the mess in update() ). unfortunatly playback doesnt keep the current tracks offset going at the end of the track so we cant use that callback fully just yet
If it works you should see the cuemarks on the progress bar, be able to "track skip" inside the track, and the id3 info shuold be updated correctly as the song progresses...
Using the default WPS and album art, play an album, skip to track 5, then repeatedly (fast) skip back/forward between tracks 4 and 5. Playback works fine, but the WPS ends up with junk metadata displayed; heiroglyphs, basically (althogh nicely scrolling heiroglyphs).
do the patch as it is above with some changes:
- mp3entry.cuesheet will be changed to .cuesheet_handle, if thats >=0 then a call to cuesheet_get_current() will return a cuesheet pointer, doing this because there will be no static buffers anywhere for cuesheets(i.e it will always be on.)
- on file buffer a .cue will be checked for, if found it gets parsed and dumped into the buffer and its hid will get put in the mp3entry struct
- playback will stay how it is in svn, so prev/next track will not know about cuesheets
- the wps will handle actual cue subtracks (hopefully more nicely than svn though)
next steps would be thinking about getting embedded .flac cuesheets working..
oh, there is a comment above that cuesheets should be handled like playlists and I agree 100%... but of course that cant really happen until the track skipping happens through playlist and not playback (wps calls playlist_next(), that then talks to playback.c to change tracks)
I dont really like exposing the handle id in the mp3entry struct, but I dont think a pointer into the buffer is at all safe..... ill think about this a bit... A possible answer is but cuesheet_get_current() inside playback.c so it has access to the internally stored track hid's.... thats sort of clean, but we dont want to add more crap there :/
note to self, this will probbaly break on targets because the mob pointer is used without making sure it hasnt moved (which it could during a track playtime) the changes to audio_current_track() are bad.. need to put those bufgetdata() calls into something a bit safer