Pitch shifting when streaming internet radio

[Pettax]

Since upgrading to 7.5.1 the audio signal is pitch shifted down on my SqueezeBoxes when streaming internet radio. I don't know it is on all sources or just some. It is the case though for the station streaming at the link below (AAC).

http://sverigesradio.se/topsy/direkt/132-hi-aac.pls

When I stream from this link in ITunes on my computer is sounds just fine but in my squeezeboxes the audio is pitched down (with preserved speed). It is just a slight pitch down. Enough though to make the people speaking on this channel sounding like they are having a cold. It is obviously most apparent when playing music. Playing ALAC encoded music from my library works fine though. Below is another link with the same issue with some more music.

http://sverigesradio.se/topsy/direkt/164-hi-aac.pls

I run the SqueezeBox server on a ReadyNAS Duo.

Anybody got a clue?

[Pettax]

I can add that playing AAC encoded music from my music library works fine so it is not a general AAC transcoding issue. Something misinterpreted for these particular internet radio streams?

[bpa]

What sort of player are you using ? Radio & Touch play AAC natively but Boom, Classic, Receiver and Transporter needs transcoding by server.

Generally 128kbps and less internet Radio uses AACplus which has some audio and psycho acoustic additions so comparing files and stream may not be valid.

Can you try the following and see if any have the problem.

32kbit/sec
AACplus - http://www.somafm.com/illstreet32.pls
WMA - http://www.somafm.com/illstreet.asx

128kbit.sec - AAC stream
AAC - http://www.somafm.com/illstreet130.pls

[Pettax]

What sort of player are you using ? Radio & Touch play AAC natively but Boom, Classic, Receiver and Transporter needs transcoding by server.

Generally 128kbps and less internet Radio uses AACplus which has some audio and psycho acoustic additions so comparing files and stream may not be valid.

Can you try the following and see if any have the problem.

32kbit/sec
AACplus - http://www.somafm.com/illstreet32.pls
WMA - http://www.somafm.com/illstreet.asx

128kbit.sec - AAC stream
AAC - http://www.somafm.com/illstreet130.pls

Hi,

I use one Boom and two Classics so the server (ReadyNAS Duo) does the transcoding. The results of the test you asked me to carry out are the following:

AACplus: This stream plays significantly faster in speed on my Boom compared to when using iTunes. This is not the same issue as I reported where the speed was preserved but the pitch was changed (lowered).

WMA and AAC: Both these links sounds the same on my Boom and on iTunes.

The links I included in my original post all uses 192 kbps.

Thankful for all help I can get on this one!

[bpa]

Since you have a Boom and Classics then your ReadyNAS does the transcoding. IIRC the transcoding application for ReadyNas Duo is different than for other installations such as Windows, Linux and OSX because of the processor (it had to be optimised to be able to play streams).

You should open a bug report as I think your problem only affect ReadyNAS Duo users with non Radio and Touch players.

I suspect the problem might be associated with your streams as they are 48kHz whereas most internet streams are 44.1kHz.

[andyg]

On Jul 15, 2010, at 10:23 AM, bpa wrote:

>
> Since you have a Boom and Classics then your ReadyNAS does the
> transcoding. IIRC the transcoding application for ReadyNas Duo is
> different than for other installations such as Windows, Linux and OSX
> because of the processor (it had to be optimised to be able to play
> streams).
>
> You should open a bug report as I think your problem only affect
> ReadyNAS Duo users with non Radio and Touch players.
>
> I suspect the problem might be associated with your streams as they are
> 48kHz whereas most internet streams are 44.1kHz.

Note that in 7.5.1 ReadyNAS also uses faad.

[bpa]

The symptoms are not consistent.

1. Speed change might be explained by 44.1/48 especially as the AACplus SomaFM stream is in fact a 32kHz sample rate - chosen to exaggerate speed changes more than a 48kHz stream.

2. A pitch change would indicate that audio sample are being correctly decoded but somehow incorrectly calculated. Could this be some sort of floating point / fixed point issues as I think the Readynas Duo does not have a FPU so fixed point arith is probably used ? I don't think so as fixed point builds are also used for the ARM processors but would need to test stream on ARM to be sure.

Is it possible that what OP described as pitch change is in fact a speed change of a 48kHz stream being played at 44.1kHz

[Pettax]

The symptoms are not consistent.
Is it possible that what OP described as pitch change is in fact a speed change of a 48kHz stream being played at 44.1kHz

I am almost 100% sure that the issue I originally described is only a pitch change and not a speed change. On the other hand I have a hard time understanding how a pitch change can occur without being deliberate. Unfortunately I'm away from home for a week but when I return I can reply to this thread to definitely out rule a speed change.

Then again, I cannot understand how a speed change (as in the AACPlus case) can occur either without causing a buffer underrun or something.

The change in pitch could maybe find it's explanation in the 48 kHz / 44.1 kHz relationship. It is only a wild guess since I'm not comfortable with the digital theory behind it all but the pitch change could very well be something like 10% (down).

I might add that I switched directly from 7.4.2 to the official 7.5.1 where the new faad were added. I'm almost 100% sure that this issue were not present in the 7.4.2 release. This would maybe point to the new (optimized) sparc faad binary? Or maybe a wrong interpretation of a header or envelope or something in surrounding code?

[bpa]

I am almost 100% sure that the issue I originally described is only a pitch change and not a speed change.

What measurement did you make to ensure it was not a speed change. The
easiest one with stream is to listen to a program of known length and time it. A 60 minutes 48kHz program played back at 44.1kHz will play for about 65mins.

Then again, I cannot understand how a speed change (as in the AACPlus case) can occur either without causing a buffer underrun or something.

You would get underrun only if you tried to play a 44.1kHz program at 48Khz but you do not get underrun if you play a 48kHz program at 44.1kHz.

The change in pitch could maybe find it's explanation in the 48 kHz / 44.1 kHz relationship. It is only a wild guess since I'm not comfortable with the digital theory behind it all but the pitch change could very well be something like 10% (down).

Nothing to do with digital theory. With a 48kHz stream audio - 48000 sample is needed to play 1 sec of audio. If you play it back as a 44.1kHz stream then only 44100 samples will be used for one sec and so audio will be lower in pitch as it is being played back slower.

I might add that I switched directly from 7.4.2 to the official 7.5.1 where the new faad were added. I'm almost 100% sure that this issue were not present in the 7.4.2 release. This would maybe point to the new (optimized) sparc faad binary? Or maybe a wrong interpretation of a header or envelope or something in surrounding code?

It is better to first characterise the problem properly i.e. determine whether it is a 44.1/48 issue or not. If not then an accurate measure of the pitch change or reproducing the problem on another platform would help determine the source.

[Pettax]

What measurement did you make to ensure it was not a speed change. The
easiest one with stream is to listen to a program of known length and time it. A 60 minutes 48kHz program played back at 44.1kHz will play for about 65mins.

I did not use any scientific method. It just sounded like a pitch change only. When I am back home I'll time the length of a program.

It is better to first characterise the problem properly i.e. determine whether it is a 44.1/48 issue or not. If not then an accurate measure of the pitch change or reproducing the problem on another platform would help determine the source.

Ok, I'll get back in a week when I have access to my Squeezeboxes again.

Thanks!