Re: radio sample rates.
On Tue, 17 Mar 2015 09:27:25 + (GMT), Jim web wrote: Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). Or use Firefox (on linux). Far easier to highlight the text in theblock with right click drag surely? All that does with NetSurf here is drag the entire page. Doesn't reveal the text that is hidden by black rectangles. OK but how do you highlight something (anything) to copy it to the clipboard. -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article e1yxcgn-ux...@bombadil.infradead.org, Dave Liquorice allso...@howhill.com wrote: Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). Or use Firefox (on linux). Far easier to highlight the text in theblock with right click drag surely? All that does with NetSurf here is drag the entire page. Doesn't reveal the text that is hidden by black rectangles. I guess the problem is that the page scripting redefines 'code' which is a standard markup, and this confuses NetSurf. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article mpro.nlbm2n0068cj80...@wingsandbeaks.org.uk.invalid, Jeremy Nicoll - ml get_iplayer jn.ml.gti...@wingsandbeaks.org.uk wrote: But I did find reading awkward using NetSurf because the definition of code seems on those pages to cause it to render as black text in a black rectangle! So I may have missed it. I assume this is a NetSurf problem. (This is using the RO NetSurf.) Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). I've been saving as a drawfile [1] and then removing the rectangles. Or use Firefox (on linux). I've done that on occasion. But its often quicker to do the above as I can go on using the same machine. I write all my notes, etc, on the RISC OS machine. Jim [1] For those who don't know RISC OS, 'drawfile' is its standard vector image format. -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article e1yxt8l-00063l...@bombadil.infradead.org, Dave Liquorice allso...@howhill.com wrote: On Tue, 17 Mar 2015 09:27:25 + (GMT), Jim web wrote: Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). Or use Firefox (on linux). Far easier to highlight the text in theblock with right click drag surely? All that does with NetSurf here is drag the entire page. Doesn't reveal the text that is hidden by black rectangles. OK but how do you highlight something (anything) to copy it to the clipboard. Ah! Sorry, I think I now see what was meant. A *left* mouse button click-drag does 'highlight' the text as all being white text against a mid-grey background. Confusion was perhaps because the mousebutton arrangements for RISC OS may be different than other window systems. I've got so used to using a mix of RISC OS and both ROX and xfce on Linux that I tend to adapt without thinking, but missed your meaning here. Doing this does show the code marked text. Since it was otherwise invisible it is better, but still hard to read. I can save it as text but that loses the font change that distinguishes code from body text, along with other layout. Its an improvement, but still I find it hard to read. Easier to export as a drawfile and get a clearer result. I can save out as a drawfile as easily as text. I'd experimented with other mousebutton and keyboard action modifier keys, but didn't find anything that did any better. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article mpro.nl9kix00g3lj40...@wingsandbeaks.org.uk.invalid, Jeremy Nicoll - ml get_iplayer jn.ml.gti...@wingsandbeaks.org.uk wrote: Jim Lesurf w...@audiomisc.co.uk wrote: This is all for *sound radio*... Ah you traditionalist! Don't you look forward to touch sniff radio? In case anyone is curious, I can tell the sample rate because the audio DAC I use indicates it. In general, it switches to 'follow the source'. So the audio stream isn't just audio data then? Afraid that's a muddled question to ask. Audio is essentially always sampled at a specific rate. When LPCM is converted into other forms like mp3, flac, aac, etc, then they will have an associated rate. I kind-of assumed that you might be able to play a stream at any sampling rate you liked, though that would alter the time taken to play a clip... Well, you could choose to playback at the 'wrong rate' in order to speed up /sharpen or slow down / flatten the sounds. But in practice you're more likely to encounter rate *conversions* if you want to hear things at the right speed / pitch. That requires data manipulation. So you can convert the rate. But all such conversions carry the risk of degrading the result. So its best avoided unless there is a specific reason to do it. In particular 44.1k - 48k conversions are a real challenge to do well because of the close ratio of the rate values and the high integers for the lowest common ratio. Its much easier to make 48k into 96k well than convert from 48k to 44.1k. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On 16 Mar, w...@audiomisc.co.uk wrote: When I measured test stream mumble years ago they showed the levels of artifacts were low. Just checked back, and this may be of interest. http://www.audiomisc.co.uk/Linux/Sound2/ListenAgain.html It shows the results I got from the 44.1k output of FF+Flash back in 2009. The 320 aac stream was pretty clean. (Afraid the FFTs were done with simple windows, so a bit frizzy.) Wherever it was being done, any 48k - 44.1k was being done well. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article 575c0faa39219d3bb67632d5d8ea7...@custommade.org.uk, Christopher Woods christop...@custommade.org.uk wrote: On 2015-03-15 22:23, Tris wrote: I'm not sure if this is connected but two or three weeks ago I was still on v2.89 (I think) and all radio downloading suddenly became unavailable. Things all started working again after I updated to 2.91 which had all the changes in it for the upcoming changes to BBC streaming methods (which had obviously just happened when things stopped for me). Maybe this change to BBC methods is also when the file rates became 48k for you? Tris Audio Factory encodes at the audio's native 48 kHz; this is what the stations operate at internally. Understood. 44.1 kHz was a legacy thing and to be honest was unnecessary; after stations went all-digital at 48 kHz it effectively gave us three resampling steps (48 - 44.1 - 48). That raises some questions. Ever since I've used the FireFox + Flash plugin it has output 44.1k. I've understood the conversion was 'at source'. i.e. coyopa sent 44.1k. But the closed nature of Flash makes it hard for me to tell. When I measured test stream mumble years ago they showed the levels of artifacts were low. Admittedly that was in the 'nemesis' era. :-) So when I now get 44.1k is that being sent by the server? Or is the Flash plugin doing it? And are uses of the RTMP/Flash plugin stuck with it? I'm asking here but if you can't say I'll raise it with someone else off this public list. And the situation that alerted me is that I seem to have found that gip 2.90 got me 44.1k files, but 2.91 gets me 48k files with a different filename syntax. Were both types always present, and can I take it that the 48k version would avoid a conversion? i.e. the 44.1k is downstream of the 48k? Or the reverse? Now we have zero additional resampling steps (save for anything like commercial music, which will have been resampled once from 44.1 kHz source to 48 kHz). However I get 44.1k from FF+Flash - just like gip until a short time ago. Which raises the above questions. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On 16/03/15 14:33, Jim web wrote: I'll try to find out if that's still the case. I've ended up deciding to try and write a potted 'technical history' of the iplayer development. So I'll take this elsewhere as not 'on topic' for this list unless people are interested. Jim Jim I'd be in interested in your technical history of iplayer as and when. Where you end up putting it is up to you and others, might be as you say a bit off topic here. Mike ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article 5506fd30.1070...@gmail.com, michael norman michaeltnor...@gmail.com wrote: On 16/03/15 14:33, Jim web wrote: I'll try to find out if that's still the case. I've ended up deciding to try and write a potted 'technical history' of the iplayer development. So I'll take this elsewhere as not 'on topic' for this list unless people are interested. I'd be in interested in your technical history of iplayer as and when. Where you end up putting it is up to you and others, might be as you say a bit off topic here. OK. I'll say more once I've got somewhere. As yet I've no idea how large it will become or when it'll be done. And I may produce a version for 'Hi Fi News' magazine, first, then my website, or the other way about! As yet I'm still finding out details and contacting a few people. Might be good if I can do something similar to the PCM/NICAM radio distribution history page http://www.audiomisc.co.uk/BBC/PCMandNICAM/History.html I did a while ago. But in this case I only have a few relevant photos and don't yet know how I'll get on! Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
RE: radio sample rates.
-Original Message- From: get_iplayer [mailto:get_iplayer-boun...@lists.infradead.org] On Behalf Of Jim web Sent: 16 March 2015 14:34 To: get_iplayer@lists.infradead.org Subject: Re: radio sample rates. ... I'll try to find out if that's still the case. I've ended up deciding to try and write a potted 'technical history' of the iplayer development. So I'll take this elsewhere as not 'on topic' for this list unless people are interested. Jim I, for one, would be interested. Simon Morgan ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article 54a534bf53...@audiomisc.co.uk, Jim web w...@audiomisc.co.uk wrote: It shows the results I got from the 44.1k output of FF+Flash back in 2009. The 320 aac stream was pretty clean. (Afraid the FFTs were done with simple windows, so a bit frizzy.) Wherever it was being done, any 48k - 44.1k was being done well. I've just found an old email from someone on the 'nemesis' side of the Iplayer development where he told me that - at that time (2009) - the Flash plugin couldn't cope with 48k and downsampled it to 44.1k. So they'd got the servers to generate 44.1k to send as they'd do a better job of it. I'll try to find out if that's still the case. I've ended up deciding to try and write a potted 'technical history' of the iplayer development. So I'll take this elsewhere as not 'on topic' for this list unless people are interested. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
Jim web w...@audiomisc.co.uk wrote: ... but 2.91 gets me 48k files with a different filename syntax Output filenames are entirely dependent on G_ip options; either one sets them explicitly oneself from a mix of template literal data (as I do), or one has a default template applied. For example, the template that my frontend generated for a radio programme fetch a few minutes ago was: $GRAB-SN130-003130 R=nameshort [20150316 Mar16] Sseriesnum Eepisodenum - E=episodetitle 'E=episode' P=pid M=mode Z=duration F=firstbcastdate L=lastbcastdate (the first part is a machine-specific grab sequence number, which makes finding relevant log lines later on simpler, if I need to). This produces a filename like: $GRAB-SN130-003130 R=Brain of Britain [20150316 Mar16] S E - E= 'E=Heat 12, 2015' P=b055g12p M=flashaacstd Z=1680 F=2015-03-16 L=2015-03-16.mp3 [The reason that seriesnum, episodenum, episodetitle and episode are all in there is that over time I've found that different combinations of them have had the values I actually want. Recent changes in derivation of these values may have made this unnecessary. Time will tell. Anyway, once such a file has been fetched I rename it, mainly by deleting the unnecessary parts. It's far easier to delete bits than add them...] The constituent parts of such templates are parsed out of metadata, and there are continuing changes to where metadata is sourced from and how it is parsed. If you haven't already done so you should read the release notes for each successive version of G_ip to see how the values extracted from metadata have changed. See: https://github.com/get-iplayer/get_iplayer/wiki/releasenotes -- Jeremy Nicoll - my opinions are my own. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On Mon, 16 Mar 2015 19:56:47 +, Jeremy Nicoll - ml get_iplayer wrote: Also, eyeballing the contents of the cache files will show that the values there are not always consistent in format (I mean I think the BBC do not always describe successive episodes of the same show in the same way). Agreed there doesn't seem to be a fixed format for anything. Genre can be fun, I'd have expected the data entry for that to be a froma drop down list but it appears to be free form. But I did find reading awkward using NetSurf because the definition of code seems on those pages to cause it to render as black text in a back rectangle! So I may have missed it. I assume this is a NetSurf problem. (This is using the RO NetSurf.) Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). Or use Firefox (on linux). Far easier to highlight the text in theblock with right click drag surely? -- Cheers Dave. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article mpro.nlbfzt001jhy00...@wingsandbeaks.org.uk.invalid, Jeremy Nicoll - ml get_iplayer jn.ml.gti...@wingsandbeaks.org.uk wrote: Jim web w...@audiomisc.co.uk wrote: ... but 2.91 gets me 48k files with a different filename syntax Output filenames are entirely dependent on G_ip options; either one sets them explicitly oneself from a mix of template literal data (as I do), or one has a default template applied. That's fair enough. I assume that means the default has changed between 2.90 and 2.91 as I used the same command line options If you haven't already done so you should read the release notes for each successive version of G_ip to see how the values extracted from metadata have changed. See: https://github.com/get-iplayer/get_iplayer/wiki/releasenotes I didn't find anything on a change in sample rate when I read the notes a while ago. But I did find reading awkward using NetSurf because the definition of code seems on those pages to cause it to render as black text in a black rectangle! So I may have missed it. I assume this is a NetSurf problem. (This is using the RO NetSurf.) However regardless of if it is a change in gip default or not, my real curiosity is over if the 48k is 'upstream' of the 44.1k or not on the servers. I suspect it is, but haven't yet found out. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
Jim web w...@audiomisc.co.uk wrote: In article mpro.nlbfzt001jhy00...@wingsandbeaks.org.uk.invalid, Jeremy Nicoll - ml get_iplayer jn.ml.gti...@wingsandbeaks.org.uk wrote: Output filenames are entirely dependent on G_ip options; either one sets them explicitly oneself from a mix of template literal data (as I do), or one has a default template applied. That's fair enough. I assume that means the default has changed between 2.90 and 2.91 as I used the same command line options IIRC the area that's changed most is the reliability or otherwise over several versions of G_iP of seeing episode numbers in one or other of the 'full episode name' metadata fields. It's worth using --info to explore which fields are set to what values for the programmes you commonly download, to get a better feel (if setting your own template) for which fields are likely to be of most use to you. Also, eyeballing the contents of the cache files will show that the values there are not always consistent in format (I mean I think the BBC do not always describe successive episodes of the same show in the same way). I also see changes in the episode-related fields for some shows as a day passes; it kind-of looks as if in some cases a junior person sets up a programme's entry and someone else refines it later on. Sometimes it's just typos being fixed, but in particular descriptive text quite often changes a lot. But I did find reading awkward using NetSurf because the definition of code seems on those pages to cause it to render as black text in a black rectangle! So I may have missed it. I assume this is a NetSurf problem. (This is using the RO NetSurf.) Maybe when you see black rectangles you should 'view source' (or whatever NS calls it). Or use Firefox (on linux). -- Jeremy Nicoll - my opinions are my own. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
Read the 2.92 release notes at https://github.com/get-iplayer/get_iplayer/wiki/release292 and see if that answers your questions. *From:* Jim Lesurf w...@audiomisc.co.uk *To:* get_iplayer@lists.infradead.org *Date:* Sun, 15 Mar 2015 15:10:48 + (GMT) I've just noticed a curious change and wondered if others have encountered it or know the reason. This is all for *sound radio*, not TV... Until about a week ago the files I fetched using gip all share the 44.1k sample rate I also get using the BBC's Flash plugin with FireFox. However recently I've noticed that some of the radio files have a 48k sample rate. Although the same programs using the Flash + FF RTMP route show up as 44.1k still. I'm still using gip 2.91 as I've not yet updated to 2.92, although I'll do that shortly. Afraid that since I've only recently noticed the above change I don't know if it might have co-incided with my adopting 2.91 or not. In case anyone is curious, I can tell the sample rate because the audio DAC I use indicates it. In general, it switches to 'follow the source'. For radio I use --type=radio --no-tag --pid pid and this seems to get the 'best' results in general. Then allow gip to call avconv to recontain with the usual codec copy settings. Anyone encountered something similar or know why this has started to occur? I'm wondering if the BBC are moving over to 48k sample rate for the radio files and the Flash plugin or FF is causing this to be downsampled. Jim Regards John ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article memo.20150315152937.45...@jeason.cix.co.uk, J K.Eason m...@john-eason.co.uk wrote: Read the 2.92 release notes at https://github.com/get-iplayer/get_iplayer/wiki/release292 and see if that answers your questions. I was reading it this morning. Can't find anything about this on that page. Its curious as I know the BBC used to use 44.1k in the past as I've had access at times. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
In article 14c1e1e896f.10c7dfaf6204929.7982023381937494...@zoho.com, batguano999 batguano...@zoho.com wrote: Until about a week ago the files I fetched using gip all share the 44.1k sample rate Hi I still have radio show files that I downloaded with get_iplayer 3 months ago, MediaInfo shows them as Sampling rate : 48.0 KHz. Strange as all here before a week or two ago are 44.1k. TV files are all 48k thoughout. What command options do you use? Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
Hi All, I'm a bit inexperienced with regard to get_player. All I use it for is to record Bob Harris from BBC Radio 2 each week. Since BBC's earlier changes I have resorted to putting the url in to the 'quick url' box and pressing record. I thought that updates had made this unnecessary but having downloaded 2.91 and now 2.92, it's still is the same. I have tried to change my shortcut to Web PVR Manager but no change. Is there something else that I need to update? Thanks Roger -Original Message- From: Jim Lesurf Sent: Sunday, March 15, 2015 3:10 PM To: get_iplayer@lists.infradead.org Subject: radio sample rates. I've just noticed a curious change and wondered if others have encountered it or know the reason. This is all for *sound radio*, not TV... Until about a week ago the files I fetched using gip all share the 44.1k sample rate I also get using the BBC's Flash plugin with FireFox. However recently I've noticed that some of the radio files have a 48k sample rate. Although the same programs using the Flash + FF RTMP route show up as 44.1k still. I'm still using gip 2.91 as I've not yet updated to 2.92, although I'll do that shortly. Afraid that since I've only recently noticed the above change I don't know if it might have co-incided with my adopting 2.91 or not. In case anyone is curious, I can tell the sample rate because the audio DAC I use indicates it. In general, it switches to 'follow the source'. For radio I use --type=radio --no-tag --pid pid and this seems to get the 'best' results in general. Then allow gip to call avconv to recontain with the usual codec copy settings. Anyone encountered something similar or know why this has started to occur? I'm wondering if the BBC are moving over to 48k sample rate for the radio files and the Flash plugin or FF is causing this to be downsampled. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4800 / Virus Database: 4257/9304 - Release Date: 03/14/15 - No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4800 / Virus Database: 4257/9304 - Release Date: 03/14/15 ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
Jim Lesurf w...@audiomisc.co.uk wrote: This is all for *sound radio*... Ah you traditionalist! Don't you look forward to touch sniff radio? In case anyone is curious, I can tell the sample rate because the audio DAC I use indicates it. In general, it switches to 'follow the source'. So the audio stream isn't just audio data then? I kind-of assumed that you might be able to play a stream at any sampling rate you liked, though that would alter the time taken to play a clip... -- Jeremy Nicoll - my opinions are my own. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
I've done some more checking. The change seems to have occurred when I changed from using 2.90 to 2.91 but I've used the same command options thoughout. At the same point the syntax of the fetched file names has changed for series. e.g. I was getting the 'cosmic quest' (R4x) series in weekly bursts. When using 2.90 the file names didn't have numbers (and are 44.1k). Using 2.91 they have numbers (and are 48k). I also looked back at some early tests I did where the flv isn't converted. They're all 44.1k as well. So this may be a co-incidence, but it looks like a change of behaviour from 2.90 to 2.91. Though why that would alter the sample rate for radio files I don't know. When I get a chance I'll try 2.92. Jim -- Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html Audio Misc http://www.audiomisc.co.uk/index.html ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
- Original Message - From: Jim web w...@audiomisc.co.uk To: get_iplayer@lists.infradead.org Sent: Sunday, March 15, 2015 5:20 PM Subject: Re: radio sample rates. The change seems to have occurred when I changed from using 2.90 to 2.91 but I've used the same command options thoughout. Change of BBC mediaselector perhaps? -- Owen Smith owen.sm...@cantab.net Cambridge, UK ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
I'm not sure if this is connected but two or three weeks ago I was still on v2.89 (I think) and all radio downloading suddenly became unavailable. Things all started working again after I updated to 2.91 which had all the changes in it for the upcoming changes to BBC streaming methods (which had obviously just happened when things stopped for me). Maybe this change to BBC methods is also when the file rates became 48k for you? Tris On 15/03/2015 17:20, Jim web wrote: I've done some more checking. The change seems to have occurred when I changed from using 2.90 to 2.91 but I've used the same command options thoughout. At the same point the syntax of the fetched file names has changed for series. e.g. I was getting the 'cosmic quest' (R4x) series in weekly bursts. When using 2.90 the file names didn't have numbers (and are 44.1k). Using 2.91 they have numbers (and are 48k). I also looked back at some early tests I did where the flv isn't converted. They're all 44.1k as well. So this may be a co-incidence, but it looks like a change of behaviour from 2.90 to 2.91. Though why that would alter the sample rate for radio files I don't know. When I get a chance I'll try 2.92. Jim ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: radio sample rates.
On 2015-03-15 22:23, Tris wrote: I'm not sure if this is connected but two or three weeks ago I was still on v2.89 (I think) and all radio downloading suddenly became unavailable. Things all started working again after I updated to 2.91 which had all the changes in it for the upcoming changes to BBC streaming methods (which had obviously just happened when things stopped for me). Maybe this change to BBC methods is also when the file rates became 48k for you? Tris Audio Factory encodes at the audio's native 48 kHz; this is what the stations operate at internally. 44.1 kHz was a legacy thing and to be honest was unnecessary; after stations went all-digital at 48 kHz it effectively gave us three resampling steps (48 - 44.1 - 48). Now we have zero additional resampling steps (save for anything like commercial music, which will have been resampled once from 44.1 kHz source to 48 kHz). Don't get confused with the HLS bit rates (of which 48 kbps - 48 Kilobits per second - is one). :-) Chris ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
