PDA

View Full Version : OGG VORBIS Support in Firmware



Gerald B. Cox
2005-03-16, 13:45
I have submitted an enhancement request (BUG 1061). I also agree with the other
poster that it is a waste of resources. SLIMDEVICES is hoping that the extra
buffer and the bandwidth compression of FLAC will be a reasonable stopgap
measure. It definitely will be an improvement over WAV and SB1, but no way is
it as good as the actual ogg support in firmware.

Quoting Jason <jason (AT) pagefamily (DOT) net>:

>
>> So by streaming oggs as lossless, you use more resources and
>> do not gain anything.
>> If all your network/computer do is squeezebox - BFD.
>> But Linux users tend to have a lot more going on, and also
>> often tend to use older computers as headless boxes for
>> things like slimserver - where the cpu load will make a
>> difference (especially if same box is being used for DNS and
>> mail and ... as well)
>>
>>
>
> You should file this as a bug/enhancement request and then you can petition
> all of your friends to vote on it to see if it can be implemented.
>
> However, as many have told you, the CPU requirements of transcoding are
> minimal and transcoding to a lossless format for delivery is an excellent
> solution for most users.
>
> Those who might panic over a small additional overhead on the cpu when
> playing music (remember that a cheap 1ghz Celeron box can easily support 6-8
> players even WITH transcoding) or a small additional load on the network and
> who refuse to transcode their music might best look elsewhere for a music
> solution. It took Slim a very long time to add native FLAC support to SB
> (and actually had to come out with SB2 to do it) so I wouldn't hold my
> breath on the addition of another native codec.
>
>

Steven Spies
2005-03-16, 16:09
As long as we are asking for Ogg Vorbis support in firmware we should
also ask for ReplayGain support for Ogg Vorbis in firmware as well.
Should that be a separate enhancement request or should it just be
added to bug 1061?


On Wed, 16 Mar 2005 12:45:22 -0800, Gerald B. Cox <gbcox (AT) bzb (DOT) us> wrote:
> I have submitted an enhancement request (BUG 1061). I also agree with the other
> poster that it is a waste of resources. SLIMDEVICES is hoping that the extra
> buffer and the bandwidth compression of FLAC will be a reasonable stopgap
> measure. It definitely will be an improvement over WAV and SB1, but no way is
> it as good as the actual ogg support in firmware.
>
> Quoting Jason <jason (AT) pagefamily (DOT) net>:
>
> >
> >> So by streaming oggs as lossless, you use more resources and
> >> do not gain anything.
> >> If all your network/computer do is squeezebox - BFD.
> >> But Linux users tend to have a lot more going on, and also
> >> often tend to use older computers as headless boxes for
> >> things like slimserver - where the cpu load will make a
> >> difference (especially if same box is being used for DNS and
> >> mail and ... as well)
> >>
> >>
> >
> > You should file this as a bug/enhancement request and then you can petition
> > all of your friends to vote on it to see if it can be implemented.
> >
> > However, as many have told you, the CPU requirements of transcoding are
> > minimal and transcoding to a lossless format for delivery is an excellent
> > solution for most users.
> >
> > Those who might panic over a small additional overhead on the cpu when
> > playing music (remember that a cheap 1ghz Celeron box can easily support 6-8
> > players even WITH transcoding) or a small additional load on the network and
> > who refuse to transcode their music might best look elsewhere for a music
> > solution. It took Slim a very long time to add native FLAC support to SB
> > (and actually had to come out with SB2 to do it) so I wouldn't hold my
> > breath on the addition of another native codec.
> >
> >

Gerald B. Cox
2005-03-16, 16:22
I don't know much about ReplayGain, but it appears that it isn't limited to
ogg,
that it can be used with MP3, FLAC, etc. If that is the case, it should be a
separate request.




Quoting Steven Spies <sspies (AT) gmail (DOT) com>:

> As long as we are asking for Ogg Vorbis support in firmware we should
> also ask for ReplayGain support for Ogg Vorbis in firmware as well.
> Should that be a separate enhancement request or should it just be
> added to bug 1061?
>
>
> On Wed, 16 Mar 2005 12:45:22 -0800, Gerald B. Cox <gbcox (AT) bzb (DOT) us> wrote:
>> I have submitted an enhancement request (BUG 1061). I also agree
>> with the other
>> poster that it is a waste of resources. SLIMDEVICES is hoping that
>> the extra
>> buffer and the bandwidth compression of FLAC will be a reasonable stopgap
>> measure. It definitely will be an improvement over WAV and SB1, but
>> no way is
>> it as good as the actual ogg support in firmware.
>>
>> Quoting Jason <jason (AT) pagefamily (DOT) net>:
>>
>> >
>> >> So by streaming oggs as lossless, you use more resources and
>> >> do not gain anything.
>> >> If all your network/computer do is squeezebox - BFD.
>> >> But Linux users tend to have a lot more going on, and also
>> >> often tend to use older computers as headless boxes for
>> >> things like slimserver - where the cpu load will make a
>> >> difference (especially if same box is being used for DNS and
>> >> mail and ... as well)
>> >>
>> >>
>> >
>> > You should file this as a bug/enhancement request and then you can
>> petition
>> > all of your friends to vote on it to see if it can be implemented.
>> >
>> > However, as many have told you, the CPU requirements of transcoding are
>> > minimal and transcoding to a lossless format for delivery is an excellent
>> > solution for most users.
>> >
>> > Those who might panic over a small additional overhead on the cpu when
>> > playing music (remember that a cheap 1ghz Celeron box can easily
>> support 6-8
>> > players even WITH transcoding) or a small additional load on the
>> network and
>> > who refuse to transcode their music might best look elsewhere for a music
>> > solution. It took Slim a very long time to add native FLAC support to SB
>> > (and actually had to come out with SB2 to do it) so I wouldn't hold my
>> > breath on the addition of another native codec.
>> >
>> >

Stuart
2005-03-17, 05:14
With all this talk of codacs in the firmware, I was wondering about
mp3's. Is this done on SB2 in the hardware? I started using MAD
http://www.underbit.com/products/mad/ on my SB1, do decode mp2's. My
'broadcast' mp2 files sound choppy if sent directly to SB1.

MAD also has 24-bit output... has the mp3 decoder in SB2?

Stuart.

Gerald B. Cox
2005-03-17, 05:44
Yes, SB1 & SB2 have firmware support for MP3 and they use the MAD BTW.

Quoting Stuart <stuart (AT) stu (DOT) org.uk>:

> With all this talk of codacs in the firmware, I was wondering about
> mp3's. Is this done on SB2 in the hardware? I started using MAD
> http://www.underbit.com/products/mad/ on my SB1, do decode mp2's. My
> 'broadcast' mp2 files sound choppy if sent directly to SB1.
>
> MAD also has 24-bit output... has the mp3 decoder in SB2?
>
> Stuart.
>

Stuart
2005-03-17, 06:04
Gerald B. Cox wrote:
> Yes, SB1 & SB2 have firmware support for MP3 and they use the MAD BTW.

They use MAD already? MAD seems to play my broadcast mp2's ok, yet if i
stream them directly to my SB1, it's all choppy. Some decoders have a
problem with broadcast mp2's. I always thought SB1 had hardware
decoding (i.e. it was done on a dedicated chip).

S.

rtitmuss
2005-03-17, 06:39
Stuart wrote:

> Gerald B. Cox wrote:
>
>> Yes, SB1 & SB2 have firmware support for MP3 and they use the MAD BTW.
>
>
> They use MAD already? MAD seems to play my broadcast mp2's ok, yet if
> i stream them directly to my SB1, it's all choppy. Some decoders have
> a problem with broadcast mp2's. I always thought SB1 had hardware
> decoding (i.e. it was done on a dedicated chip).

Yes, SB1 does the mp3 decoding in hardware. The mp3 decoding in the SB2
is based on MAD, and is performed in a programmable DSP. See Sean's post
: http://forums.slimdevices.com/gforum.cgi?post=35109

Regards,
Richard

seanadams
2005-03-17, 08:02
Stuart,

Squeezebox2 firmware uses MAD with 24-bit output. MAD is widely
regarded as the most compatible and most accurate decoder.

Squeezebox1 uses a "hardware" Micronas DSP with 20-bit output. I
believe their code is based on the original Fraunhofer reference. It
has been a very widely used implementation.


So, both SB1 and SB2 have really good compatibility as far as mp3 goes.
For mp2 and some of the more obscure configurations of
bitrate/channels/samplerate/etc, there may be a couple things SB1 can't
do that we will be able to on SB2.

The most important mp2/3-related one I can think of OTOH is that we now
resample 22.05KHz streams to 44.1KHz at the output, so it can play over
s/pdif. Seems like a minor thing but it caused a lot of confusion.


On Mar 17, 2005, at 4:14 AM, Stuart wrote:

> With all this talk of codacs in the firmware, I was wondering about
> mp3's. Is this done on SB2 in the hardware? I started using MAD
> http://www.underbit.com/products/mad/ on my SB1, do decode mp2's. My
> 'broadcast' mp2 files sound choppy if sent directly to SB1.
>
> MAD also has 24-bit output... has the mp3 decoder in SB2?
>
> Stuart.
>