Re: World Service podcast bit rates
Hi Richard, 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. Regards, Alastair. 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@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 SBR. 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 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... 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 reliably. 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 ev
Re: New radio PIDs, more than 8 characters - "solved"
Hi C. E.,
> for a high-level language, [Perl's] syntax is unnecessarily difficult
> and obscure.
Perl's syntax is heavy on notation, but then notation is powerful
compared to the long-hand alternatives, and that's why it's fine in
maths, chemistry, and Perl. For the occasional visitor, Python's that
way →
Perl uses sigils, a symbol attached to a variable name, but then so does
sh(1) that influenced it. Many languages do, Ruby, PHP, ..., though not
all the time, e.g. Python has `@foo' to mean it's a decorator function.
Perl also sigils to indicate the type of an identifier, so `$foo' is a
simple scalar variable whereas `@bar' is a indexable list. Similar
syntax differences allow literals to be given: `[42, 314, "xyzzy"]' is
a list whereas '{May => 10, Hammond => 11}' is a `hash', AKA associative
array or dictionary.
Perl is no harder to learn than C or Ruby. They both like notation too,
e.g. the «int foo(int, int (*)(void *, char *), void *);» I wrote
recently. Perl's easier than PHP because that has far too much
duplication, bad design, and corner cases to memorise. C++ is also
something to avoid; too large a language and each coder uses a distinct
subset. Assembly languages are easy, once you understand a CPU's
workings, but RISC ones like ARM are nice to learn compared to the
twisty passages of x86.
> The whole point of high-level languages, the reason they were
> invented, was make to programming more human-readable and therefore
> more understandable, but Perl bucks that trend.
I think it was to give more expressive power than assembly language by
introduction abstraction, and notation, at the cost of efficiency.
Plenty of Unix programmers with a sh, sed, awk, background found Perl
straightforward to pick up because it distilled their features into a
single language. It was Perl 4 when I learnt it, and a single
well-written man page described the language and that's all the
documentation there was.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: World Service podcast bit rates
Oh for get_iplayer when I was sailing around the Indian Ocean in the early '60s. Shortwave radio was the only option whether for speech or even "music". I still mourn the day the World Service dropped its ident tune which was essential to tune into the news broadcasts. I started off with a "steam driven" Eddystone radio which was the size of a minor planet and eventually I worked through a series of Sony radios. I still have one about half the sizes of a paperback book which is truly excellent with its digital frequency display. Needless to say it is seldom used these days other than for nostalgic reasons. As Vangelis has said, 96kps is more than adequate for speech and I can't recall when I last listened to music on the World Service (used to be call Overseas Service or something like that I seem to remember). Notwithstanding some of the rather boring spats on this list, thank goodness for the author(s) of get_iplayer which I find I find indispensible. The niceties of the programming language are of no interest to me as I am stuck in the world of Fortran IV and Fortran 77. Dinkypumpkin et al keep up the good work. Rgds Simon Morgan -- I am using the free version of SPAMfighter. SPAMfighter has removed 643 of my spam emails to date. Get the free SPAMfighter here: http://www.spamfighter.com/len Do you have a slow PC? Try a Free scan http://www.spamfighter.com/SLOW-PCfighter?cid=sigen ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: World Service podcast bit rates
From: Budge Sent: Thursday, August 17, 2017 12:03 Hi Richard, 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. Hi Alastair Many thanks for the suggestion. I'll certainly look at it. I had a quick glance at IQaudIO, and it seems they have a range of boards. The Pi-Digi+ will probably do what I need, although I may only need a HDMI to TOSlink converter as my amplifier will do the DA conversion. Sorry to hear that Linn has not fixed your AAC problem. At one stage it seemed quite promising when they identified the problem from the samples you sent them. I received a lot of help on this listserver from someone with a username something like batguano999. The problem he had sounded similar to mine. He had found it was container dependent. The length of file his player would play ranged from zero with AVconv to 40s for ffmpeg up to 30min for a file multiplexed with mp4creator. I wasn't getting anywhere with AGPteK support so I decided to buy a SanDisk Clip Jam to see if that was any better. I then came across a thread in a ffmpeg forum started by someone with a similar username. He said there it was the SanDisk Clip Jam he was having a problem with! He had been trying for a year or so to get the ffmpeg developers to fix whatever in the multiplexing was responsible for the problem. Anyway I've been lucky because SanDisk issued new firmware which fixed the problem only about two months after I reported it. It will now play all the AAC-LC files I have tried. I still have a problem with the Triax satellite receiver, so I'll give the Raspberry Pi a try. The irony is that the FAAD and FAAD2 decoders used by VLC and ffmpeg seem to work well. I appreciate that developers may not want to include GPL licensed code in their products, but you would think they might get some inspiration as to how to make their decoders work from the free decoders. Best wishes Richard ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
