Resampling Frequency

[Mike Duckett]

I have some MP3s that are encoded at 22.05khz (audiobooks). These MP3's do
not play over the digital ouput on the squeezebox. Attached is a real simple
patch to allow slimserver to "upsample" these particular MP3 when I decide to
play them. It works real well, I can play the MP3s without having to
manually resample the file.

Let me know if there is any interest in the idea, and maybe I can clean it up
to be more generic and fit in the covert.conf semantic.

Also I noticed that MP3::Info::samplerate may not be correct. I made a slight
change to it to have it return the sample rate from the CPAN::MP3::Info
object. Patch also included.

-Mike

[dean]

Hi Mike,

Interesting patch. I'd rather not hardcode command lines into the code
if possible, but I can't think of a clean way to add it to the
convert.conf file.

here's a crazy idea... I wonder if we should change the convert.conf
file format to use the template toolkit framework. That way we could
do lots more complicated rules in there and not have to keep updating
the parser. One of the rules could be about sample rates.

Thoughts anyone?

Finally, the patch to Info.pm. That looks fine, as long as we remove
the old 'RATE' setting.

-dean

On Apr 12, 2004, at 3:56 PM, Mike Duckett wrote:

> I have some MP3s that are encoded at 22.05khz (audiobooks). These
> MP3's do
> not play over the digital ouput on the squeezebox. Attached is a real
> simple
> patch to allow slimserver to "upsample" these particular MP3 when I
> decide to
> play them. It works real well, I can play the MP3s without having to
> manually resample the file.
>
> Let me know if there is any interest in the idea, and maybe I can
> clean it up
> to be more generic and fit in the covert.conf semantic.
>
> Also I noticed that MP3::Info::samplerate may not be correct. I made
> a slight
> change to it to have it return the sample rate from the CPAN::MP3::Info
> object. Patch also included.
>
> -Mike
>
>
> <slim.patch>

[kdf]

Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:

> Hi Mike,
>
> Interesting patch. I'd rather not hardcode command lines into the code
> if possible, but I can't think of a clean way to add it to the
> convert.conf file.
>
> here's a crazy idea... I wonder if we should change the convert.conf
> file format to use the template toolkit framework. That way we could
> do lots more complicated rules in there and not have to keep updating
> the parser. One of the rules could be about sample rates.
>
> Thoughts anyone?

sounds like an excellent plan. since we're loading it, we might as well use it.
For the most part, users shoudln't have to edit the file directly so any
complexity will be mostly hidden as long as the web setup page for file types
can display the rules in a very clean table. This way, any number of rules can
be present by default, with alternative rules already listed, but disabled by
default. An example is the MOV transcoding could use mov123 by default, but the
rule to use faad2 for linux users could be present, but disabled.

This might also open us up for a way to choose the priority, as opposed to the
current hardcoded order of mp3, aiff, wav for wireless and aiff,wav,mp3 for
wired squeezebox. The last time I tried to get uncompressed output, aiff made
noise and disabling mp3 in order to get uncompressed on my wireless squeezebox
(which works just fine on my setup) meant I had to lose transcoding features for
my slimp3.

-kdf

[Andrew W. Donoho]

On Apr 12, 2004, at 18:40, kdf wrote:

> Quoting dean blackketter <dean (AT) slimdevices (DOT) com>:
>> here's a crazy idea... I wonder if we should change the convert.conf
>> file format to use the template toolkit framework. That way we could
>> do lots more complicated rules in there and not have to keep updating
>> the parser. One of the rules could be about sample rates.


OK

Whatever format/template you use it needs to allow choices based upon
platform, stream, transcode to wav/aiff/mp3/flac and target device.
Because of the limitation of the squeezebox to handle low sample rate
audio out of its digital ports, we also need to allow some transcoding
based upon internal characteristics of the file. (For example, I cannot
play my favorite radio station without adding an analogue cable because
the squeezebox doesn't play low sample rate MP3s.) Also, local
convert.conf files need to have precedence over the standard
convert.conf. In other words, let's try to move all of the assumptions
about the streams out of the code and into config files with the
ability for local overrides.

What can I do to help?

Andrew

____________________________________
Andrew W. Donoho
awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)