World Service podcast bit rates
ajebay at errichel.co.uk
Thu Aug 17 04:03:21 PDT 2017
This is way OT so forgive top post but you mentioned players and I had
some problems with Linn devices a while back which was mentioned again
recently and has still not to my knowledge been fixed.
My device of choice now is a Raspberry Pi with an IQaudIO DAC on top.
Software is straight Raspbian with MPD player and with Jean-Francois
Dockes' brilliant upmpdcli front end to give me UPnP renderer with
gapless playback between tracks. For completeness of system description
the music and GiP radio recordings are served by NAS running minimserver
and control point is BubbleUPnP on android phone.
Very much more affordable than Linn and more to the point, not yet
baulked at playing anything I throw at it and it enables me to continue
to use some quite decent amplifiers that otherwise would be redundant.
On 17/08/17 00:32, RS wrote:
>> From: Vangelis forthnet Sent: Wednesday, August 16, 2017 02:58
> Thanks Vangelis for your helpful comments and explanations.
>> Since 95% of BBC WS Radio content is "talk-radio",
>> I find 96kbps to be more than adequate for the task...
> I don't disagree. We have survived with much lower bandwidths in the
> past. One programme I listen to regularly is Moneybox on Radio 4. If
> I've remembered correctly for a long time its podcast was at 16kbit/s.
> I think it is probably made in a tiny studio with Paul Lewis sitting too
> close to the microphone, because now you can hear his every breath.
>> 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...
> We must be grateful for all the modes the BBC provides, because they are
> there for the benefit of devices the BBC wants to support, not for our
> benefit. Even so it would be nice if there were always one mode without
>> 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...
> I had forgotten about the restriction of music in podcasts. It was
> probably part of the reason Desert Island Discs didn't have a podcast
> for so long. I listened to one about a year ago, and it struck me the
> clips were rather short, but it didn't occur to me that was the reason.
>> (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?)
> I don't have any immediate plans to move to another country, but if I
> did it would be a consolation that I could still listen to BBC radio.
> If I comment on the politics of copyright licensing I am in danger of
> going way off topic. In my view the Television Without Frontiers
> Directive does not go anywhere near far enough. The EU Commission seems
> to be much closer to the mark with its argument that national copyright
> licences partition the single market and are therefore unlawful.
> Unfortunately the UK may not be in the EU by the time anything happens.
>>> 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
>> 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...
> I am sure you are right that there are many software players which will
> play AAC-LC and HE-AAC v1 without problem. It is a different matter
> when it comes to hardware players (portable players or satellite
> receivers). Finding players which will reliably play AAC-LC for up to 3
> hours is not simple. I was lucky with SanDisk. There was a new version
> of the firmware which fixed a problem with AAC-LC about 2 months after I
> asked. My Triax satellite receiver will play AAC television sound,
> whether stereo or AC3, from satellite, from its own recording, and from
> external sources for hours on end without problem. When it comes to
> playing AAC-LC/M4A files on the Music tab it will start playing and then
> stop after a time which is repeatable for each file, but varies from one
> file to another with no obvious pattern. I have not received any reply
> from Triax support. Since I use it as the interface to my surround
> sound amplifier I have to convert files to MP3 if they are to play
> In both cases the player is only claimed to support AAC-LC, so it would
> be unreasonable to ask the supplier to make it support HE-AAC.
> My Panasonic blu-ray player only supports MP3 and FLAC.
>> 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...).
> The specification for my phone says it plays eAAC+, which I gather is
> HE-AAC v2. I have not checked it with the Fraunhofer tests. The
> specification for my previous phone says it plays AAC/M4A, so it
> probably does not support HE-AAC v1. They are not the devices I want to
>> If your device does not support HE-AACv1,
>> have you contacted its vendor by any chance?
>> I often transcode HE-AACv1 m4a encodes
>> to mp3 files with ffmpeg, here's an example:
> I am intrigued that you are way ahead of me in transcoding HE-AAC v1 to
> MP3. You must have had a reason for doing it. When the --aactomp3
> option was withdrawn, several people asked for help in creating a
> --preset or --command to do it. I suspect I am not alone in finding MP3
> better supported than AAC by some players.
>> I can assure you the MP3 transcode has full audio
>> bandwidth preserved!
> When I was trying to do it I did find a free software spectrum analyser
> to check, but I couldn't get it to hear the file I wanted to analyse. I
> have since spotted that VLC has an uncalibrated spectrum analyser at
> Audio Visualisations Spectrum
>>> the latest episode of Science in Action, p05bdb8p.
>> get_iplayer --type=radio --pid=p05bdb8p -i | FindStr versions =>
>> versions: original,podcast
>> get_iplayer --type=radio --pid=p05bdb8p -i | FindStr modes =>
>> modes: original:
>> which is consistent with what I wrote earlier...
> and is the same as I got.
>> 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
>> 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?
> I agree. I thought it was weird to limit the original version to
> 96kbit/s while making the podcast version (which in this context refers
> to content rather than mode of delivery) at 320kbit/s. In fact the same
> podcast version modes are created for non-World Service programmes
> (matching the version original modes), but that is still weird because
> the highest bit rate the podcast itself is offered at is 128kbit/s.
> There were two points I wanted to make with my post. Firstly anyone
> having problems with the new World Service PIDs may be able to get round
> them by downloading the podcast if there is one. Secondly the podcast
> may offer higher quality for those whose players do not support HE-AAC v1.
> Best wishes
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
More information about the get_iplayer