Poor quality audio on last 2 episodes

[Jeremy Nicoll - ml get_iplayer]

Mark Phillips <mark at wondermouse.co.uk> wrote:

>I have been recording the series Petite Mort on Radio 4 - both as
>individual 15 minute episodes and also as an omnibus on 4 Extra.
>
>Episodes 1-8 and Omnibus 1 all came down at 128k AAC as expected, Episodes
>9 and 10 and Omnibus part 2 have just turned up as a much less acceptable
>48k.

I've noticed this sort of thing sometimes happens...

So far as I understand things, the BBC send the audio files for programmes
to CDNs (CDN = content delivery network), which are commercial businesses
whose business it is to host & distribute digital files.  Get_iplayer finds
out where it thinks all the available copies of a programme are, and tries
them in turn, working through a list of options at different quality
settings and also - in theory - trying different providers' copies of the
files.  Sometimes the particular file one ends up with isn't one of the good
quality copies.

You can influence this by telling get_iplayer specifically which qualities
you're willing to accept (so for example it won't try to fetch a low quality
file), and if - say - the highest quality file from one provider won't fetch
you can explicitly ask for the highest quality one from another provider.

If you make successive fetches of the same programme you will need to use
the  --force  parameter on the command to override the fact that the
download history knows you've already fetched that programme.

To affect quality you either use relatively vague parameters like  

  --modes=best   etc  or   explicit ones like --modes=flashaachigh

If you look at the output from get_iplayer early on in a fetch you'll see it
list the modes that it thinks are available at that point for the programme
concerned.  The list sometimes contains numbered alternatives at the same
quality level, eg

   flashaachigh1,flashaachigh2,flash...

which I take to mean (maybe wrongly) that that particular program appears to
have 2 'flashaachigh' options available.  If a particular fetch fetches eg
flashaachigh1 (it'll say in the output which was fetched) and it's broken or
fails and tries a lower quality, you can explicitly ask later for the other
alternative with 

  -modes=flashaachigh2

ie include the number.



It's also sometimes useful to use --file-prefix   to set the elements of a
fetched file's name; for example I use quite a long option, something like:

  --file-prefix "T=<name> S=<senum> E=<episode> M=<mode> 
      Z=<duration> F=<firstbcastdate> L=<lastbcastdate>"

when I fetch TV programmes, so that the filename created includes various
bits of info about the file concerned, including the mode value of that
file.  In other words I get a filename like:

  T=Have I Got News for You Series 46 S=s46e06 E=Episode 6 M=flashvhigh
Z=1740 F=2013-11-08 L=2013-11-08.mp4

so I can by looking at it that that's a "M=flashvhigh" file.  In the name
template "M=<mode>" created that section.


However, fiddling around in this sort of manner needs one to look at the
output from each fetch to understand what's happening.  If that's not
something you're comfortable doing, you might just want to reissue another
fetch (with --force) for any program that arrived in low quality, perhaps a
day later.  I have the impression that if one does a fetch just as a program
first goes to the CDNs one can be unlucky and get a low quality one when a
day or so later higher quality ones will be available too.

-- 
Jeremy Nicoll - my opinions are my own.