Bugzilla – Bug 14
Add support for mono, 8bit and other sample rates, left/right swap
Last modified: 2009-10-08 11:15:28 UTC
The following data formats need to be supported on the client natively in the firmware: Mono/Stereo/Stereo-swapped 8bit/16bit 8/16/32/44.1/48k S/sec Extra credit for uLaw/aLaw 8bit.
the hardware mp3 decoder seems to play mono mp3s just fine on both my slimp3 and squeezebox but it -definately- screws up when i use a mono ogg file. this doesn't seem like a firmware issue to me, just a bug in slimserver's transcoding not passing on the fact that the audio is mono to the reencoding stages (though there might be a firmware component on the squeezebox if you need to tell it the pcm stream its receiving is non stereo).
Created attachment 190 [details] mono FLAC file that plays fast on squeezebox
Spoke with another customer via e-mail who had this to say: I have a database containing hundreds of files of historical recordings. These files have been recorded in mono and to save harddisk space, I have saved these files as mono wave files first and subsequently compressed them to FLAC. This way, files are at least 30% smaller than when directly compressed into flac and the result is 100% equal, if played back correctly. Unfortunately, slimserver cannot deal with these files, probably because the bit rate is read as if it were a stereo file, resulting in a increased playback (probably exactly twice the speed). Other players tested such as Foobar2000 can perfectly play the files at the correct speed, so there is no demonstrable error in these files temselves. The impact on the functionality is such that I cannot palyback approx. 300 hours of music (mu total collection contains 2000 hours of music).
I have experienced the same problem. I do not believe that the problem is because the files are mono though. I think it has to do with the bit rate and sample rates and the number of channels. I first noticed the problem on an Ogg file that has the following characteristics: bitrate = 18 channels = 1 samplerate = 8000 bitrate_nominal = 16 Playing this file in SqueezeBox results in super fast playing. I then took an Ogg music file that plays fine in SqueezeBox and saved it so that it has the following characteristics: bitrate = 22 channels = 2 samplerate = 8000 bitrate_nominal = 22 (Both files have an Ogg "quality" of 1.) The second file is stereo but it displays the same fast playing problem. I also tried: bitrate = 48 channels = 1 samplerate = 48000 bitrate_nominal = 60 which resulted in a file that still played fast but was slower than the others. I've also noticed this problem in SlimServer (ver 5.3.1 and 5.4.0) when playing these files to a computer using foobar2000 as the player. I was able to work around this problem in SlimServer by editing the convert.conf file. In the OggDec section I removed the "-R" from the OggDec side of the pipe. I removed the "-r -x" from the Lame side of the pipe. The above change allows these problem files to be streamed through SlimServer without the fast playing problem - but only when streaming to a computer using an external player. This change did not seem to add a bigger load to the server hosting SlimServer (on Windows 2000.) Interestingly, the SoftSqueeze java player does exhibit the same problem when playing the same files.
I neglected to mention that my "problem" files are radio shows that are recorded from an internet stream for later playback (by family members that aren't tech savvy.) These shows do not have a SqueezeBox compatible feed either. Because of the length of these shows (up to 3 hours) they are saved in Ogg files to save on disk space.
I have seen similar behavior. I have a 16khz wav mono wave file. When played it seems to play very fast. Only when I convert the wav file to stereo at 44.1 Khz does it play properly. Both conversions (mono->stereo + 16khz->44.1khz) seem to be necessary. Caveat: I'm testing this with softsqueeze. Also note, when streamed to: slimserver:9000/stream.mp3 things play normally.
This happens with mono Ogg streams as well. Example: http://ogg.tv-radio.fr:1441/encoderfmusiques.ogg
*** Bug 911 has been marked as a duplicate of this bug. ***
What is the status of this bug? I'm trying to listen to WCLV in Cleveland, Ohio and it shows every sign of this bug!
vidur: does your SOX work address this?
The good news is that the use of sox addresses this for Ogg streams (see bug 699). and native FLAC decoding addresses this for FLAC files. It's still the case that non-stereo/non-44.1KHz sample rate PCM files will play incorrectly, but that's a server bug, not a client one. The client can now accept mono/stereo, 8/16/32 bit, 8/11.025/12/16/22.05/24/32/44.1/48 KHz stream (no stereo-swapped or uLaw/aLaw).
I'm sorry - native FLAC and a wider range of PCM inputs is a feature of the new hardware, not SB1. We should still see if sox can do transcoding server-side for SB1/SliMP3.
Moving bugs that won't be immediately fixed in 6.1 release. Please review and update if this is an error or if this bug has already been fixed. Thanks.
I don't know if my problem is caused by this. I can't listen live to wnycam or wyncfm. Both are mono 22kb streams. I can listen to the HIFI wnycfm stream, and many other streams. Curiously, if I rip the wnycam stream with mplayer, I can play the resulting file with slimserver. I'm running 6.2.2 beta - same problem with 6.2.1
I realize ny report above is incomplete. By can't play, I mean that it appears to play, but there is no sound. The log shows continuous: 2006-01-28 13:16:13.8677 Metadata byte not read, trying again: Resource temporarily unavailable ... 9 more times 2006-01-28 13:16:13.8713 metadata size: 0 ...
Marc: please open a new bug with the URL for that station attached. This is a separate bug.
Big chunks of this have been implemented. I have decreased the severity slightly.
This bug is a bit of a mess. Please open separate bugs for the formats that you care about.