On 04/11/2019 20:04, RS wrote: > 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 Dear Richard, Very many thanks for you reply and continued assistance which is very much appreciated. I am still trying to pick up the threads here and will look at all the options and suggestions.
AFAIK I have never converted any of the files in my master data set but I have explained that this set spans many years and many OS versions even before my own installation errors so there is no obvious explanation of my problem. I will try to learn how to break up my files to aid digestion by Linn as you suggest, if I can, but only to test their player. I do not have enough time to listen to all my collection now, let alone have time to edit each file in turn but my problem with the control point progress line not working on some files does mean there are some works in which I never hear the final act! I will plan and refine a more structured trial of options for conversion suggested and try and report but I am well beyond my own knowledge so appreciate and am grateful for the help received. Whilst this approach may help me pin down the problem it seems clear that Linn have no intention of helping solve this issue as a Linn problem, even though every other playing device I have, including the humble Raspberry Pi and Vero devices costing a tenth of the cost of the cheapest Linn DS play without problems. PS for some reason your message came flagged as spam this time whereas all previous messages have arrived without problem. Thought I would let you know but it could be a problem at my end. Best wishes, Budge. _______________________________________________ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
