I have used get_iplayer for about 3 years and am very appreciative of the efforts of the developers and wiki/forum maintainers.  I have searched the forum for advice on use of the start/stop commands for rtmpdump, but I'd like to test this a little further to understand the subject fully.

I'm trying to download for offline listening Bach solo cello 4,5,6.  Unfortunately this has nearly 9 mins of continuity at the start which I'd like to remove.  While I'm at it, I might as well tidy up the end of the file too.  My instruction is:

get_iplayer --type=radio --pid b06s9js7 --start 00:08:54 --stop 01:35:10

I've observed that get_iplayer downloads about 70% of the file, stalls for a few seconds, then recommences at about 80% download.  Further, whereas with a Radio 3 recording I would expect a m4a file of approx. 320kbps (which is what I get if I download the programme without the start/stop commands), get_iplayer reports just 288kbps.  Still further, when I play the file in VLC, at about the 70% mark (about 60 mins into the recording), although the music doesn't appear to 'jump', the timing reported by VLC suddenly jumps from 60 mins to 69 mins or so.

I have seen advice on the forums to add --attempts=1 and --raw to the start/stop command.  However, I would then have to extract the audio from the partial .flv file and I've found that my Ruark radio doesn't like the m4a files that ffmpeg produces.  m4as produced by rtmpdump/get_iplayer seem fine.

Having said all the above, I do wonder if VLC isn't simply tricked into reporting a timing jump that isn't there.  As regards the kbps, although I haven't watched the stats on VLC all the way through the recording(!), having flicked through at intervals, it seems to report 320kbps throughout.

So, given your knowledge of the start/stop command, do you believe I'm probably actually getting a continuous 320kbps recording?  Should I ignore the get_iplayer report of 288kbps and VLC's supposed 60-69 min 'jump' and just enjoy the music?  Many thanks indeed for your help.

get_iplayer itself doesn't report a bitrate when downloading. You're probably referring to the output from ffmpeg while re-muxing to M4A. Use of --start could confuse its calculation of bitrate for display. The file has 86 minutes' worth of audio but ffmpeg thinks it is the full 95 minutes. 

In general, I suggest you don't use --start with rtmpdump because it can cause problems like this (among others), though --stop is OK. It is always best to use a proper audio editor, but you should be able to do the same thing during re-muxing by letting ffmpeg do the cropping.  For example:


The timestamp jump was most likely caused by rtmpdump resuming the download due to a streaming glitch.  When it starts appending to the file after resuming it may not account for the --start gap in the timestamps.  

As I mentioned, get_iplayer uses ffmpeg to re-mux FLV->M4A, so if you're having problems with re-muxing files outside of get_iplayer, you may simply be using a version of ffmpeg that is too old.

user-2 - many thanks indeed for your advice.  It works!  I can now trim Radio 3 downloads easily and maintain m4a 320kbps quality.  Thank you very much.  Suffolkman.