Re: DABsworth in disguise?

"James Cridland" <james.cridland@xxxxxxxxx> wrote in message
news:db57fb49-d626-4f8a-a338-c9e9adc44b2c@xxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jan 3, 7:34 pm, Richard Evans <rp.evans.nos...@xxxxxxxxxxxxx>
wrote:
Cridland claims that the reason for using only 96k, is not due to
cost,
but is due to reliability problems on crowded office networks.
Not that I agree with much of what Cridland says on this blog, I'm
more
inclined to think that he's keeping bit rates low to try to avoid
hurting DAB. Whatever the reason, BBC web streams bit rates are
being
kept low for a reason.

I'll try, for a little while, to engage in conversations here:
trying
to be as open as I can. I'll stop when I get personal abuse.

First, I genuinely want our radio services to sound the best they
can
on any platform. I'm not directly responsible for DAB, working
within
the Future Media area of the BBC, and during my 18 months with the
company I have not once had anyone wanting me to restrict quality on
any platform "to avoid hurting DAB". It's a good conspiracy theory,
but I've simply not heard it. It should be noted that on-demand
quality is already higher than DAB.


I can't be bothered repeating why I've come to the conclusion I have
(you know already anyway), so I'll just repeat that the only thing
that actually matters is what you actually deliver, and I'll make my
mind up off that. To my mind, there is no justifiable reason not to
use 128 kbps AAC for the live streams for the stereo stations (and 160
or 192 kbps AAC for Radio 3), because there are so many ways that you
could deliver 128 kbps AAC (see below for a list). So IMO you should
be rightly judged on whether you actually provide it or not.


The Flash player within iPlayer gives us buffering stats, and I've
seen some statistics for our 128k streams, which appear to give
unacceptably high buffering rates.


You say yourself below that the stats could be flawed, and the figures
you've told me definitely sound too high to me.

I've also said that you could find out where the specific problem
areas are by writing a few scripts analyzing the log files and using
info from the Quova Geo-location database that provides info about the
network the user is on from their IP address, and using the
samknows.com broadband database to figure out if home users receive
data via BT or via LLU.

IMO it would be easy to find where the problem areas are, and then you
can simply deliver higher bit rate streams to users who've got an IP
address prefix that doens't suffer from problems, and deliver a lower
bit rate to everyone else.

This is why I've found this issue so frustrating, because you always
make it sound like it has to be an all-or-nothing thing when it comes
to what bit rates you're going to use - e.g. if 128 kbps is buffering
for quite a few people then everybody has to receive a lower bit rate.
But why do you need to do that when you've got all this info at your
disposal and the system is basically programmable?

Incidentally, one thing you should do to improve the robustness of
on-demand streams is to increase the upper threshold buffer size with
dual-threshold buffering:

http://www.adobe.com/devnet/flashmediaserver/articles/fms_dual_buffering.html

You already seem to be using dual-threshold buffering, but when I did
some measurements a few weeks ago the amount of audio left in the
buffer when it was refilled was only 13 seconds. So why not use an
upper threshold buffer size of 1, 2, 3, 4 or 5 or however many
minutes' worth of audio? Because it's dual-threshold buffering,
setting teh upper threshold to a high level doesn't lead to any
additional delay in the time it takes before the audio starts playing
(that's the whole point of dual-threshold buffering).

It's basically a trade-off between how much audio data is wasted (i.e.
downloaded to the buffer but never listened to) and robustness, so if
you want to improve robustness it would be worth increasing the buffer
size.

If you did this so that the streams would ordinarily be *very* robust
(by ordinarily I mean when there's just normal bit rate fluctuations),
then if streams continued buffering this would also help to pinpoint
where there are serious problems, such as ISPs throttling iPlayer
on-demand traffic.


I don't want to give licence-fee
payers a poor service, so I'm keen to start at a bitrate that we are
more comfortable with, and then experiment and change accordingly.


You're nearly there, but you're just missing the magic words, which
are "we will seek to use 128 kbps as soon as I know it can be provided
reliably". If you had said that from the start then you wouldn't have
been criticised, but that's very different to what you've been saying
on the Radio Labs blog and in emails (or at least in emails from a few
months ago).

You know my opinion is that there is no justifiable reason not to use
128 kbps, because there's so many ways that you could provide it, such
as using low and high bit rate streams, using dyanmic streaming on
Flash Media Server 3.5 once it's been released, using automatic
bandwidth detection on Flash Media Server 3, which doesn't require the
wait for 3.5 to be released, or using people's IP addresses and the
Quova database and delivering higher bit rates to people who're on
ISPs / networks taht don't suffer from any problems. So it's not as if
your options are limited...


Therefore, I've requested that the Flash iPlayer has better
statistics-
gathering; the current stats are based on analysis that could be
flawed, and are not per-station. I've also got agreement that I will
be able to change one station's streams to allow us to experiment
with
different bitrates. This should start in late January, as we move
live
streaming, and on-demand, over to AACfamily streams.

It might be worthwhile mentioning that buffering statistics are not
available to those streaming in Windows/Real. I'm also unaware of
any
commercial radio colleagues who can give me their own buffering
stats;


GCap/Global already uses MS Intellistream though - which, as you know,
I think you should use for the WMA streams so that Wi-Fi connected
devices can receive 128 kbps streams.


and RAJAR's recent MIDAS research would appear to show that
commercial
radio is doing comparatively much worse online than off-air. I'm a
commercial radio man by trade, having spent 18 years working for
commercial stations; and this worries me.


I don't think that's down to buffering issues. I think it's far more
likely to be due to things like commercial radio stations' websites
tend to be crap, so people don't visit them much, whereas BBC radio
station websites are good quality and very busy - plus there's the
iPlayer effect since June, which the BBC will benefit from more than
commerical radio.

Also, some pretty big commercial radio stations are still offering
Internet streams at low quality, such as some Bauer and GMG stations,
which doesn't help, and lots of smaller commercial stations are using
ridiculously low quality streams, which seems to be because they don't
really understand what they're doing - and I've said that the likes of
the BBC and Global should pass on best practice information to these
broadcasters or your "agree on technology, compete on content" would
just be a hollow line.


I am criticised in some quarters internally for my wish to be open;
yet I believe that, while we'll doubtless disagree, it is better if
we
understand each others' position.


It is better that we understand each other's positions, you're right,
mainly because if you really haven't been opposed to providing higher
bit rates for the live streams it really has not come across that way.
So the only way to get the point across was to explain yourself
properly, and the Radio Labs blog isn't the best forum to do that on,
because you're (initially at least) addressing a much wider audience.

Ultimately though, all that matters is whether or not you deliver 128
kbps AAC and WMA - and how long it takes you to deliver it.




--
Steve - www.digitalradiotech.co.uk - Digital Radio News & Info

The adoption of DAB was the most incompetent technical
decision ever made in the history of UK broadcasting:
http://www.digitalradiotech.co.uk/dab/incompetent_adoption_of_dab.htm


.

Relevant Pages

  • Re: Is DAB worth saving?
    ... were at the BBC, Simon Nelson, was in control of them, which was why ... Steve -www.digitalradiotech.co.uk-Digital Radio News & Info ... It is a fact that the audio is received off-air via digital satellite prior ... Internet radio streams, and 2 very recent ad campaigns saying that 1Xtra and ...
    (alt.radio.digital)
  • Re: Told you Cridlands biased against Internet radio
    ... digital radio, because you never discuss it with anyone. ... the quality of a medium I spend a lot of time listening to. ... Cridland didn't want to deliver the live streams at high quailty. ...
    (alt.radio.digital)
  • Re: Phil Riley - investing in DAB was a mistake
    ... high quality, could you explain (and this is the 3rd of 4th time ... live or on-demand, and they'll change at least another two times ... (admitting to the intention to nobble the live streams once again) ... "The third thing to mention is that we are looking at live radio ...
    (alt.radio.digital)
  • Re: Phil Riley - investing in DAB was a mistake
    ... high quality, could you explain (and this is the 3rd of 4th time ... live or on-demand, and they'll change at least another two times ... (admitting to the intention to nobble the live streams once again) ... "The third thing to mention is that we are looking at live radio ...
    (alt.radio.digital)
  • Re: Phil Riley - investing in DAB was a mistake
    ... high quality, could you explain (and this is the 3rd of 4th time ... live or on-demand, and they'll change at least another two times ... (admitting to the intention to nobble the live streams once again) ... "The third thing to mention is that we are looking at live radio ...
    (alt.radio.digital)