Rockbox

Tasklist

FS#5200 - gapless play fails after seeking within track

Attached to Project: Rockbox
Opened by PY (py) - Friday, 21 April 2006, 13:27 GMT
Last edited by Dave Chapman (linuxstb) - Monday, 01 May 2006, 09:45 GMT
Task Type Bugs
Category Music playback
Status Closed
Assigned To No-one
Operating System All players
Severity Medium
Priority Normal
Reported Version
Due in Version Version 3.0
Due Date Undecided
Percent Complete 100%
Votes 0
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, 13:08 GMT
Reason for closing:  Fixed
Additional comments about closing:  All testers are reporting that this issue is now fixed.
Comment by Paul Louden (darkkone) - Friday, 21 April 2006, 22:05 GMT
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, 09:45 GMT
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, 15:24 GMT
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)
Comment by Mark Arigo (lowlight) - Wednesday, 03 May 2006, 15:28 GMT
Small fix.
(application/octet-stream)    gapless_mpa.patch (9.8 KiB)
Comment by Mark Arigo (lowlight) - Wednesday, 03 May 2006, 19:09 GMT
Forgot to run dos2unix before.
(application/octet-stream)    gapless_mpa.patch (9.4 KiB)
Comment by Mark Arigo (lowlight) - Friday, 05 May 2006, 13:05 GMT
Another small update.
(application/octet-stream)    gapless_mpa.patch (9.4 KiB)
Comment by Dave Chapman (linuxstb) - Saturday, 20 May 2006, 11:57 GMT
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, 12:14 GMT
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...