Better audio for BBC Radio online

Great news! Just in time for Morrisey's Live Concert on Radio 2!

you probably know, but R1 live does not seem to be working.

@darrenj1 - this service is not supported 24/7; apologies if it continues to stay down tonight. You can, of course, stop being a labs tester in the meantime.

@andrewgeekuk - yay!

And this bit's moderately important: the diagnostic information that some of you have discovered is not guaranteed to be an accurate reflection of the actual stream you're listening to (in codec terms or bitrate terms) while this Labs test is ongoing.

James, the Flash plugin _is_ a piece of software. Whether you think it's easier to install, or avoids the Beeb having users deal with codecs is a completely different matter.

Give us a stream link, and I'm sure VLC, Totem and QuickTime users will be happy to play the AAC through their players.

And, for what it's worth, QuickTime has had AAC support since 2002[1]

[1]: https://en.wikipedia.org/wiki/Quicktime

@hadessuk - fair point. It's preinstalled on many things these days, but yes, I meant to say "additional" software.

The AACfamily stream (the diagnostic info doesn't distinguish between AAC and AAC+, and we'll use both in our trial) is produced specifically for Flash. In the meantime https://iplayerhelp.external.bbc.co.uk/help/finding_programmes/real_wma_streams will give you direct links for Real and Windows. I'd recommend the Windows streams: they sound better. We will add AACfamily streams when they're available for Totem/VLC/etc - right now, the streams are not compatible with these players.

VLC compatible streams would be nice. The flash player is good, but being 'open' gives the potential for loads of flexibility, and integration into things like XBMC/boxee.

Thank you for openning this up to users.

Listenning now and indeed the sound dosn't seem better even on my modest speakers.

Is it now worth getting better speakers for my PC now I wonder?

Cheers, daveac

@James Cridland,

You've reduced the bit rates of the on-demand radio streams, which means that you've deliberately degraded the audio quality compared to what it would have been if you'd have left the bit rates unchanged.

You're also using a bit rate of 96 kbps bit rate used for the live streams, which is lower than the 128 kbps used by a third of all UK commercial radio stations and by over 8,000 Internet radio stations on shoutcast.com.

Could you explain why you've chosen to effectively reduce the audio quality on both the live and the on-demand streams compared to if you hadn't limited the bit rates when the BBC is going to launch HD streams on the iPlayer later this year? You can hardly claim that the BBC needs to save bandwidth if you're going to launch HD streams, because the HD streams are going to use a bit rate level that's 40 times higher than the radio streams, and the iPlayer TV streams are already consuming over 8 times as much bandwidth as the radio streams.

The Internet radio streams do provide higher quality than DAB (although that was inevitable the day that you said you were going to use AAC/AAC+). But considering that the BBC was part of the Digital Radio Working Group (DRWG), whose recommendations for government were blatantly pro-DAB and anti-Internet radio, do you not think that the BBC deliberately limiting the audio quality on the Internet radio streams confirms that the BBC is biased towards DAB and biased against Internet radio?

Will the on-demand streams be there later today? None seem to have made it through yet this morning. Hope it's all working! I find iPlayer radio listen-again about 10x more useful than a normal radio.

All this talk of re-buffering - it's not _just_ due to bitrate, is it? The 128k on-demand streams never have a problem for me - whereas the 64kbps real audio streams often had issues here (and still do this morning, while the new 96k streams do not!).

So there's obviously other factors involved. I hope you'll give 128kbps AAC a go. Even on a monthly capped internet connection, I really don't care enough about my bandwidth to want you to reduce the audio quality for the sake of saving 128-96=32kbps!

Cheers,
David.

Great news but why did it take so long. I have been using AAC for years.

As for DAB well internet radio will slaugter it. Internet car radios are now becoming available.

I think that the BBC should start pushing for multicasting in place of unicast. This technology has been around for years and I understand that its just a case of geting the ISPs to switch it on as most professional routers support it. The BBC has been experimenting with multicast and it should save alot of bandwidth.

@trevorjharris - we've been involved in multicasting for a long while. https://bbc.kongjiang.org/www.bbc.co.uk/multicast/ is worth a look (it says we're not updating that website: the services are still on, and I've raised this as an issue.)

@2Bdecided - AACfamily listen-again streams are being produced, but only since 6pm last night. And yes, we'll be trialling a variety of bitrates.

James

Are there any plans for a live stream for iPod Touch and iPhone?

@Grasbak - my boss is recently quoted in an interview as saying "not yet".

You can use F-stream on an iPhone to access the live Windows Media stream.

Phazer

In the interests of openness - we're temporarily removing the AAC listen-again service for delivery reasons. You should notice nothing, though we'll be using MP3 once more for a short time.

Will I notice the difference on my Logitech Squeezebox Boom?

Hi

I am just curious if there is any plans to make this work on Blackberries?

Either natively through the built in media player or through a 3rd party application?

Thanks!

@StuMcBill - Can't really comment on other platforms; but these AAC streams are iPlayer only for now (since they require a Flash player to work).

Those of you who tried earlier will spot we're trying new bitrates on R2, R3 and R4; and I'm pleased to let you know that the on-demand services are now back as AACfamily on all UK-national services.

I'm now off to the London Twestival, where all this @nonsense actually means something! ;)

I think quite clearly this is the way to go.

128 AAC+ on listen live

128 AAC+ on Listen again

For all BBC National & Local radio stations with music or drama content.

Stations like 5 live are fine in good quality mono really,if the BBC want to save on costs. 32k Wma?

The difference between 96kbit/s wma & 96 aac+ to 128k MP3 or 128 aac+ is huge if you listen through a hi-fi system.

Radio 2 online has been worth tuning into today for the 1st time.
Previous best source was 192 MP2 on Sky channel 0102 via amp.

Anybody in the BBC know when installing real player is no longer a requirement to listen to Local BBC?
I uninstalled this player when flash was 1st used on BBC i player.
I look forward to hearing Tony Blackburn sunday show in high quality whenever I like.
I have no intention of reinstalling the real player at the current unacceptable quality. Sooner go without than ruin my amp!!!!!

Just been listening to Radio 4 on iplayer live. Noticed it is running at 128kbps AAC and it sounds very impressive! Nice sibilance at last!

Keep up the great work.

https://94.102.49.21:8000

Radio 1 is only available at 128 MP3 here above via shoutcast. why ?
would be useful to have song titles & Radio 2 via shoutcast as well

Radio 2 at 128 aac sounds v. good, Radio 4 better still! (I reckon these are almost as clear as D-Sat's 192 Mp2 stream)

Can you put 6 music at 128 too please so we can hear that? at 96 it doesn't sound so pleasing as R2 and I probably wouldn't want to listen for very long with it like this..

Thanks for your efforts!

@digitalradiotech - You obviously don't understand the fundamental differences between MP3 and AAC/AAC+, nor what JC meant by "During this time, we'll play with the bitrates, to see what effect that has". Try reading the post again without any of the red mist in your eyes..

I'm listening to 6music live at the moment and it sounds great - a real improvement over the Real and Windows streams. Rather than sniping at the BBC for daring to launching a 'beta' service that may not be quite right in the first instance (that's what the Labs thing is for), why not applaud them for making great steps in the right direction, which will only encourage them to experiment and engage more.

Just a quick report

Listening to Desert Island Discs - David Suchet at the moment.

Supposedly 128kbps AAC+ - very heavy compression artefacts on his voice.

Using good Sennheiser headphones and Creative Audigy soundcard

Quite disappointing?

Maybe it was recorded in some other format?

@hexenductionhour,

You seem to be ignoring what I wrote in the first sentence:

"degraded the audio quality compared to what it would have been if you'd have left the bit rates unchanged"

That's based on the following fundamental rule of perceptual audio coding:

"with all else being equal, a higher bit rate will always provide higher quality than a lower bit rate, and vice versa"

i.e. if they had just switched from MP3 to AAC and left the bit rates unchanged at 128 kbps, the quality would be higher than at 96 kbps.

I stand by that, and if they can use bit rates of 500 kbps, 800 kbps, 1.6 Mbps SD and 4 Mbps HD for the iPlayer TV streams (the last 2 are planned for this year) then they can obviously use 128 kbps AAC for all of the stereo Internet radio streams as well.

I think the BBC missed out on not employing Digitalradiotech,the passion to get the audio correct is not at the BBC. I just think they regard it as a least important aspect of the iplayer.

Further to my previous comment on Desert Island Discs.

I honestly believe that the source for this programme was of an inferior quality and I find programmes on Radios 2, 3 and 4 generally better than that.

However I do still notice that speech seems to have some very light sibilance associated with it whereas recorded music seems to be quite good.

Is there some difference in the way speech reaches the encoders?

On listen again it just says this>>? b00hbshp/ac/ak/

Why dont you give the bit rate? I know 96k is low and it might be embarrassing to list it but at least I get a reminder of how bad it is when tuned in and that it is not my equipment failing to deliver?

@digitalradiotech: Hm. You seem to be ignoring, deliberately, what the post says and that I reiterated for your benefit (I'll do it again, just in case you missed it):

"During this time, we'll play with the bitrates, to see what effect that has"

So it sounds to me like the bitrates you observe right now (and obviously care so deeply about improving, otherwise why would you spend your valuable time arguing on the internet about it?) are not set in stone, and will change in the future as the BBC monitors and tweaks the various variables.

Starting on the conservative side and then upping the bitrates gradually (and measuring the associated effects - buffering, etc) makes absolute sense from the point of view of deploying a brand new service. I am an IT manager myself, and have deployed large scale services on a beta, incremental basis and I know myself that this is a very sensible decision to make.

So, rather than biting their heads off at the first instance when the service doesn't match your own preconceptions of high standards, why not give the BBC a chance to evaluate and improve over time?

I'm listening to 6music @96kpbs again. It sounds a zillion times better than Realaudio. For that alone, I'm very grateful.

A welcome first step, but PLEASE, PLEASE, no lower than 128.

Firstly, anything less than 128 is way behind the curve of the quality of streams readily available elsewhere, from stations with a millionth of the budget, means, and public service remit of the BBC.

Secondly, to differentiate between stations exhibits a prejudice (Why is Radio 2 prioritised over Radio 1, for instance, via 96 and 128 streams respectively? And why is the human voice, the oldest and most complex "instrument" of all, discriminated against with a 64 Radio 5 stream? The logic behind these distinctions is flawed, at best, culturally prejudiced, at worst.)

Lastly, why no stream for the World Service??? Given that this station is not available on FM anywhere in the UK, it would seem like the ideal candidate for a high quality internet stream.

As of 12th Feb, two things seemd to have happened to me (using Real Player on a PPC Mac):-

1) All my Listen Again Favorites links have stopped working;

2) Alternative links (kindly provided by helpful souls) work for a short while and then break up into a crackling, squawking mess.

I prefer to use a standalone player because I do not always want to have a web browser open whilst I'm working on my computer.

It does appear to me that there is a just perceptible improvement in live streaming, but why the degradation in the Listen Again service ?

Does this development explain why .ra streams seem to be no longer available?

Perhaps it's just that such files are no longer required by BBC for any other purposes so transcoding has totally ceased and the timing is coincidental.

I have seen no mention made so don't know whether the current non-existence of such files is intentional or an oversight.

Any clues available?

@hexenductionhour,

"Hm. You seem to be ignoring, deliberately, what the post says"

No, you're referring to the live streams, whereas I'm referring to the on-demand streams.

Here's what James said:

"During this time, we'll play with the bitrates, to see what effect that has, as well as the embedded media player's code to make it more resilient of choppy network conditions. So don't worry if the audio quality goes down or up, or if it fails altogether - this is a test, after all."

The streams that are testing are the live streams - the AAC/AAC+ on-demand streams are already available to the public. My main issue was with the on-demand streams.

You say that:

"Starting on the conservative side and then upping the bitrates gradually (and measuring the associated effects - buffering, etc) makes absolute sense from the point of view of deploying a brand new service."

But they've been using 192 kbps MP3 for Radio 3 and 128 kbps MP3 for the other stereo stations' on-demand streams for the last 7 months, so they already knew that those bit rate levels worked, so there was no reason to reduce the bit rates.

They always intended - from about Feb last year - to reduce the bit rates when the streams switched from MP3 to AAC/AAC+, because they said that this was justified because the audio quality wouldn't be reduced. What I'm simply saying, is that if they just switched from MP3 to AAC/AAC+ and left the bit rates unchanged then the audio quality would be higher than if they reduced the bit rate levels. So they are effectively reducing the audio quality relative to what it would have been if they'd have left the bit rates unchanged.

They also tried to justify reducing the bit rates by claiming that using lower bit rates would lead to streams being more reliable. But the on-demand TV and radio streams use dual-threshold buffering (https://tinyurl.com/3yac4u%29, so I suggested that rather than reduce teh bit rate levels they should first use a very large buffer size (with dual-threshold buffering the upper threshold buffer size can be set arbitrarily large, and this has no effect whatsoever on the time it takes for the streams to start playing - because that's determined by the lower threshold level), because the probability of the on-demand streams buffering with a very large buffer size is practically zero - not that there was a problem with the reliability anyway, because if there was a problem they would have reduced the bit rates at some point over the last 7 months, which they haven't done.

I measured the buffer size being used for the on-demand streams after they'd reduced teh bit rates, and they haven't increased teh buffer size at all, so they've just reduced the bit rates without even testing the effect of using a large buffer size.

I don't have a problem with them being initially cautious with the *live* streams, because the live streams face different issues to the on-demand streams. But when I wrote my first post, they had already reduced the bit rates of the on-demand streams, which IMO was completely unjustified, and they hadn't yet started using 128 kbps AAC for any of the live test streams either, so it didn't exactly look like they wanted to use 128 kbps at the time. I'd be very happy to be proved wrong, but I will only be proved wrong if all of the live and on-demand stereo streams are at least 128 kbps AAC.

You say that:

"I'm listening to 6music @96kpbs again. It sounds a zillion times better than Realaudio. For that alone, I'm very grateful."

But the Real Player streams sound dire. At the end of the day, we pay for the BBC, so you have to ask why they're still delivering 64 kbps Real Player live streams to the public when GCap Media (now Global Radio) has been delivering 128 kbps WMA Internet streams for 2 years now? And the recent changes to the BBC's radio streams have been enabled by the new "Coyopa" encoders going live, but if you read this, https://tinyurl.com/c55ce8, "When we originally identified the requirements of Coyopa, approx 4 years ago" - why has it taken 4 years for these encoders to go from requirements capture to going ilve?? And why has the BBC been using the dire Real G2 codec when AAC/AAC+ has been available in Real Player since January 2004? Why has the BBC been transcoding the audio for the Internet streams for the last 6 years by receiving the radio stations off-air via satellite at Maidenhead when they could have spent a few thousand per year on a leased line to avoid transcoding - they spend about £10m per annum transmitting DAB, surely they could have spent a few thousand per annum to avoid seriously degrading the quality of the Internet streams? Even without a leased line being installed, why was teh audio for the on-demand streams transcoded anyway when the programme audio could have been chopped up at Broadcasting House then sent over the Internet to Maidenhead as files?

Basically, I'm not in the least bit grateful for them improving the quality, because this is literally years overdue - and even though it's years overdue they still seem to want to limit the quality!

Fantastic last post,Mr Cridland over to you?
After all you were delivering Higer streams for an ex employee of yours years ago.

@rangersman - I don't know why the EMP (embedded media player) doesn't give the bitrate for listen-again content. It -should- be mirroring the live services (128k vs 96k) but currently it's sticking at 96k.

@bloggblogg - We're testing different bitrates on different stations to enable a subjective comparison. We're not discriminating. Having said that, 5 Live is only sourced in mono, contribution circuits differ in audio quality, and also has regular high demand, so I'm certainly planning to leave it at a lower bitrate. We shouldn't be encoding it (as we currently are) in stereo. Again, it's a test. Finally, the World Service is not paid-for by the licence-fee (it's government funded) and thus is encoded differently according to their requirements.

@tsunami2 @society - we stopped using older listen-again formats at Christmas on the iPlayer, and finally stopped making the files last week, so old, non-official, links will now fail. Best way if you want to listen in a player, rather than a web browser, is... 1. Find the programme you want in the iPlayer; 2. Hit the "text version" link at the top of the page; 3. Hit the RealAudio and/or Windows Media link. We're working on a nicer way of doing this - but the iPlayer version should work much better for you anyway.

Finally, @digitalradiotech has sent a number of formal complaints to the BBC on this subject, so I'm unable to enter into public debate. Apologies.

https://bbc.kongjiang.org/www.bbc.co.uk/iplayer/episode/b00hbz7l/Aled_Jones_with_Good_Morning_Sunday_08_02_2009/

Well if you go on link above & then right click the mouse on Aled Jones it does not give the bit rate.

@James Cridland,

I have not made "a number of formal complaints" about this - I have made a single complaint about this issue. Are you trying to make me out to be someone who's unreasonable? I'm hardly being unreasonable considering that all I'm asking the BBC to do is to match what commercial radio has been providing for over 2 years now.

And you're not the only person who works on the BBC Internet radio streams, so perhaps John Ousby could respond to my comments in your place if you're unable to?

Introduction to Wi-Fi radios






BBC now testing AAC/AAC+ Internet radio streams at higher quality than DAB

13th February 2009

After a seven-month delay, the BBC has finally begun testing its live Internet radio streams using AAC/AAC+, and the BBC has launched AAC+ streams for the on-demand radio streams.

The on-demand streams are available to everyone, but the live test streams are only available to BBC iPlayer Labs testers, so if you want to listen to them you first need to go to the BBC iPlayer Labs sign-up page, then just click on the pink button that says "I want to be a Labs tester", then instead of the receiving the poxy Real Player streams you'll receive the new AAC/AAC+ streams.

The following table shows the bit rates and codecs the live test streams and the on-demand streams were using yesterday. Bear in mind that because the live streams are currently testing, the bit rates and which codec is used are likely to change over time. If you right-click on the Flash window it tells you what the bit rate and codec is, although it shows "aac" for both AAC and AAC+.



Station Live test streams
bit rate / codec Live streams links On-demand streams
bit rate / codec
Radio 1 96k AAC+ Listen 96k AAC+
Radio 2 128k AAC Listen 96k AAC+
Radio 3 128k AAC Listen 128k AAC
Radio 4 128k AAC Listen 96k AAC+
Radio 5 64k AAC+ Listen 64k AAC+
6 Music 96k AAC+ Listen 96k AAC+
Radio 7 96k AAC+ Listen 96k AAC+
1Xtra 96k AAC+ Listen 96k AAC+
Asian Network 96k AAC+ Listen 96k AAC+



The World Service is the only "national" BBC station that isn't using AAC/AAC+ yet, which is because of some arcane rule that stops the BBC from providing higher quality to listeners in the UK compared to what people around the world receive, but the World Service will also start using AAC+ within the next few months.

Higher quality than DAB
All of the BBC test live streams and on-demand streams are now at higher quality than on DAB. The reason why the Internet streams are at higher quality than on DAB is because they're using the AAC/AAC+ audio codec, which is twice as efficient as the MP2 codec used on DAB, so the following applies for the AAC/AAC+ bit rates being used at the moment:

128 kbps AAC provides the same level of audio quality as 256 kbps MP2 on DAB
96 kbps AAC+ provides the same level of audio quality as 192 kbps MP2 on DAB
64 kbps AAC+ provides the same level of audio quality as 128 kbps MP2 on DAB (this is for mono -- it's different for stereo)
The following table compares the audio quality on DAB with the equivalent MP2 bit rates used for the live Internet streams. As you can see, the equivalent MP2 bit rate that the live Internet radio streams are all higher than the actual MP2 bit rate used on DAB, so the audio quality of the Internet streams is also higher. In addition, the stations that are always or sometimes in mono on DAB (in the table, s = stereo, m = mono) are all in stereo on the Internet streams.

Station DAB
MP2 bit rate
kbps Live Internet test streams equivalent MP2 bit rate
kbps
Radio 1 128 s 192 s
Radio 2 128 s 256 s
Radio 3 192 s / 160 s1 256 s
Radio 4 128 s / 80 m1 256 s
Radio 5 80 m 128 m
6 Music 128 s 192 s
Radio 7 80 m 192 s
1Xtra 128 s 192 s
Asian Network 64 m 192 s



1 - Radio 3 is reduced to 160 kbps on DAB in the daytime when Radio 5 Sports Extra is on-air before 5pm, and Radio 4 is reduced to 80 kbps mono on DAB when Radio 5 Sports Extra is on-air after 5pm

BBC is testing 128 kbps AAC for the live streams
As the table at the top of the page shows, the BBC is testing 128 kbps for the live test streams for Radios 2, 3 and 4. If they use 128 kbps AAC once the live streams actually launch, that would obviously disprove my claim that they're trying to avoid using 128 kbps AAC! No-one likes to be wrong, but in this case I'd be very happy to be proved wrong.

However, they are only testing 128 kbps AAC at the moment, so it still remains to be seen whether they will use 128 kbps AAC for all of the live and on-demand stereo streams; and if they don't, I would be proved right.

BBC has reduced the bit rates of the on-demand streams
The BBC has been using 128 kbps MP3 and 192 kbps MP3 for the stereo on-demand radio streams since last June when radio was integrated into the BBC iPlayer, but the BBC has reduced the bit rate levels of the stereo on-demand streams from using 128 and 192 kbps MP2 to using 96 kbps AAC+!

The BBC has tried to justify doing this by saying that AAC+ is more efficient than MP3, so reducing the bit rates won't reduce the audio quality compared to what they've been providing with MP3. But looking at this from an alternative perspective, if they had just changed the streams from using MP3 to AAC/AAC+ and left the bit rate levels unchanged at 128 and 192 kbps, the audio quality would obviously have been higher than it is at 96 kbps. So the BBC has effectively deliberately reduced the audio quality compared to what it would have been if they hadn't reduced the bit rate levels.

My opinion on this is simple:

All BBC stereo Internet streams should use 128 kbps AAC
BBC iPlayer TV streams are consuming an enormous amount of bandwidth
The following figure shows how much bandwidth the BBC Internet radio streams and the BBC iPlayer TV streams have been consuming up to August last year. The iPlayer TV streams were already consuming over 7 times as much bandwidth as the Internet radio streams by August, which was just 8 months after the iPlayer TV streams had launched.







The second very steep jump in bandwidth for the iPlayer TV streams following a small dip in the summer was due to the launch of the higher quality 800 kbps H.264 iPlayer TV streams in August. The BBC is also planning on launching 1.6 Mbps SD and 4 Mbps HD iPlayer TV streams this year, which will lead to further massive increases in the bandwidth required, and that doesn't even take into account the exponentially increasing usage of the iPlayer, which also requires the bandwidth to increase exponentially.

The BBC also wants to make the iPlayer available on new Freeview and Freesat set-top boxes that have an Ethernet connection so that people can watch the iPlayer streams on their TV sets rather than on computers, which Anthony Rose, who's in charge of the BBC iPlayer, said could lead to the bandwidth required increasing ten-fold over the next year or two -- that would make the bandwidth for the iPlayer TV streams over 70 times higher than the BBC's radio streams were using last August.

I completely support the BBC launching new higher quality iPlayer TV streams, but it is hypocritical beyond belief to limit the bit rates to just 96 kbps for any of the stereo Internet radio streams -- especially in the same year that the BBC is planning on launching HD iPlayer TV streams that will use a bit rate that's 40 times higher than the 96 kbps that most of the radio streams are using!

All of the BBC's stereo Internet streams should use 128 kbps AAC without exception.



BBC on-demand streams can be made very reliable by using a very large buffer size
Both the TV and radio on-demand streams on the BBC iPlayer use what's called a 'dual-threshold' buffering scheme.

Dual-threshold buffering works as follows: When a user clicks play, the buffer size is set to be a small size (the lower threshold) so taht the stream starts playing quickly. Then once the stream has started playing, software increases the buffer size to the upper threshold value, and the server sends data to fill the buffer up, and the server continues to top the large buffer up as the stream continues playing.

The advantage of dual-threshold buffering is that the streams simultaneously begin playing very quickly and the streams can use an arbitrarily large buffer size. The advantage of using a very large buffer size is that the larger the buffer size is the lower the probability will be that the buffer will every empty, and buffering (i.e. the stream pausing) only happens when a buffer has run out of data.

In other words, the on-demand streams can be made arbitrarily reliable by using a very large buffer size. But this also means that the BBC cannot claim that it needs to reduce the bit rates of the on-demand streams due to reliability reasons, which the BBC has been using as a justification for limiting the bit rate levels of the Internet streams -- or at least the BBC was claiming this until earlier this week, but it seems to have quietly dropped this claim



BBC live streams will use 'automatic bandwidth detection' and 'dynamic streaming'
The iPlayer TV and radio streams are going to start using 'automatic bandwidth detection' in March (although given that the live streams were 7 months late in launching, this will probably be late as well), and they're going to start using 'dynamic streaming' by the summer, once the new Flash Media Server 3.5 has been released.

Automatic bandwidth detection: As its name suggests, this consists of a user's available bandwidth being automatically detected by the streaming servers -- it works in a similar way to how broadband speed tests do, where the user automatically downloads a file, and the time taken determines how fast the connection speed is to the streaming servers. The server will then deliver a higher bit rate stream to users that have a high enough bandwidth, and other users will receive a lower bit rate stream. The vast majority of users listening at home should receive the higher bit rate radio streams, though.

Dynamic streaming: This consists of the streaming server switching between lower and higher bit rate streams on-the-fly according to the speed of the connection from the user's computer or device to the streaming server -- the bandwidth can be determined by monitoring the level of data in the buffer, so for example if the buffer starts to empty quickly that means the connection speed to the server will have fallen, probably due to Internet congestion, and the server will switch to delivering a lower bit rate stream -- and vice versa for switching from lower to higher bit rate streams. Dynamic streaming also performs automatic bandwidth detection when a user first connects.

Switching between streams at different bit rate levels can be done without introducing a gap in playback between one stream finishing and the other stream starting (unless the buffer completely empties in the meantime, of course), but if the stream switches to a lower bit rate the audio quality would obviously be reduced.

For the vast majority of people who're listening at home, though, streams shouldn't need to reduce in bit rate level, because the Internet is sufficiently fast these days such that 128 kbps streams are basically small trickles of data in comparison to all the video streams that are being delivered -- the days when 128 kbps Internet radio streams were unreliable are long gone.

Microsoft has actually been offering its Intelligent Streaming (aka Intellistream) technology for years, which works identically to dynamic streaming on Flash, and the WMA streams for stations owned by the UK's largest commercial radio group, Global Radio, all use Intellistream.

As both automatic bandwidth detection and dynamic streaming are specifically designed to ensure that streams don't suffer from buffering, this means that the BBC cannot claim that reliability is an excuse not to use 128 kbps AAC for the live streams either.

Overall, then:

The BBC simply has no justification whatsoever to avoid using 128 kbps AAC for all of the live and on-demand stereo Internet radio streams.

Ignore my post #34. I found a clue (should have researched more before posting) and have now found the .ra files named according to the new conventions in the various coyopa hierarchies.

I use a Mac laptop with with an Airport Express broadband router, so my audio is deivered wirelessly and digitally from my laptop to my hi-fi. With this setup the quality of the new live audio streams is a welcome improvement over the previous live streams, and I think comparable if not better than current DAB broadcasts.

However, whilst I appreciate that this is just a test at this stage, why are Radio 1, 1Xtra and the Asian Network currently being streamed at a lower bit rate than the other music stations Radios 2 and 3?!

I can appreciate that with broadcast services such as DAB, the lower audiences for the 1Xtra and Asian services perhaps don't justify reserving the same bandwidth. But surely the reverse situation is true on the internet where the total bandwidth needed reduces with lower audience numbers? In any case, if the decision was based on audience numbers then Radio 1 bit rate should be higher than Radio 3.

Who makes these bit rate decisions, and why are they allowed to discriminate against listeners to these channels?

@ James Cridland

I'm trying to use a standalone player (Mac, Tiger, PPC) to avoid firing up a browser, so that I can Listen Again whilst dealing with email, writing articles and playing games.

Unless I misunderstand your proposal, it means that I have to fire up a browser to use iPlayer and find out a unique URL for each 'episode' of a programme - rather than using a Favorite/Bookmarks saved link for all 'episodes' in the player.

Not only is this inelegant, it doesn't solve the issue.

BTW, my iPlayer Radio Console doesn't have a 'text version' link at the top.


@ Society: Care to share ?

@tsunami2: I think James was referring to the main iPlayer episode page, rather than the console. For instance at the top left of here:

https://bbc.kongjiang.org/www.bbc.co.uk/iplayer/episode/b00hbbh3/Today_09_02_2009/

@andrew646 Thank you yet again. Unfortunately, following James' procedure on your link produces a Betsie Error Page :-(

For those who want to take advantage of andrew's useful advice, I'd suggest going to the iPlayer Messagebaord, where these issues are usually discussed:-

https://bbc.kongjiang.org/www.bbc.co.uk/dna/mbiplayer/

@pgrimshaw: "Who makes these bit rate decisions, and why are they allowed to discriminate against listeners to these channels?" I made the decision for this iPlayer test. I'm testing whether 128k causes more buffering than 96k, and whether the sound quality is noticeably better - so I've left some at 96k, and some at 128k, while I collect listening data. (In this way, it's easy to compare Radio2/6music, or Radio4/Radio7, which is similar audio from the same broadcast location). Apologies if you see this as discrimination; it's unavoidable to have a disparity while we run this test.

@tsunami: running Safari/Firefox as your 'player' will use just as much processor power as a standalone RealPlayer; indeed, one of my colleagues reports that on his Mac (Leopard, Intel) the flash player is using 5% of processor power as opposed to 45% processor power being used by RealPlayer. My Mac Mini (Tiger, PPC) has no problem using iPlayer while I do other things on it. I do agree that my solution is inelegant, though; we're looking at how we make it easier. iPlayer, as a mass-market consumer product, is unlikely to have any direct links to player URLs - but we wish to support internet media devices better, as well as those who for whatever reason wish to use a standalone player. I appreciate your comments.

@James

Will the listen again and live aac+ streams be available without the flash wrapper? If so can you share any info on accessing them or when this will be available.

(I see the mediaselector urls return multiple real entries for listen again to me - claiming 128kbit/s - I assume one of these may become aac?)

Why was this complaint ignored?

Complaint to BBC about the bit rate reduction on the on-demand Internet radio streams

15th February 2009

Below is a copy of the complaint I sent to the BBC about their decision to reduce the bit rate levels of the on-demand Internet radio streams. I sent the complaint to the BBC a few days before the new AAC/AAC+ on-demand streams launched (which is why the launch of the AAC+ streams is referred to in the future tense in the complaint) in the hope that they would see sense and choose not to reduce the bit rate levels. However, in its infinite wisdom the BBC chose to ignore my suggestions and reduced the bit rates anyway, so the BBC has chosen to reduce the audio quality relative to what it would have been if they'd have left the bit rates unchanged.

Incidentally, someone from the BBC has claimed elsewhere on the Internet that I've sent "numerous complaints" about this, which is incorrect, because this is the only formal complaint I've ever sent to the BBC about the Internet radio streams.



Summary of complaint
Full complaint
Reliability of streams
Bit rates & audio quality
Bandwidth
Distribution costs
BBC's bias towards DAB and against Internet radio


Summary of complaint
I would like to complain about the decision to reduce the bit rate levels of the on-demand radio streams when they switch from using MP3 to the AAC/AAC+ audio format.

The main justification that the BBC has put forward for why the bit rate levels should be reduced is that higher bit rate streams suffer from reliability problems. However, evidence strongly suggests that the reliability of the on-demand streams is fine at the bit rate levels they're currently using. Therefore, reducing the bit rate levels simply amounts to reducing the level of audio quality relative to what it would be if the bit rates were not reduced.

By reducing the bit rate levels to 96 kbps AAC+, the BBC would be reducing the audio quality to well below that provided by 128 kbps WMA, which around a third of all UK commercial radio stations use for their Internet streams. There are also over 8,000 Internet radio stations that are using 128 kbps streams or higher bit rate levels.

There are also compelling audio engineering reasons for why 128 kbps should be used for Internet radio streams, and the poor-sounding 96 kbps WMA live streams that the BBC launched a couple of months ago are a shining example of why 128 kbps should be used for Internet radio streams that carry stereo music, and not 96 kbps.

Because of the huge amount of bandwidth that the iPlayer TV streams are consuming, and the amount of money that the BBC spends transmitting DAB each year, not to mention the bandwidth the iPlayer TV streams are expected to consume in the near future and the £40m - £70m per annum that providing universal DAB coverage is estimated to cost, I find it extremely difficult to believe that the BBC needs to reduce the bit rate levels of the on-demand radio streams in order to save bandwidth or money.

The BBC is also planning on launching HDTV streams on the iPlayer this year. Such streams would use a bit rate level that is 30 - 40 times that of the radio streams, so the BBC would be practising double standards if it chose to limit the audio quality of the on-demand radio streams by reducing their bit rate levels. Combining this with the fact that there doesn't look to be any legitimate reason for why the bit rate levels need to be reduced, the only logical explanation I can think of is that the BBC plans to deliberately limit the audio quality because of its long-standing bias towards DAB and its bias against Internet radio.

I have previously suggested that the reliability of the on-demand streams can be improved by using a large buffer size, but my measurements show that the buffer size has not been increased. I would therefore reiterate that if you have any concerns about the reliability of the on-demand streams then you should increase the buffer size used. The buffer size can be set arbitrarily high for the on-demand streams, which would make the streams arbitrarily robust for everyone other than people suffering from major problems, in which case the streams would rebuffer no matter what bit rate were being used. There is especially no justification for reducing the bit rate levels without even bothering to see what the effect of using a large buffer size is on the buffering statistics.

Full complaint
My complaint relates to the intention to reduce the bit rate levels of the on-demand radio streams when the streams switch from using MP3 to AAC/AAC+.

The bit rate levels used at present with MP3 are as follows: Radio 3 uses 192 kbps, the other national stereo stations use 128 kbps, and the mono speech stations use 80 kbps. I believe that the 128 kbps MP3 streams are going to be reduced to 96 kbps AAC+, and Radio 3's streams will be reduced from 192 kbps MP3 to 128 kbps AAC.

I believe that the BBC's justification for reducing the bit rate levels is that the AAC/AAC+ audio codec is more efficient than MP3, so that the reduction in bit rate levels would not lead to a reduction in the level of audio quality.

However, if the bit rate levels were not reduced, the audio quality would be signfiicantly higher than it is now as a result of changing from MP3 to AAC. Therefore, unless there are any other factors that necessitate a reduction of the bit rate levels, doing so actually amounts to deliberately reducing the level of audio quality relative to what it would be if the bit rate levels were not reduced.

The only factors that I can think of that might influence any decision to reduce the bit rate levels are as follows, which are discussed in-turn below:

Reliability of streams

@Nick Reynolds,

"2. Are you and digitalradiotech one and the same person?"

Er, no.

The articles he's copied are from my website though:

https://www.digitalradiotech.co.uk/2009/02/bbc_test_aac+_streams_overtake_dab_quality.php

https://www.digitalradiotech.co.uk/2009/02/bbc_complaint_on-demand_radio_bitrates.php

I'd prefer it if he provided links to the articles as well, to be honest, so if you can replace the text in his very long replies with the URLs above that would make the blog a bit less messy.

BTW, I notice you've used a URL link anchor text rather than displaying the URL itself - how do you do that, please?

@ James

My experience is different from your colleagues: most of the time Firefox uses less processor power than Real Player (although it does switch - I'd say this is true 80% of the time). Firefox seems to use between 12 to 25% (without iPlayer running) whilst Real Player uses between 8 to 15%.

I'm guessing your colleague is using Real Player 11 for Mac, which caused me problems (see the iPlayer messageboard for details). My Firefox may also have more add-ons in operation than your colleagues.

Interestingly, Real Player uses noticeably more processing power for BBC feeds than for internet radio stations with 128 kbps feeds.

I'm not in love with Real Player (far from it) - any standalone player will do. There is also a difference with time taken to load between RP and Firefox, although with these new links RP is taking a long time to play them nowadays.

I discovered that my firewall is often using most processor power, which reminds me: why do BBC streams have different servers each time I choose a feed ? I give permanent permission for each one each time, but every time I go back to a feed it seems to be using a different one, which requires a new permission. Very annoying.

@ James,

I really pity you. The fact that some people can't understand "it's a test" is a bit worrying. Switch the streams on and off at random - that'll get the message through! ;)

However, you said "(In this way, it's easy to compare Radio2/6music, or Radio4/Radio7, which is similar audio from the same broadcast location)"

I wish it was that easy. Those pairs of stations have never sounded the same to my ears (whatever platform), even when playing identical content.

A simpler comparison to gauge 128k vs 96k would be helpful - e.g. two feeds of the same station, or two versions of one on-demand programme, one at 96k, the other at 128k. Then people can listen, and draw their own conclusions. You could even label them "A" and "B" rather than 96k and 128k and then find out if people can really hear a difference, or are just imagining it. It depends whether you really want to know what people really hear.

Cheers,
David.

Simple maths here

128-96 = 32 kbits

Extra quality nuff said!

I've been thoroughly enjoying the new AAC streams for the radio since the "upgrade", they really sound so much better I've finally managed to stop having to listen to Freeview Radio and now listen exclusively on iplayer!

But please increase the listen again streams to 128kbps. I can sort of understand the thinking in using lower bitrates for live streaming but not for listen again.

I just find it amazing that the audio on iplayer videos, such as "Bob the Builder" ;-) , is higher bitrate than any radio channel!

It's probably too complicated but perhaps a user could choose to have a higher quality feed for listen again radio (say 256kbps AAC), much as dial-up users can currently select a lower bitrate.

I got the impression that they're switching/trialling codecs. So the bitrate question is no longer as simple.

I'm no expert but even I've noticed that some better codecs or encoding techniques can provide an increase in perceived quality even at same/lower bitrates. And when you're serving audio data for high-usage streaming, I can understand wanting to find the optimum (not maximum) bitrate for enjoyable listening.

And from the sounds of it, they're currently testing things at the different bitrates to see if there is a difference and what it is.
Yes, it probably sucks if your choice of station is the one at the lower bitrate but it's probably the best way they have of currently comparing. Dual feeds for each station would be nice, but it's whether they have that as a viable option at the moment.

@TiggsPanther,

"And when you're serving audio data for high-usage streaming, I can understand wanting to find the optimum (not maximum) bitrate for enjoyable listening."

The BBC iPlayer TV streams were already using 7-8 times as much bandwidth as the BBC's radio streams last August, and that was just 8 months after the iPlayer TV streams had launched - within one month of them launching they'd already overtaken the radio streams in terms of how much bandwidth they were using.

There's also 1.6 Mbps SD and 4 Mbps HD iPlayer TV streams that are planned to be launched this year - 4 Mbps is 40 times higher than the 96 kbps bit rate used for the radio streams.

The BBC is also keen to allow people to watch iPlayer TV streams on their TV sets using forthcoming Freeview and Freesat set-top boxes that have an Ethernet port to allow connection to the Internet, and Anthony Rose has said that that could lead to the bandwidth for the iPlayer TV streams increasing ten-fold over the next year or two - that would take the iPlayer TV streams' bandwidth to about 70 - 80 times what the radio streams were using last August.

Internet bandwidth is basically dirt cheap these days, and in comparison to the bandwidth required for the iPlayer TV streams the amount required for the radio streams is tiny, so there's no justification to reduce the radio streams' bit rates in order to save bandwidth.

Can you explain the geographical restrictions applied to live streams - and how these will apply to the AAC streams?

In France, I can listen to any real audio stream, but not to R1-R4 wma streams. So, I can listen on computer using real player to anything. If I want to use windows media (which you suggest sounds better) I can only get Radios 5,6 7. My Roku player does most formats, but not ra, so I can't have Today in the mornings.

Seems very inconsistent. If you wanted to geo-lock, why only some stations in some formats?

Anyway, as a licence payer, shouldn't there be some easy way for me to listen to everything?

@squiditchy - thanks for the comments. The listen-again services are live for everyone, so I'm not playing with those until we've completed our tests. And being fair, the 96k AAC+ audio is exactly the same bitrate and codec as Bob the Builder as far as I'm aware... ;)

@TiggsPanther - we also need to take into account the fact that radio listeners are also using their bandwidth for other things while listening - unlike television.

@simonvfr - can't comment on international restrictions right now, but hopefully some news on the way shortly.

@James Cridland,

"we also need to take into account the fact that radio listeners are also using their bandwidth for other things while listening - unlike television"


The difference in bit rate level we're talking about here is 32 kbps. According to the Digital Britain report, 98% of broadband users have a connection speed of 1 Mbps or over.

If someone downloads a 200 KB web page, if the person was also listening to a 128k BBC radio stream it would take:

200k x 8 / (1000k - 128k) = 1.83 seconds to download

if the BBC radio stream were at 96k, it would take:

200k x 8 / (1000k - 96k) = 1.77 seconds to download

The difference is 0.06 seconds - and that's for people with very slow broadband.

Anyway, you've got the option of launching additional lower bit rate streams if you're concerned about this issue. It is not a justification to limit the bit rate levels, though.

If they can find a way to justify 96 poor kbits, they will implement it just to upset us all!!!!

I too would like to remind you that flash is a piece of software just as VLC and quicktime.

TBH I have no problem using flash, I would love to.. if it was supported on my device (Nokia N800)! As it is iplayer doesn't work at all.

I would at least like to listen to the live streams as I could with the Real Audio streams.

Just my 0.02 GBP thank you

@dogsbodyorg - you're welcome to use these links to listen using a suitable player on your Nokia N800.

@rangersman - I note your impassioned views on this subject. I am trying to do the best for our audience.

@ James - Will those streams still be available when the new streams you are working on come out of beta? If not, will links to direct stream URLs be made available for people who use devices which cannot support the iPlayer, and people who want to listen to the audio without having a web browser open?

Will the BBC's local radio stations use the new streaming format?

Earlier you described iPlayer as "a mass-market consumer product". I thought iPlayer was a public service? The way you described it makes it sound commercial to me.

@ James

I appreciate that you may not want to deal with the processor and server issues I raised in post 53 (most of my posts are about usability - which is disappointing in the iPlayer - rather than quality), but could you comment on the variability in volume of the 'coyopa' links ?

For example, the current Late Junction Listen Again feeds appear much quieter than other programmes. I can only listen to them (whether in RP or iPlayer) by having all volume settings at max.

On the 'quality' issue, I can begin to understand why a higher bitrate should provide more information (and higher volume in my experience), but does this necessarily equate to a better 'quality' of sound ?

Some 128kpbs streams to which I listen are harsh and have painful dynamics which restricts the length of time to which I can listen without feeling tired. I'm guessing this may be a similar issue to the switch to digital CDs from analogue vinyl: early examples of CD recordings had a hard harsh sound that began to disappear as engineers began to understand how to master such recordings.

Now you've launched AAC streams is there any news on the Windows Media Audio version of Listen Again programming that was supposed to be launching back in January? As I understand it one of the great benefits of Coyopa is that it's now relatively easy for you to transcode programming into pretty much any format you want to.

Also, on a geeky point, any reason why you're running all the AAC through Akamai, therefore making it pretty difficult to use the streams outside of iPlayer? It would be fantastic if you could expose individual URLs in the same way you do with the RealAudio version of programmes.

Great to hear that you will provide the AAC steams directly to play without the obnoxious flashplugin.

Looking forward to that day.

A thumbs up for the current settings according to my ears. I've had a brief spin through my usual stations and the result are excellent. In some cases I think the quality of my (not too bad) Logitech PC speakers is the limiting factor.

As background 4Mbps connection with a VM doing a 248Mb update and VPN to work going. No clever traffic shaping setup at this end.

During the test, only the VPN seemed to suffer becoming noticeably more sluggish on screen refresh, but otherwise streaming was "free".

I've only commented on stations I listen to regularly. I listen to a lot of radio on a combination of various Tivoli Model One's, a Tivoli Model DAB (in DAB for R7 / Jazz), so this is my comparison

R1 - 96k
Good quality, slightly brash on occasion, but a lot of guitars and CM can be an irritant. 5 sec of buffering at kickoff then perfectly stable

R2 -128k
Excellent mellifluous Wogan tones. A lot more detail in speech (including the odd atmospheric wheeze and creak). Very impressive.

R3
Failed to start. Stuck on initial buffering. Retried a few times but still no joy. I guess a reflection of the hunger for quality amongst the R3 audience (usually a Late Junction listener)

R4 - 128k
Desert Island Discs - a nice bit of opera, clear as a bell. Music seemd a bit quiet compare to subsequent discussion, but great quality. About 10 sec. buffering at startup then no problems

R5 - 64k
Nikcy Campbell phone in. Seems less sibilant at 64k than R1 at 96k. This could be because flipping between the scratchy caller and in-studio voice provided an easy contrast. For the 10 minutes I listened, not fatigueing (sp? maybe a vowel too many in there).

R7 - 96k
Presenters noticably more sibilant than other stations, event R5 at 64k? This didn't seen to affect Miss Marple, but did affect the talking head that followed. I listen to a lot of R7 via dab and the sound seemed richer but definitely more sibilant - I was quite aware of it in the end. Perhaps I need to tweak at the OC end.

All-in-all a great improvement.

I'd echo a request for direct live streams rather than having to use the player - which I actually rate but I want to transcode for my bedside Chumby.

Any way to directly access in mp3 without transcoding would be a bonus - even at lower quality and / or as an additional subscription would get my vote.

@James,

Your dynamic range compression shreds some kinds of music.

It's not a subtle "oh the loud parts aren't quite as loud as they should be" - it's a "it sounds like something is badly broken here".

The worst example I've heard is here:
https://bbc.kongjiang.org/www.bbc.co.uk/iplayer/episode/b00hjzr9/Nigel_Ogden_The_Organist_Entertains_17_02_2009/
Listen to 27:04. In fact, listen from 26:00 so you hear just how badly it goes wrong at 27:04 when the loud part kicks in.

You don't have to be some kind of obsessive audiophile to notice the problem here - this piece of music gets played at most weddings, so most people have heard it on a live church organ - sounding absolutely nothing like this!

There are plenty of similar examples across Radios 3 and 2 on non-pop music - the _very_ loudest parts crash against some kind of hard limiter, and get shredded.

Cheers,
David.

@tsunami2: missed a question from you earlier - "Why do BBC streams have different servers each time I choose a feed?" - for load-balancing reasons.

And to answer your later point: Radio 3 has a wider dynamic range than other services, hence why it subjectively appears to be quieter - we use less dynamic processing (which is possibly the 'painful dynamics' that you refer to for other services). We're using the least processed audio feed available to us for the Coyopa feeds - it's the version also available on Freeview if you're interested. FM is more processed, since it's also intended for mobile use. This is a rough précis, and my colleagues in Radio Resources (who actually know about these things) are welcome to add more detail. As a former radio presenter, I'd comment that some dynamic range compression is required for all radio output: otherwise it's very difficult to listen to.

@Greatest_Valentines_Day_Ever_2009: We certainly aim to publish direct streams for those that really want to use Windows/Real/etc. These won't be in the iPlayer, though. (And a "mass-market consumer product" isn't incompatible from "public service".)

@adancy - We're making Windows Media files now; the work to publish those is now ongoing, and apologies for the delay. Use of Akamai (or Level 3) doesn't preclude you from using these streams outside of iPlayer, but they're currently optimised for Flash delivery, which is why you can't play them in anything else. We are looking at what we're calling 'vanilla' AAC family streams for other devices.

@mrsean2k - thank you for the kind review. The initial buffering isn't good, and I'd like to ensure we manage to reduce this; and I'll ensure our team get to see your comments.

Finally, @2Bdecided - as noted above, we're simply using the feed with the least dynamic range compression. We apply no further compression specifically for online use. I'll ensure that your comments are seen by the appropriate people though.

@james

Aside from the apparently infinite buffering seen on R3, the rest of the buffering times didn't seem problematic to me, just making an observation.

@anyonewantingtocompare

If your bandwidth is decent, you can easily compare before / afters by running two instances of the popout radio player in Firefox (at least it was easy enough in FF3 / Ubuntu) and flipping between the labs setting between launches. Then just start / stop in turn. Takes a second or so each time.

There are drop outs in this one:

https://bbc.kongjiang.org/www.bbc.co.uk/iplayer/episode/b00hs6lj/Im_Sorry_I_Havent_A_Clue_26_02_2009/

e.g. at 05:59. There are lots throughout the whole programme - nothing to do with buffering, connections etc - they're on the iPlayer recording, in exactly the same place if re-played.

The programme will probably have expired by the time anyone read this ;)

Cheers,
David.

Finally I got around to connecting my Laptop to my hi-fi system, so that I can try out the aac/aac+ streams.

I thought Radio 2 sounded very good (as I would have expected at 128k). Hi-fi quality digital radio at last :-) . Some of the tracks played were tracks that I also have on CD, so I could tell that the 128k stream didn’t seem to sound quite as good as CD. However there wasn’t that much difference, and part of the difference may have been to do with different DACs. I’m used to listening to CDs on my Squeezebox, but of course for the flash based streams, I had to make do with the relatively low quality DAC on my laptop.

I thought I ought to also try the 96k streams, and listened quite a lot to Radio 1 and 6 music. I found the results rather variable.

Radio 1 sounded poor most of the time, sometimes being pretty awful. I suspect that has a lot to do with the content being played being difficult to encode. However when the news was on this afternoon, containing only speech the top end sounded strange, probably SBR artefacts. Occasional tracks sound good, but over all I’m not impressed with Radio 1.

I thought 6 music sounded a lot better than Radio 1. I thought it sounded good about 80% of the time. However on some tracks that peculiar sound at the top end was creeping in again. There were a few tracks that sounded awful.

As far as re-buffering problems. Errr what re-buffering problems. Not a single re-buffering event. Looks like my 5 meg broadband connection is able to handle 96k and 128k ;-) .

Well so far my opinion has hardly changed. 96k sounds worse than I would have expected, the SBR atrefacts seem to be more of a problem than I would have expected. I think that if you must use 96k, it would be better to use aac and not aac+. The difference in sound quality between 96k and 128k is substantial and I find it hard to understand why we would have to put up with sound quality being so much lower than it could be, just for the sake of an extra 32k.

I also hope it doesn’t take too long for the vanilla aac streams to come on line, as it would make life so much easier if I were able to play the streams on my Squeezebox (using Mplayer).

As I write this 6 Music are playing Open Your Heart by The Human League, and it sounds dreadful. I think it is the dynamic range compression that is spoiling it.

Currewntly AUtoUpdate has no plug0in avilable to play your selection.

Also more info button seems to do nothign as well. So not a lot of use

@RichardEvans67 - thanks for your comments. Radio 1 has moved to 128k from Monday; so take another listen. (The dynamic compression is outside my control, it should be said).

@SyliaBristol - this sounds like a RealPlayer error message, and one I don't really understand. Assuming you're in the UK, could you ensure that "modem version" is off, and that you've checked into iPlayer Labs?

Now listening to Late Junction (Radio 3) from Thursday and it's sounding VERY good. Have you increased the bitrate on R3 AAC? It sounds noticeably better than before - very impressed!

Thanks

Phil

I just tried to have a listen to the Radio 1 stream, and wondered why it sounded so muffled. Then I realised that at the moment I'm only getting the 64k Real Player stream. :-(

I haven't got around to listening to the Radio 1 128k stream very much, due to the inconvenience of having to plug my Laptop into my hi-fi, and also due to an interference problem I have been getting recently when I do that. I do hope it is not too long before the so called vanilla aac streams come on line, as it would be so much easier to be able to listen on my Squeezebox.

From what I have managed to hear of the 128k Radio 1 stream, it does seem encouraging. However I haven't had time for a proper listen until today, and today I can't access the stream. I'd also like to mention that I haven't had any re buffering problems with the 128k stream.

I've been using the AAC+ streams, largely without problems, for the last three months.

For me they are pretty good.

The problem of Optimod type compression of the audio before encoding, although it exists, is not of such significance on the channels to which I listen. The principle in general seems to be patronising as it assumes that the listener is incapable of making any necessary adjustment. Not everyone listens in their car or on an IPod.

One minor issue I do have have is that the AAC+ Flash streams always start in the main web page, but when I try to use the pop-out player it mostly refuses to start and calls for me to install Real Player. I'm using Ubuntu 9.04 and Firefox 3.0.10.

Finally, as this post is now three months old - is there any news on the "vanilla" AAC+ streams as I would dearly love to use my Squeezebox to play them on my hifi. Perhaps these "vanilla" streams could be free of Optimod type compression as they are destined for higher quality listening equipment - at least to some part.

Sorry

I meant to say AAC family streams in previous post - I know that not all of them are AAC+.

I notice that BBC Radio 3 is now 192kbpS in AAC on iPlayer and all other main stations are now 128kbpS.

World Service starts eventually in my iPlayer but without a "properties" bar to verify the streaming rate.

A WS flash player starts if you launch from the stations home page at 64kbpS -no need to sign up to be a labs tester.

Haven't yet found any local radio in flash player but haven't checked many.

Is anybody still reading this?

Is this information being posted elsewhere?

Vanilla Streams?

How about an update?

I notice that now nearly all the test streams are at 128k. I tried out 6 music a few days ago and it did sound very good. Not all streams sound good all the time, a few previous times I found sound quality to be a bit poor, especially on Radio 1. I strongly suspect however that this has more to do with what goes into the encoders. On Radio 1 I think it is mostly the dynamic compression that spoils it. The 128k encoding however does seem to be working very well, and sounds very good when the content allows it to.

My only problem now is not being able to play the streams on my Squeezeboxes. Any hints about when the vanilla aac streams will be available?

Also I can't help wondering how long are the 128k streams going to stay as test streams. Unless there are problems still to be ironed out, then why can't everybody benefit from the improved sound quality?

Richard.

Can James or anyone else comment on whether these changes will impact the ability of my Sonos system to play both live radio streams and listen again content? Better quality will be great but I'd hate to lose access totally.

Also as an early (for the UK) adopter of the Chumby - what's the outlook for getting BBC radio on that device? I understand it doesn't have aac codecs (and doesn't work with wma or real either - mp3 only I think...) They're now available in the UK and would be a great little device if it wasn't for the inability to get the BBC.

P

I see that the BBC R3 live stream for music is labelled 192 | aac | LI on the iPlayer bar, while the same item on demand is labelled b001xqq1 | aac | LI. What is the difference here? Also it's good to see that the streams have a frequency range up to 22kHz, which I think is essential to get audio quality anywhere near CD quality, unlike the broadcast 192 kbps mp2, which is lowpassed at 15kHz (as FM transmissions have always been). However, it's disappointing to see that music transmissions from the Proms are low passed at 15kHz on aac. Why is this?