• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Music playback
  • Assigned To No-one
  • Operating System All players
  • Severity Medium
  • Priority Very Low
  • Reported Version
  • Due in Version Version 3.0
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by py - 2006-04-21
Last edited by linuxstb - 2006-05-01

FS#5200 - gapless play fails after seeking within track

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.

Closed by  linuxstb
2006-05-20 13:08
Reason for closing:  Fixed
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

All testers are reporting that this issue is now fixed.

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.

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.

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.

Small fix.

Forgot to run dos2unix before.

Another small update.

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?

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


Available keyboard shortcuts


Task Details

Task Editing