Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#5200 - gapless play fails after seeking within track

Attached to Project: Rockbox
Opened by PY (py) - Friday, 21 April 2006, 15:27 GMT+2
Last edited by Dave Chapman (linuxstb) - Monday, 01 May 2006, 11:45 GMT+2
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Player Type All players
Severity Medium
Priority Normal
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Private No

Details

First of all, thanks Rockbox for bringing gapless mp3 to the iPod mini 2g.
Album made of LAME VBR mp3 with gapless tags, playing great when not seeking. However, if seeking is performed in a track, the next transition will always fail.
Rockbox version 20060419.
This task depends upon

Closed by  Dave Chapman (linuxstb)
Saturday, 20 May 2006, 15:08 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  All testers are reporting that this issue is now fixed.
Comment by Paul Louden (darkkone) - Saturday, 22 April 2006, 00:05 GMT+2
This is a known bug, and I *think* is implicitly caused by the nature of VBR MP3s. I'm not sure how solvable it is.
Comment by Dave Chapman (linuxstb) - Monday, 01 May 2006, 11:45 GMT+2
If the number of samples to drop at the end of the file is <= the size of the final frame, then it should be possible to drop them even after seeking. I don't know how often this is true, but IMO we should try and at least implement that case.
Comment by Mark Arigo (lowlight) - Wednesday, 03 May 2006, 17:24 GMT+2
This patch *should* fix gapless after seeking (it does to my ears). Mainly, I've removed the dependence on sample count for determining the end of the file. Libmad just will decode until the end of the file, then the samples in the final frame are cut. For cases where more than the final frame is to be cut, I utilize the "feature" of libmad where it won't decode the last frame without padding :). Thus it will exit on the second to last frame from which we can cut the required samples. For this to work, all tags must be stripped from the end of the file during buffering. Currently, we only strip ID3v1 tags, so APE tags will screw this up.
(application/octet-stream)    gapless_mpa.patch (9.8 KiB) 
 mpa.c |  181 ++++++++++++++++++++++++++++++------------------------------------
 1 file changed, 83 insertions(+), 98 deletions(-)

Comment by Mark Arigo (lowlight) - Wednesday, 03 May 2006, 17:28 GMT+2
Small fix.
(application/octet-stream)    gapless_mpa.patch (9.8 KiB) 
 mpa.c |  183 ++++++++++++++++++++++++++++++------------------------------------
 1 file changed, 85 insertions(+), 98 deletions(-)

Comment by Mark Arigo (lowlight) - Wednesday, 03 May 2006, 21:09 GMT+2
Forgot to run dos2unix before.
(application/octet-stream)    gapless_mpa.patch (9.4 KiB) 
 mpa.c |  163 ++++++++++++++++++++++++++++++------------------------------------
 1 file changed, 75 insertions(+), 88 deletions(-)

Comment by Mark Arigo (lowlight) - Friday, 05 May 2006, 15:05 GMT+2
Another small update.
(application/octet-stream)    gapless_mpa.patch (9.4 KiB) 
 mpa.c |  163 ++++++++++++++++++++++++++++++------------------------------------
 1 file changed, 75 insertions(+), 88 deletions(-)

Comment by Dave Chapman (linuxstb) - Saturday, 20 May 2006, 13:57 GMT+2
Most recent gapless_mpa.patch now applied to CVS.

It works for me with my single test album, but can people with larger collections of MP3 files needing gapless playback please test and confirm if this bug can be closed?
Comment by Mark Bright (Redbreva) - Saturday, 20 May 2006, 14:14 GMT+2
Just tried it on a 192KCBR MP3 album - before 'very slight click' on track transition if FF'd, after - Nothing... Upshot it seems to work on the only album I have that should play back gapless

Loading...