Re: World Service podcast bit rates
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@64kbps/44.1kHz (and until the end of 2015 there existed live streams in the form of WMA9@32kbps & ShoutcastMP3@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@96kbps/48kHz (*med modes in GiP) and HE-AACv1@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@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.00, 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
Re: New radio PIDs, more than 8 characters - "solved"
On Mon Aug 14 13:19:14 BST 2017, M Clark wrote:
changing all 7 occurrences (sigh...) of
[bp]0[a-z0-9]{6}
to
(?:[bp]0[a-z0-9]{6}|w[a-z0-9]{7,14})
solves the w3*, w1* problem for Me.
Hi Martin; that new code still assumes that both Red Bee & PIPs
PIDs will have "0" as the second character in the string.
I am not saying this is something that will have to be dealt with soon,
but I've watched Red Bee PIDs move from "b08*" to "b09*"
and, recently, from "b0909***" to "b0910***", e.g. "b0910w0x".
If this is a pattern, then I expect strings like "b0999***" to appear in
the future;
and the next logical (?) step would be strings beginning with "b1**"
(in which case the amended code will break..).
Pure speculation on my part, though...
I haven't done the maths myself (number of permutations of 7 alphanumeric
strings),
this is supposed to be a huge integer; but, as PIDs are unique
(can't be recycled), linked to a specific audio-visual offering from the
beeb,
that huge number is bound to be exhausted sometime...
Regards,
Vangelis.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: New radio PIDs, more than 8 characters - "solved"
More on REs ...
--
www.macfh.co.uk/MacFH.html
> > Yes, I was aware of \b support in some languages, but RE support
> > varies across languages, and, knowing this but not being experienced
> > in PERL, I checked at least two online sources for PERL REs
> and could
> > find no evidence of support for it.
>
> One is http://perldoc.perl.org/perlre.html#Assertions
Obviously my brief research was too brief!
So, yielding to your superior knowledge of PERL, for the sake of clarity for
the benefit of those who may have had difficulty in following the nuances of
the argument, or been confused by the multiple suggestions, would we both
agree with?:
\b[bpw][0-9][a-z0-9]{7,13}\b
> It was Perl that invented `\b', along with many of the other
> conventions
> that spread to other implementations, e.g. `\d' for digit, a
> `?' suffix
> for non-greedy as in /<.*?>/, the otherwise invalid `?' after an open
> parenthesis as a gateway for further flags like the
> non-capturing `:' in
> /(.)(?:.)(.)/, etc. Larry Wall was very knowledgable of the Unix
> programming environment, including the various regular expression
> syntaxes in sed, grep, egrep, ..., and came up with a consistent
> almost-superset that had some nice conveniences too.
As it happens I've been doing some Bash scripting over the last week or so.
> > True, but if that is starting to happen, then one of the
> other 'rules'
> > was to break a monolithic program into blocks
>
> Alas, AFAIK, get_iplayer wishes to ship as a single file.
You can still break a single file down into blocks, both by using
subroutines/functions or even just by appropriate layout and commenting, and
in both cases individually testing that the resulting sections do what is
expected of them.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: New radio PIDs, more than 8 characters - "solved"
More about Regular Expressions (REs), which can be safely ignored by those not interested ... -- www.macfh.co.uk/MacFH.html > > it might be necessary to bracket it at the beginning and end with > > non-capturing non-word meta- or pseudo-characters > > Rather than \W, representing a single non-word character, \b would be > better, meaning a zero-width boundary between a word, \w, and > non-word, > \W, character, or the start or end of the string. /\Wfoo\W/ matches > ":foo:", but not "foo", but /\bfoo\b/ matches both. The zero-width > means it consumes nothing; the test is of the character either side. Yes, I was aware of \b support in some languages, but RE support varies across languages, and, knowing this but not being experienced in PERL, I checked at least two online sources for PERL REs and could find no evidence of support for it. If you're a PERL programmer and therefore know that it works, I concede to your superior knowledge. RE support has varied from none to very complete with every language I've programmed, which includes Assembler, Bash, BASIC, C, COBOL, SQL, and Python, but these days I'm more used to HTML and JavaScript, and before that I was doing quite a lot of work in Java, and, despite their similar sounding names and similarities in basic syntax, the latter two are very different in many, perhaps most, other respects, including REs. So REs are regularly one of those areas I find myself having to refer back to manuals and API documentation in particular cases, and at one point in one particular case got so frustrated with the complexity of the REs I was trying to develop that I spent some time creating a JS RE test page to help develop the code. Ironically, the JS RE Test Page has blossomed into being quite a successful page on my site, but the original page that caused it to be written is still 'under development'!-) > > Pretty much the first item in that list was to declare constants at > > the beginning of the program containing all the fixed or semi-fixed > > values that the program needed > > Though that can put them a long way from their use, removing context > from their definition and requiring it to be put back into their > identifier instead. True, but if that is starting to happen, then one of the other 'rules' was to break a monolithic program into blocks - each of which has one particular purpose, which testing has shown it to do well and without rror - and then build the program up by combining such blocks; because the individual components are known to work, the wider program built from them is likely to be more reliable. Regards. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
World Service podcast bit rates
This is off topic so if you are going to be offended please stop reading. Vangelis mentioned at the weekend that the World Service is very popular overseas. I don't doubt it. It seems to have a very wide range of very informative programmes. My problem is being selective. At one time I used to use Juice to retrieve all the podcasts I might be interested in and found myself drowning in downloads I was never going to have time to listen to. That is not the reason for this post. I noticed that some of the programmes mentioned in the discussion about w1, w3 and 15 digit PIDS were limited to dafmed, hafmed and hlsaacmed and a bit rate of 96kbit/s. They also mostly had podcasts, and in the UK I was offered a choice of 128kbit/s and 64kbit/s. I was aware that BBC radio outside the UK was at one time limited to 96kbit/s, but I did not know if that limit still applied. It is difficult to find the answer on the BBC's web site. I don't know either whether the 128kbit/s podcast option is offered outside the UK. If it is, it seems a lot more attractive than 96kbit/s HE-AAC with the SBR extension from get_iplayer. As Vangelis pointed out a few weeks ago, if HE-AAC with 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. Converting to MP3 seems a possibility, despite the purists' objection that it is converting from one lossy format to another. It seems ffmpeg does not support SBR, but VLC could be used for the conversion. The podcast is already available as MP3. Even if 128kbit/s is not offered for podcasts outside the UK, 64kbit/s MP3 is probably better than 96kbit/s HE-AAC with half the bandwidth missing. There is something else surprising I noticed this morning about the latest episode of Science in Action, p05bdb8p. The original version was limited to 96kbit/s with dafmed, hafmed and hlsaacmed. The podcast version, p05c1hf1, not only had dafstd, hafstd and hlsaacstd at 128kbit/s, but also dafhigh and hafhigh at 320kbit/s. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: New radio PIDs, more than 8 characters
C E Macfarlane wrote: Thinking about this a bit more, I wouldn't wish to claim a spurious hit was more likely with no upper limit, but nevertheless I would still regard it better programming practice to have one - with normal written English, the potential for spurious hits would be low, and in the event of one it would be delimited quickly by the next space, but if you were trawling raw HTML or similar code, which might contain longs strings of pseudo-random characters as not just PIDs, but also GUIDs, session keys, and the like, then the potential for spurious hit would be very much increased, so more would be found, and in the interests of program efficiency you'd want them to be delimited sooner rather than later. This is reasonable. The regexp without an upper limit sourced from the BBC's code is used to confirm that a given string is formed only of characters from an acceptable set to make up a PID. In most cases the string which is passed in is explicitly extracted from the request URL, as the application in question is a server-side, web-based one. For such purposes I think the lack of an upper limit is completely acceptable, but if you're writing code to extract a valid PID from text of unknown length or complexity, the regexp probably is not very efficient. -- James Scholes http://twitter.com/JamesScholes ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: New radio PIDs, more than 8 characters - "solved"
Hi C. E., > it might be necessary to bracket it at the beginning and end with > non-capturing non-word meta- or pseudo-characters Rather than \W, representing a single non-word character, \b would be better, meaning a zero-width boundary between a word, \w, and non-word, \W, character, or the start or end of the string. /\Wfoo\W/ matches ":foo:", but not "foo", but /\bfoo\b/ matches both. The zero-width means it consumes nothing; the test is of the character either side. > pseudo code > if --url > strip characters following last / > use as pid ... > ... particularly as URLs exist with other characters after the PID, > though perhaps these might not be used in the context of GiP. Yes, it's never that simple. :-) URLs have a defined structure and encoding rules, and there's query parameters and fragments to consider. > Pretty much the first item in that list was to declare constants at > the beginning of the program containing all the fixed or semi-fixed > values that the program needed Though that can put them a long way from their use, removing context from their definition and requiring it to be put back into their identifier instead. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
