Bug 2944 - Silent gaps introduced into audio output (esp. with WMA VBR)
: Silent gaps introduced into audio output (esp. with WMA VBR)
Status: RESOLVED FIXED
Product: SB 2/3
Classification: Unclassified
Component: Audio
: 48
: PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Richard Titmuss
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-07 04:31 UTC by Sam Hawker
Modified: 2009-09-08 09:20 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Hawker 2006-02-07 04:31:40 UTC
With WMA VBR silent gaps are introduced into the audio output. (Relatively) large gaps seem to occur near the start of the track even with fairly low bitrate (200kbps) files. With high bitrate files (500kbps) small gaps occur throughout the track. No part of the audio is actually lost, it is simply broken up by silences. If the same files are transcoded to FLAC by SlimServer there are no gaps at all (even though this is more stressful for the host PC and requires more bandwidth). In some cases transcoding to WAV does still produce some small gaps but they are much less frequent than with WMA VBR and the large gaps near the start of the track are not present.
Comment 1 Blackketter Dean 2006-04-23 21:32:26 UTC
Sam: Is this still happening with the latest nightly release of 6.2.2?  There's been a bunch of bug fixed in WMA and other parts of the firmware.  Can you confirm that it's still happening?
Comment 2 Sam Hawker 2006-04-25 15:59:19 UTC
I'm using FLAC->WAV on a QNAP nowadays but I just downloaded and tested the latest 6.2.2 nightly. And it still does it. Interestingly I get these dropouts even with the buffer fullness reading 100%.
Comment 3 Richard Titmuss 2006-06-01 08:54:36 UTC
Sam, could you attach a file that has this problem. Thanks, Richard
Comment 4 Sam Hawker 2006-06-01 12:32:32 UTC
The files attached to bug report #2985 also demonstrate this problem (for me at least).
Comment 5 Blackketter Dean 2006-06-06 16:51:07 UTC
richard, is this something you are looking at for 6.3?
Comment 6 Richard Titmuss 2006-06-12 14:55:34 UTC
Moving target to 6.5.

Sam I could recreate the gap at the start of the track with the test file attached to bug 2985 as you suggested. In the original report you also mentioned "small gaps occur throughout the track", do you have an example that demonstrates this?

Thanks,
Richard
Comment 7 Richard Titmuss 2006-07-13 02:51:00 UTC
This bug is fixed in firmware 58. It is currently undergoing
internal testing. You will be notified again when it is made part of
a nightly release. 
Comment 8 Chris Owens 2006-09-03 12:16:36 UTC
I apologize; I've been slow in adding this notification to some of the bugs.  Please ignore it if you've already tried the new firmware.

This bug fix is now available in the nightly Slimserver release. The release is available from:

http://www.slimdevices.com/dev_nightly.html

If you prefer to wait for the next official release, you will be notified when it occurs.

You'll need to install the new version of Slimserver, and then force your Squeezebox to upgrade its firmware by holding down the 'Brightness' button on the remote control until the firmware upgrade process begins.

If you are still experiencing this problem after upgrading your affected players to the new firmware, please reopen the bug.