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