Audio (radio) files downloaded using the --pid approach are much larger than they used to be.

I'm using get_iplayer 2.99, running under Windows 7 SP 1.

Earlier this week, during the time that the xml metadata was reported as being unavailable, I tried downloading a two-hour show. I downloaded it again today after the problem was reported as having been solved. In both cases this week, the file sizes were over 300 MB, while the file size for that show is usually around 48 MB. That's how I discovered the problem. What I report below in greater detail is another, smaller example displaying similar symptoms (though not as high a ratio of file size increase).

On February 27, I downloaded the program at http://www.bbc.co.uk/programmes/p04t64xs, which is a 14-minute Radio 3 essay. I used get_iplayer 2.94, and I downloaded it using the --pid p04t64xs command. The resulting file was 5,400 KB. Not having any problems at that time, I did not save any logs.

Today, I downloaded it again, using version 2.99 and this command:


The resulting audio file was 13,142 KB. In both cases, the files were downloaded in .m4a format.

I have attached the output of the command which I ran today, including the ffmpeg output.

Using ffprobe, I looked for obvious differences between the two files. The one downloaded in February includes this characteristic:
  Duration: 00:13:49.23, start: 0.000000, bitrate: 53 kb/s
The one downloaded today includes this characteristic:
  Duration: 00:13:50.91, start: 0.000000, bitrate: 129 kb/s
The ratio of bitrates matches the ratio of file sizes. I don't have any tools that can conveniently tell me whether there is actually any difference in audio quality or just some kind of padding.

Forgive me - are you asking why the files are larger in version 2.99 vs 2.94?

If you are, the answer lies in the release notes (in the Wiki), probably in the ones for 2.95 if I remember correctly.

Thanks for your prompt reply.

I didn't think that was what I was asking, though it seems to be part of the answer. I thought I was asking why the files were larger when the metadata wasn't available. Now I think that both two different circumstances can each account for larger files: missing metadata and the get_iplayer upgrade.

I first noticed a file's being roughly 7 times larger than in the past when I was still using 2.94 on Monday of this week, and there was a problem with the metadata. I later switched to 2.99 just to make sure that everything was up to date, in part because I didn't want to file a problem report concerning an obsolete version.

I've now read the release notes for 2.95 and 2.96. I'd glanced at them previously, but not concerning bandwidth issues. I now see that they're relevant to my situation. Having read the notes, I used ffprobe to analyze the .ts files as they were being downloaded, before they were converted to .m4a files. Right now, they're all coming in at bitrate 335 kb/s, which I'm not supposed to be able to get here in Canada. I'm not sure if this is a bug or a feature.

Compared to the 48 kbps which I used to reliably download, both 96 kbps and 320 kbps account for the two different file sizes increases that I'm seeing. I can understand an unexpected change to 96 but not to 320, given what the release notes say.

So, under the circumstances,
(1) I now think that get_iplayer is responding correctly to both unexpected and expected increases in available bandwidth. 
(2) I won't be surprised if some of the higher-bandwidth feeds eventually disappear again.

Missing metadata has nothing to do with file size. It simply seems that the BBC has become a bit lax on geoblocking. You can always go back to 48k streams if you prefer.