World Service podcast bit rates

Tue Aug 15 18:58:21 PDT 2017

 On Tue Aug 15 12:40:54 BST 2017, RS wrote:

> were limited to dafmed, hafmed and hlsaacmed
> and a bit rate of 96kbit/s.

 As a general rule, BBC World Service Radio does not impose
any form of geo-filtering; in fact, for all "broadcast versions" of
its content (not podcast vPIDs), i.e. the ones available as A-O-D
streams on iPlayer Radio, they're employing the same set of streams
worldwide (as opposed to a UK and an overseas set...).

 In the not so distant past, the chosen bitrate for WS Radio
(both for live and OD) was set at HE-AACv1 at 64kbps/44.1kHz
(and until the end of 2015 there existed live streams in the
form of WMA9 at 32kbps & ShoutcastMP3 at 48kbps).

 Then at some point WSR got the "Audio Factory" treament,
to be more on a par with the rest of the BBC Radio stations,
and thus two stream quality variants were created:
HE-AACv1 at 96kbps/48kHz (*med modes in GiP) and
HE-AACv1 at 48kbps /48kHz (*low modes in GiP); these
are equally available to UK/non-UK audiences, i.e.
if in the UK you can't get > 96kbps...

 Since 95% of BBC WS Radio content is "talk-radio",
I find 96kbps to be more than adequate for the task...
Considering it's a "World" service, meaning they have
to cater for a global audience, 96kbps is a fine compromise
between quality and bandwidth costs...
And even HE-AACv1 at 48kbps sounds acceptable for
those parts of the world with very expensive/slow Internet access...

> They also mostly had podcasts, and in the UK
> I was offered a choice of 128kbit/s and 64kbit/s
> (snip)
> I don't know either whether the 128kbit/s podcast
> option is offered outside the UK.

 As you said, much of the BBC WS Radio content
is turning up as MP3 Podcasts:
http://www.bbc.co.uk/podcasts/worldserviceradio
Programmes with copyrighted music (or other)
content are excluded from the podcast treatment,
in the rare occasions they do make it to podcast,
music tracks are truncated to just 10sec excerpts...

 Prior to "Audio Factory", only podcasts encoded
as 64kbpsCBR/44.1kHz/mono had been available.
More and more programmes do show up now with
an additional 128kbpsCBR/44.1kHz/stereo option,
which IS NOT location specific...
(I am only joking here, but several of your recent
posts seem to be inquisitive of overseas BBC Radio
bitrates, are you planning a retirement to Majorca, Richard?)

> it seems a lot more attractive than 96kbit/s HE-AAC
> with the SBR extension
> (snip)
> if HE-AAC with SBR

... HE-AAC always comes with SBR,
HE-AAC = AAC-LC + SBR

> is played on a player that does not support SBR
> half the bandwidth is lost.
> I have been wondering how best to deal with that.

 Yet another topic that you're recently concerned with...
It does appear as though you're the owner of
a hardware device that is incapable of fully rendering
HE-AACv1...

 FWIW, in 2017, 99% of software players on all
modern OSes can play back fully HE-AACv1.
Even browsers like Firefox 52.3.0ESR does on
this old Vista laptop...

 HE-AACv1 (previously known as aacp/aac+)
is even natively supported on most cheap mobile phones,
where you need good sound quality at reduced
bandwidth (because BW is expensive there...).

 If your device does not support HE-AACv1,
have you contacted its vendor by any chance?

> Converting to MP3 seems a possibility,
> (snip)
> It seems ffmpeg does not support SBR

 Not true; FFmpeg DOES SUPPORT native
decoding of HE-AACv1, as does ffplay,
which can be used to play back HE-AACv1 encodes...
It is only ENCODING to HE-AACv1
that the native AAC encoder of FFmpeg
can't perform (you'll have to build it with
the non-free FDK-AAC encoder instead...)
I often transcode HE-AACv1 m4a encodes
to mp3 files with ffmpeg, here's an example:

Batch file used:
-----------------------------------------------
FOR %%N in (*.m4a) DO ffmpeg -v 32 -stats -i "%%N" -vn -c:a libmp3lame -b:a 
128k -ar 44100 -ac 2 -joint_stereo 1 -af "volume=2.15" "%%~nN.mp3"
pause
-----------------------------------------------
Console excerpt:

-----------------------------------------------
ffmpeg version 3.3.1 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 6.3.0 (Rev3, Built by MSYS2 project)
*
[mov,mp4,m4a,3gp,3g2,mj2 @ 00a9bfc0] stream 0, timescale not set
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test-heaac.m4a':
*
  Duration: 00:17:30.94, start: 0.000000, bitrate: 63 kb/s
    Stream #0:0(und): Audio: aac (HE-AAC) (mp4a / 0x6134706D), 44100 Hz, 
stereo,
 fltp, 62 kb/s (default)
*
Stream mapping:
  Stream #0:0 -> #0:0 (aac (native) -> mp3 (libmp3lame))
Press [q] to stop, [?] for help
Output #0, mp3, to 'test-heaac.mp3':
*
size=   16424kB time=00:17:30.95 bitrate= 128.0kbits/s speed=9.42x
video:0kB audio:16422kB subtitle:0kB other streams:0kB global headers:0kB 
muxing
 overhead: 0.012851%
-----------------------------------------------

 I can assure you the MP3 transcode has full audio
bandwidth preserved!

> the latest episode of Science in Action, p05bdb8p.

=> "Risk of Lethal Heat Waves"

... The story of my life this summer! :-)
But, returning on topic,

get_iplayer --type=radio --pid=p05bdb8p -i | FindStr versions =>

versions:       original,podcast

get_iplayer --type=radio --pid=p05bdb8p -i | FindStr modes =>

modes:          original: 
dafmed1,dafmed2,dafmed3,dafmed4,daflow1,daflow2,daflow
3,daflow4,hafmed1,hafmed2,haflow1,haflow2,hlsaacmed1,hlsaaclow1

which is consistent with what I wrote earlier...

 But for the "podcast" version (not the MP3 file, this is an .m4a
file fetched by GiP) it would appear they apply geo-filtering :-(

verpids:        original: p05bdbfp
verpids:        podcast: p05c1hf1

http://open.live.bbc.co.uk/mediaselector/5/select/version/2.0/mediaset/pc/vpid/p05c1hf1

yields different stream data based on geo-location;
no signs of dashhigh/dashstd/hlsaacstd over here;
but then again, who really wants "talk-radio" @320kbps?
(well, some, like Jim web, do, I think even 96kbps
is superfluous...)

Best regards 