Re: Bit rate from --aactomp3
In article EC2BDF4A6709483381C0695921963269@vasonote, Vangelis
forthnet
northmed...@the.forthnet.gr wrote:
[Slightly OT content!]
On Sun May 31 17:16:28 BST 2015, Jim web wrote:
when I have had to transcode aac or mp3 I convert it to LPCM (wave)
or flac so I'm losing as little as possible. In effect the result
sounds like the source. Has its flaws, but without additional damage.
Could be highly impracticle though, at times... :-{ I do own an old and
cheap portable audio player, that can only cope with MP3 (has to be
CBR), WMA WAV; its internal Flash Memory is only 1GB, its write
speed barely borders 1MBps.
Understood. :-/
FWIW I did try a 'net radio' a few years ago. One of the brand-name
'badged' ones with a well known name on the front that tries to present
itself to the user as a 'radio'. I found it a PITA to use for various
reasons. I don't have any 'portable' music players because again, some
years ago I simply wasn't interested in any of them.
In my case I tend to want to sit and listen carefully. Poor sound tends to
irritate me enough to switch off the audio unless the message is vital.
Things are different now because some very high quality portable devices
are available. (At a price!) But I still prefer speakers to headphones for
listening - unless I'm editing something and need to focus on details like
tiny clicks rather than the music.
I'm wary of 'net radios' 'streamers' etc for the reasons the recent Audio
Factory changes demonstrate. That the end user tends to lose control of
being able to go on listening, or being able to get the quality they want.
When you buy a net radio, etc, your only contract is with the retailer. Not
the BBC, not the maker, not any 'service aggrigator', etc. Its *not* a
radio. Unless and until the law and practice catches up with this offloaded
responsibility I'm inclined to avoid such devices.
The practical problem, of course, is that this is a council of perfection,
and in the real world people find net radios, streamers, portable devices,
etc, very handy. So it makes sense to buy and use them. But I guess we have
to accept that any such device has inbuilt 'planned obsolencence' and may
need replacing in little more than a few years.
Internet 'broadcasting' is an area where things are rapidly developing, and
that means changes are inevitable as well as sometimes impossible to
predict accurately in advance.
Years ago whenever I bought a new LP in the shop I used to plan what time I
could return in a few days because it was (almost always) faulty.
(Pressings were lousy back then.) Maybe when people buy devices like net
radios, etc, now, they should have this in mind, but with a slightly longer
and vaguer timescale!
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: Bit rate from --aactomp3
In article 97444A64ED014661A5C9CBA90C579E3F@vasonote, Vangelis forthnet northmed...@the.forthnet.gr wrote: On Sun May 31 11:22:16 BST 2015, RS wrote: Is there any way... to get get_iplayer to respect the --radiomode flashaaclow option when --aactomp3 is used? Hello Richard... Short answer: NO You may refer to this past post of mine: http://lists.infradead.org/pipermail/get_iplayer/2013-July/004622.html The main change since then is that with the Audio Factory overhaul, the flashaaclow (as well as the hlsaaclow) radiomode is now encoded in HE-AACv1 (not v2, so no Parametric Stereo) and the SR is 48kHz (previously at 44.1kHz). On Sun May 31 12:27:41 BST 2015, RS wrote: Once it has been compressed to 48kbit/s, any higher frequency information is gone. It cannot be retrieved by converting at a higher bit rate. We do have our own audio expert in this list (Jim web), who graces us with most excellent posts, and I stand to be corrected, but what you state is true for the first encode from the original uncompressed file. FWIW a low bitrate doesn't *have* to mean that any higher frequency information is gone. It all depends on the 'settings' for the judgements the lossy encoder was given to apply when thinning out the data. What will have happened is a loss of detail. That said, the BBC do in my experience tend to preferentially discard 'high frequency' details as that is felt to have less impact than losing the same amount of data from low frequencies. In effect, they target the bits allocated to the frequency range where our ears notice problems more easily. What is certainly true is that you can't get back what was discarded. As a general rule, I'd avoid transcoding one lossy format into another. If you have to, I'd go for a higher rate for the 'destination' to try and avoid more loss as far as possible. Particularly if you're going from aac to mp3. However this isn't really a matter of improving the result but minimising further harm. :-) I can't comment on if 128 kbps mp3 is 'good enough' for avoiding more harm to 48 kbps aac as I've never tried it. Not sure I'd want to. 8-] In practice when I have had to transcode aac or mp3 I convert it to LPCM (wave) or flac so I'm losing as little as possible. In effect the result sounds like the source. Has its flaws, but without additional damage. I'm not sure from the earlier postings, but I guess the problem is that mp3 is needed by the end-device (player) because it can't render aac. If so, I'd go for a high rate for the mp3 even though it may seem daft. But then personally I'd probably bin the mp3 device and get one that can play aac. 8-] I don't know about the podcasts, though, as I haven't tried them. I just get the programs I want as broadcast. Sorry if I've misunderstood the situation. 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: Bit rate from --aactomp3
On Sun May 31 11:22:16 BST 2015, RS wrote:
Is there any way... to get get_iplayer to respect
the --radiomode flashaaclow option when --aactomp3 is used?
Hello Richard...
Short answer: NO
You may refer to this past post of mine:
http://lists.infradead.org/pipermail/get_iplayer/2013-July/004622.html
The main change since then is that with the
Audio Factory overhaul, the flashaaclow (as well as the hlsaaclow)
radiomode is now encoded in HE-AACv1 (not v2, so no Parametric Stereo)
and the SR is 48kHz (previously at 44.1kHz).
On Sun May 31 12:27:41 BST 2015, RS wrote:
Once it has been compressed to 48kbit/s,
any higher frequency information is gone.
It cannot be retrieved by converting
at a higher bit rate.
We do have our own audio expert in this list
(Jim web), who graces us with most excellent
posts, and I stand to be corrected, but what you
state is true for the first encode from
the original uncompressed file.
Of course a higher bitrate can't generate
additional detail if it's not there in the first place,
but it should be taken into account
when different encoders are being used.
--(aac)mp3 transcodes the iplayer file
(HE-AACv1 @48kbpsABR, SR=48kHz)
to an MP3 file, using FFmpeg's (avconv's)
libmp3lame library, so from a lossy format
to another lossy one (generational loss).
The Audio Factory team use the
Fraunhofer AAC Encoder for producing
their files, which is very efficient at low bitrates.
MP3 Lame, on the other hand, is not so good
at low bitrates, so if you'd want to preserve as
much as possible the overall audio quality present
in the M4A file, you'd adjust accordingly the
transcoding bitrate to MP3 (if quality rather than
file size is your concern).
For spoken content, I've found that 64kbps MP3
pleases my ears, however for music (R1, R2 etc.),
96kbps (or the standard 128kbps GiP produces)
might be needed...
the conversion to .mp3 at 128kbit/s takes a lot longer
than the --radiomode flashaaclow .m4a download at 48kbit/s.
The transcoding conversion speed relies heavily upon your
own setup: OS, CPU, ffmpeg binary, disk write speeds etc.
The bitrate of the conversion should not affect much
the overall transcoding speed (even if reduced from 128 to 48).
You can't really compare transcoding (a CPU intensive
process) to the rtmpdump download in the same sentence -
it's like the proverbial apples vs oranges comparison :-)
when tv programmes are converted (by default) from .flv to .mp4,
the .mp4 bit rate is similar to the .flv bit rate.
This is called Remuxing and it's a simple change of file container:
from FLV to MP4. No change of format (re- /trans-coding ) of the
elementary video audio streams takes place - hence it's a very
quick and resource-friendly procedure!
It is difficult to see what parameters get_iplayer passes to ffmpeg
If you're using the command prompt window, you can always save its output
to a .txt file via stream redirection operators:
get_iplayer --type=radio --pid=b05wnjjh --modes=flashaac --mp3 --force
LOG.txt 21
and then inspect the LOG:
Output #0, mp3, to 'D:\Vangelis\iPlayer
Recordings\Bells_on_Sunday_-_31_05_2015_b05wnjjh_default.partial.mp3':
Stream #0:0: Audio: mp3 (libmp3lame), 48000 Hz, stereo, fltp, 128 kb/s
If you want more detailed logs, include the --verbose switch!
Plus, if you are agile with a code editor, you can browse the
main script itself at ca. line 10265 (for vanilla 2.92 script):
---
# Convert flv to aac/mp4a/mp3 }
elsif ( $mode =~ /flashaac/ ) {
# transcode to MP3 if directed. If mp3vbr is not set then perform CBR.
if ( $opt-{aactomp3} ) {
my @br_opts = ('-ab', '128k');
if ( $opt-{mp3vbr} =~ /^\d$/ ) {
@br_opts = ('-aq', $opt-{mp3vbr});
}
@cmd = (
$bin-{ffmpeg},
@{ $binopts-{ffmpeg} },
'-i', $file_tmp,
'-vn',
'-acodec', 'libmp3lame', '-ac', '2', @br_opts,
@ffmpeg_opts,
'-y', $prog-{filepart},
---
By changing line
my @br_opts = ('-ab', '128k');
to
my @br_opts = ('-ab', '48k');
you can accomplish what you wish - 48kbpsMP3 transcodes with --mp3;
expect detectable audio degradation!
DISCLAIMER: Take preventive measures for restoring
the original script, if you mess anything up!
Regards,
Vangelis.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bit rate from --aactomp3
On 31 May 2015 23:54:18 Vangelis forthnet northmed...@the.forthnet.gr
wrote:
[Slightly OT content!]
On Sun May 31 17:16:28 BST 2015, Jim web wrote:
when I have had to transcode aac or mp3
I convert it to LPCM (wave) or flac
so I'm losing as little as possible.
In effect the result sounds like the source.
Has its flaws, but without additional damage.
Could be highly impracticle though, at times... :-{
I do own an old and cheap portable audio player,
that can only cope with MP3 (has to be CBR),
WMA WAV; its internal Flash Memory is only
1GB, its write speed barely borders 1MBps.
When flashaudio radiomode was available for
roughly all BBC Radio, all was fine. Then
National Radios changed to flashaac, flashaudio
left only for Nations Radio (which was true until
very recently, just before the Audio Factory changes...).
I try to avoid transcoding as much as possible,
so for National Radio I turned to the compatible
wma radiomodes (which I downloaded via
specialised software, not GiP, because mplayer,
used inside GiP to dump wma, was very fickle...).
Now the WMA modes are also gone, I have to either
transcode flashaac radiomodes or - as you said -
bin my otherwise working player...
Transcoding (or decoding?) to WAV is simply
out of the question for me, because either the huge
file size of the uncompressed audio file would not fit
inside the memory storage (a 3hr long programme
would be 1.5 GiB) and even if it would fit, it
would take excrutiatingly long to transfer from my
laptop at 1MBps!...
For your setup I'd batch transcode (I'd do jt manually, but that's just me)
to 64 kbps mono MP3 from the source files. That'll give you effective 128
kbps quality with basically zero significant difference through the
transcode. Not ideal, but probably the best you can do in your setup to
accommodate your device.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bit rate from --aactomp3
[Slightly OT content!]
On Sun May 31 17:16:28 BST 2015, Jim web wrote:
when I have had to transcode aac or mp3
I convert it to LPCM (wave) or flac
so I'm losing as little as possible.
In effect the result sounds like the source.
Has its flaws, but without additional damage.
Could be highly impracticle though, at times... :-{
I do own an old and cheap portable audio player,
that can only cope with MP3 (has to be CBR),
WMA WAV; its internal Flash Memory is only
1GB, its write speed barely borders 1MBps.
When flashaudio radiomode was available for
roughly all BBC Radio, all was fine. Then
National Radios changed to flashaac, flashaudio
left only for Nations Radio (which was true until
very recently, just before the Audio Factory changes...).
I try to avoid transcoding as much as possible,
so for National Radio I turned to the compatible
wma radiomodes (which I downloaded via
specialised software, not GiP, because mplayer,
used inside GiP to dump wma, was very fickle...).
Now the WMA modes are also gone, I have to either
transcode flashaac radiomodes or - as you said -
bin my otherwise working player...
Transcoding (or decoding?) to WAV is simply
out of the question for me, because either the huge
file size of the uncompressed audio file would not fit
inside the memory storage (a 3hr long programme
would be 1.5 GiB) and even if it would fit, it
would take excrutiatingly long to transfer from my
laptop at 1MBps!...
Cheers,
V.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bit rate from --aactomp3
Some podcasts, such as Moneybox, are at 48kbit/s . It is adequate for mono speech programmes, especially if it is to be listened to on a cheap mp3 player while walking. Once it has been compressed to 48kbit/s, any higher frequency information is gone. It cannot be retrieved by converting at a higher bit rate. Also the conversion to .mp3 at 128kbit/s takes a lot longer than the --radiomode flashaaclow .m4a download at 48kbit/s. It is difficult to see what parameters get_iplayer passes to ffmpeg. As far as I have been aware, when tv programmes are converted (by default) from .flv to .mp4, the .mp4 bit rate is similar to the .flv bit rate. This is the first time I have used get_iplayer for a radio programme, so I cannot say whether the increase of bit rate in --aactomp3 is a new problem. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Bit rate from --aactomp3
Is there any way (apart from running ffmpeg manually) to get get_iplayer to respect the --radiomode flashaaclow option when --aactomp3 is used? In get_iplayer v2.91 --radiomode flashaaclow causes the download to be at 48kbit/s as expected. The --aactomp3 conversion then changes the bit rate to 128kbit/s. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bit rate from --aactomp3
Space considerations aside, why would you want to do that? A transcode to a 128 kbps MP3 will sound bad enough, never mind adhering to a 48 kbps bit rate. IMO the only way it might sound even barely listenable would be if the resultant MP3 was a mono transcode, then you're not far from quality of a 128 stereo. Apologies if I didn't get the gist of your question! Chris On 31 May 2015 11:28:44 RS richard...@zoho.com wrote: Is there any way (apart from running ffmpeg manually) to get get_iplayer to respect the --radiomode flashaaclow option when --aactomp3 is used? In get_iplayer v2.91 --radiomode flashaaclow causes the download to be at 48kbit/s as expected. The --aactomp3 conversion then changes the bit rate to 128kbit/s. ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
Re: Bit rate from --aactomp3
On 31/05/2015 12:27, RS wrote: It is difficult to see what parameters get_iplayer passes to ffmpeg. The ability get_iplayer has to convert from aac to mp3 is somewhat of an anomoly. It's been generally stated in the past that using a more specialist piece of software to perform the conversion would be preferrable. That said, there exists the ability to control the bitrate of the conversion via the --mp3vbr command. Commands range from 0 to 9 (0 being the 'best'). More info can be found in this forum thread: https://squarepenguin.co.uk/forums/topic/radio-bitrates/ ...and in the Options Wiki (ctrl+f 'mp3vbr'): https://squarepenguin.co.uk/wiki/options/ If you can't view those pages for any reason, the relevant text relating to mp3vbr from the Options Wiki is: --mp3vbr Set LAME VBR mode to N (0 to 9) for AAC transcoding. 0 = target bitrate 245 Kbit/s, 9 = target bitrate 65 Kbit/s (requires --aactomp3). Applied only to radio programmes. A full example command might look like: get_iplayer --type=radio --get Late Junction --aactomp3 --mp3vbr=0 ___ get_iplayer mailing list get_iplayer@lists.infradead.org http://lists.infradead.org/mailman/listinfo/get_iplayer
