Bugzilla – Bug 10026
PCM != WAV
Last modified: 2009-10-05 14:28:33 UTC
SC does not properly distinguish between PCM and WAV formats. The players only support PCM (see bug 10000). PCM should be handled separately, although a fix to 10000 would make this unnecessary for all except SB1s.
The summary is true, but I'm not sure it's a bug. What's the issue?
If you actually send WAV data to the players you get: (a) in the case of 16-bit or 32-bit frame sizes, a click or pop at the start, as the player tries to interpret the header as a couple of frames; (b) nasty noise if the frame-size is 24 bits because you end up unaligned. The players expect raw PCM data. However, WAV->XXX transcoding works best when the transcoding program is allowed to interpret the WAV header for itself, rather than have to be told all the parameters (not possible with all transcoders, I think). If you combine this with seeking then it is important to include the WAV header before the PCM data after seeking in the file. If you are delivering raw PCM then it it important to skip and discard the WAV header at the start, and not to include it when seeking. The streaming mechanism needs a way to know whether it should deliver WAV or PCM data, including when seeking. This could be achieved by adding a PCM type to types.conf and internally declaring that the players support PCM, not WAV.
Some potential changes, incomplete, just saved here for future reference: Index: Slim/Player/Squeezebox.pm =================================================================== --- Slim/Player/Squeezebox.pm (revision 23929) +++ Slim/Player/Squeezebox.pm (working copy) @@ -586,7 +588,7 @@ $format ||= 'mp3'; - if ($format eq 'wav') { + if ($format eq 'pcm') { $formatbyte = 'p'; $pcmsamplesize = 1; Index: Slim/Player/Squeezebox2.pm =================================================================== --- Slim/Player/Squeezebox2.pm (revision 23929) +++ Slim/Player/Squeezebox2.pm (working copy) @@ -96,5 +96,5 @@ sub formats { my $client = shift; - return qw(wma ogg flc aif wav mp3); + return qw(wma ogg flc aif pcm mp3); }
Depends on 10000, which is targetted for 8.0
Yes, I've marked it as dependent on 10000 because 10000 would be one way of making this problem go away. It is not really dependent on it, so much as related to it. We could really do with a 'related-to' fields in bugzilla.
Created attachment 4547 [details] Proposed fix This would distinguish between PCM and WAV in the strema control code and restore seeking capability to WAV files streamed as WAV (actually PCM)
Change 24597.
And change 24600
Alan, Dan Evans in support would like to see this in 7.3.2. Is it safe to put it in the earlier version? We'd like to make an informed decision.
Andy suggests these users should really use flac.
Like I said in my email on Wednesday. It depends if you think you can get sufficient testing it. It would take some work to ensure that the backport was correct - the best place to start would be the patch attache dto this bug but I think there were one or two other adjustments that should be considered. Like Andy says, FLAC is preferable for all except ReadyNAS users.
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.