GiP and ffmpeg

RS richard22j at zoho.com
Mon Nov 4 12:04:12 PST 2019


On 04/11/2019 15:14, Roger Bell_West wrote:
> On Mon, Nov 04, 2019 at 02:53:28PM +0000, Budge wrote:
>> 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)?
> 
> I don't see any reply to James Scholes' comment of 23 October. Did you
> try remuxing as he suggested? Or even a plain remux without the
> bitstream filter:
> 
> ffmpeg -i input.m4a -vn -acodec copy output.m4a
> 
> My experience with Linn is that while they make some very good
> analogue hardware they've never liked digital and they aren't
> particularly competent at it.
> 

I haven't been back to re-read the old thread, but I do remember your 
saying that Linn had told you there were too many chunks, by which I 
think they meant frames or blocks.  Someone here (and I can't remember 
who) pointed out that since the sampling rate, the number of samples per 
frame (SPF) and the number of channels were fixed, it was a matter of 
arithmetic how many frames there were.  I think you confirmed that 
Mediainfo showed SPF 1024 for one of your files.  According to Wikipedia 
the standard blocksize for stationary signals in AAC is 1024 or 960 
samples, so that seems right.

According to xiph.org, for linear prediction on 44.1kHz audio flac 
defaults to a block size of 4096.  That may be the reason converting to 
flac will result in fewer blocks or frames.  Have you tried converting a 
problem file to flac to confirm Linn's assertion that that will enable 
it to play?  xiph.org also says flac frames are self-contained, so they 
do not rely on anything in a preceding or subsequent frame.  That may be 
another reason a file may play in flac but not in another format.

Another way to reduce the number of frames would be to break up the 
recording into individual works.  If that enables it to play you could 
then experiment to find the largest number of frames in a file that will 
allow it to play.  You will then be in a position to tell Linn how many 
frames you need to be supported.

You mentioned that the files that worked had a sampling rate of 48kHz, 
while those that failed had a sampling rate of 44.1kHz.  To test whether 
the Linn player is failing to play 44.1kHz files you could re-sample a 
non-working file

ffmpeg -i=infile.m4a -vn -ar=48000 outfile.m4a

to confirm whether it then worked.  You could also take a working file 
and re-sample it to 44.1kHz to confirm whether it then stopped working.

In an earlier comment I said that if you download a radio programme in 
get_iplayer without --raw you will always get a M4A/AAC file with a 
sampling rate of 48kHz.  That was wrong.  The Radio 4 programme Law in 
Action used a 44.1kHz sampling rate until 17 Feb 2015.  It has used 
48kHz since 24 Feb 2015.  I still haven't come across a file with a 
combination of 320kbit/s bit rate and 44.1kHz sampling rate, so I am 
still puzzled how you got that combination.  Could you have converted it 
to .wav at some point?  The default sampling rate for .wav is 44.1kHz, 
although the BBC internally uses 48kHz .wav.

Best wishes
Richard





More information about the get_iplayer mailing list