Rockbox

  • Status Closed
  • Percent Complete
    100%
  • 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.

darkkone commented on 2006-04-21 22:05

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.

linuxstb commented on 2006-05-01 09:45

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.

lowlight commented on 2006-05-03 15:24

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)
lowlight commented on 2006-05-03 15:28

Small fix.

(application/octet-stream)    gapless_mpa.patch (9.8 KiB)
lowlight commented on 2006-05-03 19:09

Forgot to run dos2unix before.

(application/octet-stream)    gapless_mpa.patch (9.4 KiB)
lowlight commented on 2006-05-05 13:05

Another small update.

(application/octet-stream)    gapless_mpa.patch (9.4 KiB)
linuxstb commented on 2006-05-20 11:57

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?

Redbreva commented on 2006-05-20 12:14

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...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing