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
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
