Bit rate from --aactomp3

[Vangelis forthnet]

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 2>&1

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.