GiP and ffmpeg

Budge ajebay at errichel.co.uk
Mon Nov 4 06:53:28 PST 2019


On 04/11/2019 14:15, Budge wrote:
> On 30/10/2019 12:06, Budge wrote:
>> On 29/10/2019 16:50, RS wrote:
>>>
>>>
>>> On 27/10/2019 21:08, Budge wrote:
>>>> On 27/10/2019 20:56, Budge wrote:
>>>
>>>>>
>>>>> Further to this thread as it has developed I find I have two example
>>>>> files both downloaded with GiP.  Using ffprobe, one is shown as:-
>>>>>
>>>>> Duration: 02:33:00.99, start: 0.000000, bitrate: 321 kb/s
>>>>>      Stream #0:0(eng): Audio: aac (mp4a / 0x6134706D), 48000 Hz, stereo,
>>>>> fltp, 320 kb/s (default)
>>>>>      Metadata:
>>>>>        handler_name    : SoundHandler
>>>>>      Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc,
>>>>> bt470bg/unknown/unknown), 150x84 [SAR 72:72 DAR 25:14], 90k tbr, 90k
>>>>> tbn, 90k tbc (attached pic)
>>>>>
>>>>> and the second:-
>>>>>
>>>>> Duration: 02:37:00.06, start: 0.000000, bitrate: 321 kb/s
>>>>>      Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz,
>>>>> stereo, fltp, 320 kb/s (default)
>>>>>      Metadata:
>>>>>        handler_name    : SoundHandler
>>>>>      Stream #0:1: Video: mjpeg (Baseline), yuvj420p(pc,
>>>>> bt470bg/unknown/unknown), 86x48 [SAR 72:72 DAR 43:24], 90k tbr, 90k tbn,
>>>>> 90k tbc (attached pic).
>>>>>
>>>>> Among the differences I note first is AAC, I assume HE? at 48000Hz and
>>>>> the second is AAC (LC) at 44100Hz.
>>>>>
>>>>> The first is later and dated 2017-01-19 and the second 2014-05-15.
>>>>>
>>>>> It is the earlier download that works and I still believe the problem
>>>>> has been from my incorrect setting up of GiP.  Both files play on all my
>>>>> players except the Linn DS devices.
>>>>>
>>>>> I am about to pass the problem over to Linn but before I do please could
>>>>> somebody suggest why the two files have different codecs.
>>>>>
>>>>
>>>> Correction.  Not HE above, just AAC.
>>>> Budge
>>>>
>>> The principal difference between the two files is that the one that
>>> works has a sampling rate of 48kHz and the one that doesn't has a
>>> sampling rate of 44.1kHz.  One possibility is that Linn does not support
>>> a 44.1kHz sampling rate, although it would be very surprising if it didn't.
>>>
>>> Since "Linn recommends FLAC" you could try converting the 44.1kHz
>>> sampling rate file to FLAC at the same sampling rate.  You could also
>>> try resampling the 44.1kHz sampling rate file to 48kHz.
>>>
>>> What puzzles me is how you got a file with a sampling rate of 44.1kHz
>>> and a bit rate of 320kbit/s.  I am not saying that is not a valid
>>> combination; it is.  What I am saying is that as far as I am aware it is
>>> not a combination available from the BBC.
>>>
>>> Many radio programmes are available as podcasts.  You can download a
>>> podcast from the BBC website.  You will be offered a choice of bit
>>> rates, 64kbit/s and 128kbit/s.  The file will be in MP3 format with a
>>> sampling rate of 44.1kHz.
>>>
>>> If you download a radio programme with get_iplayer without using the
>>> --raw option you will get a M4A/AAC file with a sampling rate of 48kHz.
>>> You will have a choice of bit rates, in some cases up to 320kbit/s.
>>>
>>> In the last few months programmes with podcasts have also had podcast
>>> versions which can be downloaded with get_iplayer.  More recently still
>>> for some programmes the only download available with get_iplayer has
>>> been the podcast version.  In either case the file format has been
>>> M4A/AAC and the sampling rate has been 48kHz.
>>>
>>> One example of a Radio 3 programme with a podcast is The Listening Service.
>>> get_iplayer --pid=m0009jzd --info
>>> shows that it has both original and podcast versions and, for both, bit
>>> rates up to 320kbit/s are available.  If you download it you will see
>>> the sampling rate is 48kHz.
>>>
>>> If you go to the programme's website
>>> https://www.bbc.co.uk/programmes/b078n25h/episodes/downloads
>>> the download buttons will offer a choice of 64kbit/s and 128kbit/s bit
>>> rates.  If you download one of them you will get a MP3 file with a
>>> sampling rate of 44.1kHz.
>>>
>>> There is no option which combines a 44.1kHz sampling rate with a bit
>>> rate of 320kbitj/s.
>>>
>>> I have just read your post again, and it seems I have got the one that
>>> works and the one that doesn't the wrong way round.  It seems even more
>>> unlikely that your Linn device would not support a 48kHz sampling rate,
>>> although 44.1kHz is the CD standard.
>>>
>>> Best wishes
>>> Richard
>>>
>>>
>>> _______________________________________________
>>> get_iplayer mailing list
>>> get_iplayer at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/get_iplayer
>> Hi Richard,
>> Many thanks for the information and for your explanations.
>>
>> Unfortunately all these files are historical downloads which I am trying
>> to clean up and I believe (but cannot easily check,) these problem files
>> have resulted from downloads following an operating system change or new
>> installation, following which I have made errors which have munged the
>> downloads until discovered and corrected!
>>
>> Almost all of the problems can be linked to playing, or not as the case
>> may be, on Linn DS devices.
>>
>> Last time I tried running through ffmpeg things became worse even when
>> just "copying" through
>>
>> I am trying again to raise this with Linn.  Meanwhile I will look again
>> at my samples as I could easily get them muddled but afaik my normal
>> classical (third programme) downloads are:-
>>
>> Stream #0:0(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo,
>> fltp, 320 kb/s (default)
>>
>> which is what you advise and these play fine.
>>
>> Let us see how we get on with Linn.
>> Thanks again,
>> Alastair.
>>
>> _______________________________________________
>> get_iplayer mailing list
>> get_iplayer at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/get_iplayer
>>
> 
> At the risk of being slightly OT because normal downloads of classical
> music are all fine with Linn DS and all the others I would like to raise
> again my problem because I have had essentially the same reply from Linn
> that I had in 2017.  Here is what they say:-
> 
> "The engineer advised that he received a file from you and advised that
> if you convert the track to FLAC or ALAC that it plays.
> The problems are caused by the file being split into an enormous number
> of tiny chunks (over 400,000 audio blocks for a 9,200 second track); any
> encoder which reduced this would allow the file to play.
> 
> I passed the first track you supplied to me to them and they advised
> that have advised that the track appears to be corrupt, and transcoding
> the track should allow it to then be played on the DSM."
> 
> Leaving aside the suggestion that the file had been corrupted, which in
> one case is credible even though it plays fine on eg VLC or RPi with
> mplayer and upmpdcli, can anybody explain what Linn are on about?  I
> shall try and find my earlier thread and try again to get to the bottom
> of this.
> 
> Budge
> 
> _______________________________________________
> get_iplayer mailing list
> get_iplayer at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer
> 

Further to the above I have read all my previous thread from January
2017 and I am none the wiser, probably less so!  Linn advise the first
sample file has been corrupted.  The only clue I have on this is from
running AtomicParsley on the file when I get in the last line:-

Segmentation fault (core dumped)

Any clues what might have caused this and how can I correct the fault
(which may or may not be the problem with Linn DS player)?



More information about the get_iplayer mailing list