-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,
just my very own personal observation: mobile users around me use
headphones so stereo would probably be mandatory. I can't stand MP3
streams below 96kbps, they really sound too cheap to my ears, even in a
noisy environment and with a mobile player. If bandwidth availability is
an issue, 96kbps AAC might sound a bit better - Android handles both MP4
AAC and Ogg Vorbis, but I don't know if Vorbis sounds good at very low
bitrates.
If I may suggest, keep the best possible source at all times, up to par
with the expected CD quality for example - 44khz, 16bits (or even 24 if
your stream is pre-processed before transcoding.) For the same bandwidth
usage it will then sound much better when encoded in MP3 and AAC. At
least, I think most encoding algorithms deliver a better sound with such
parameters.

- -- 
best regards,

okay_awright
<okay_awright AT ddcr DOT biz>
[PGP key on request]

On 26/07/2011 12:47, Alain Bolli wrote:
> Great, now it works ! Thank you David.
> 
> A non technical question : what would you preconize for a stream for mobile
> : 32 or 64 kbits ? mono or stereo ?
> For the moment I have 32 kbits, samplerate 22050 and stereo.
> 
> Best,
> 
> Alain
> --
> http://www.netvibes.com/bolli#Contact
> 
> 
> 2011/7/26 David Baelde <[email protected]>
> 
>> Hi Alain,
>>
>> I'm really sorry, I didn't notice there was something else broken in
>> the example. The following works, with the use of mean() to convert
>> from stereo to mono:
>>
>> # First transcoder: MP3 32 kbps
>> output.icecast(
>>  %mp3(bitrate=32, samplerate=22050, stereo=false),
>>   mount="/your-stream-32.mp3",
>>   mean(input))
>> # Second transcoder : MP3 128 kbps
>> output.icecast(
>>  %mp3(bitrate=128),
>>   mount="/your-stream-128.mp3",
>>  input)
>>
>> This example dated back from long ago, before we switched to encoding
>> formats. This change introduced the %mp3(..) thing, but also made each
>> source have its own content type, stereo, mono, video, etc. The mono
>> output expects a mono source, so we have to explicitly do the
>> conversion. In that case, the conversion is simply done just before
>> the output, but in other cases it might be performed in other ways.
>>
>> I'll fix that on the website and repository...
>> --
>> David
>>
> 
> 
> 
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> 
> 
> 
> _______________________________________________
> Savonet-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/savonet-users


-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJOLqY4AAoJEN2X/7ng71pTOfMH/A9sxsrzGjnKkZDX1mQUXX7R
k8LQD22uSNrPRjfYNdVjLWfMkAaKirAZxQWcdJJPEb65AbnypnsHZWj/1FQyJRw3
C2lGi/VaD8mNQZT9MA0XDqK2G4w3Aik9qHjbfEuR7R1j6D9I2oy9DvZPna3gEjL8
pUWwzlXrW3NpoP/QfFYBMZqTCTZkqeenDn7wnrga4STDSRyRoZwlzYP2a8XHPe96
pJ7I1DstEm/qxQKcwWHWcac+Lvw5B5muei+4j26TppjSiYflnKve1kcvuRNSiBi9
TQogwZwh1ywNUHmwB+D9G6+XMi+sg0lbO3J24wA5/+YxcfMe8x0TOSdaO0/4bNU=
=xDCC
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
Savonet-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/savonet-users

Reply via email to