Re: GiP and ffmpeg
On 4 Nov 2019 at 14:15, Budge Budge wrote: > The Linn DS 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. imo the Linn DS does not have sufficient cpu power, memory or cache to handle such a fragmented file ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GiP and ffmpeg
On 04/11/2019 15:14, Roger Bell_West wrote: On Mon, Nov 04, 2019 at 02:53:28PM +, 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
Re: GiP and ffmpeg
On Mon, Nov 04, 2019 at 02:53:28PM +, 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. R ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: GiP and ffmpeg
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.00, 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.00, 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
Re: GiP and ffmpeg
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.00, 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.00, 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
