Bug 10823 - MP3 plays a bit too much at track boundary
: MP3 plays a bit too much at track boundary
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Audio
: unspecified
: PC Fedora
: P1 normal (vote)
: 7.4.0
Assigned To: Richard Titmuss
http://forums.slimdevices.com/showthr...
:
Depends on: 12909
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-25 08:05 UTC by Alan Young
Modified: 2009-10-05 14:37 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alan Young 2009-01-25 08:05:30 UTC
LAME-encoded MP3s playing one after another, when synchronized with an ip3k player, need to skip about 18-30ms at the start of each track to regain sync. The same problem does not occur playing FLAC or PCM.

The assumption has to be that this is something to do with skipping encoder padding either at the beginning or end of the track, but the trace output does not suggest that this is the case. As far as I can see, SP is doing the right thing.

src/audio/decode/decode_mad.c:134 DEBUG lame magic 4c414d45 bitlen 1752
src/audio/decode/decode_mad.c:148 DEBUG encoder delay 576
src/audio/decode/decode_mad.c:149 DEBUG encoder padding 1303
src/audio/decode/decode_mad.c:370 DEBUG Skip encoder_delay=0 pcm->length=1152 offset=1105
...
src/audio/decode/decode_mad.c:393 DEBUG Reached end of stream
src/audio/decode/decode_mad.c:398 DEBUG Remove encoder padding=774
src/audio/decode/decode_output.c:493 DEBUG Removing 6192 bytes padding from buffer

Perhaps the ip3k player is doing something different but I cannot see any difference in the code.
Comment 1 Chris Owens 2009-03-16 09:50:47 UTC
We are now planning to make a 7.3.3 release.  Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future.

Thanks!
Comment 2 Chris Owens 2009-03-30 17:34:28 UTC
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out.  If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it.

Thanks.
Comment 3 Richard Titmuss 2009-06-09 13:55:22 UTC
*** Bug 11877 has been marked as a duplicate of this bug. ***
Comment 4 Ben Klaas 2009-08-26 07:53:05 UTC
this is an administrative shuffle on priority fields to help make better judgment on the top end of the priority list. P4->P5, P3->P4, and P2->P3.
Comment 5 Richard Titmuss 2009-09-08 04:44:57 UTC
Alan, this will break mp3 sync. Right? It probably should be a P1.
Comment 6 Alan Young 2009-09-08 07:48:06 UTC
It does not really break it. It just means that a small resync happens at track boundaries for sync-groups that include a mix of SP and ip3k players.
Comment 7 SVN Bot 2009-09-09 06:37:51 UTC
 == Auto-comment from SVN commit #7471 to the jive repo by richard ==
 == https://svn.slimdevices.com/jive?view=revision&revision=7471 ==

Fixed Bug #10823
Fix mp3 gapless playback, finally!
Comment 8 James Richardson 2009-10-05 14:37:02 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.