Quality Variation

[Vangelis forthnet]

On Mon Oct 3 16:35:05 BST 2011, dinkypumpkin wrote:

>...but the Mon and Wed source audio is probably still the same 56Kbps AAC.

...Not only that, but the encoder used is HE-AACv1 (AAC LC with SBR, also 
known as aacPlus/AAC+, see more at:
 http://en.wikipedia.org/wiki/HE-AAC). This type of encodes is currently 
used by The BBC for Listen Again content
from BBC World Service and even there the bitrate used is 64kbpsVBR.
 The problem with  HE-AACv1 (/2) is that your standalone audio player must 
support SBR (& PS) proper decoding,
so that it outputs audio with the proper sample rate (e.g. 44,100 Hz) (and 
in stereo, in the case of PS) and not half of it
(i.e. 22,050 Hz) (nor in mono). Recent versions of WMP, Winamp, RealPlayer, 
NeroShowtime, FFplay, iTunes & others
(sorry, I can only speak about Win systems!) do so correctly.
 The M4As produced by get_iplayer come from raw ADTS .aac files demuxed from 
FLV containers & muxed back into
the MP4 container, using FFmpeg for the job:

ffmpeg -i raw.aac -acodec copy -absf aac_adtstoasc radio.m4a

 FFmpeg has no way that I know of (perhaps our "own" FFmpeg expert, bat 
guano, can advise on this...) to flag the raw
 aac file as an SBR encode; MediaInfo correctly reports this, but at least 
two players on my system, i.e. latest Quicktime
& (not so recent) MPC-HC playback only the AAC LC part of the audio (SR 
22.05 kHz), resulting in poor listening experience.
One quick workaround I use is demux the FFmpeg generated .m4a, using either 
mp4box or FFmpeg:

 MP4Box -raw 1 "radio.m4a"
ffmpeg -i "radio.m4a" -f adts -vn -acodec copy "radio.aac"

and then mux this back into an .mp4 container using mp4box with the -sbr 
(and -ps) option:

MP4Box -add "radio.aac:lang=en:sbr:mpeg4" -itags tool="mp4box" "radio.m4a"

(excerpts from mp4box documentation:
-sbr : forces importing the AAC-ADTS file as AAC SBR (aka HE-AAC, aka 
aacPlus)
with backward compatible signaling (eg non SBR aware decoders should play 
the file).
-ps : forces importing the AAC-ADTS file as backward compatible signaling of 
AAC-PS).

This way, ALL my BBC HE-AAC radio downloads play correctly on ALL the 
players on my system. Please take note that as a non-UK user,
unless I find a working (free) UK proxy or connect through a UK VPN, I am 
solely exposed to HE-AACv2 audio streams, as far as the National
Radio Stations (1, 1x, 2, 3, 4, 4x, 5l, 6) are concerned.
 Now, returning back to the matter raised by the OP of this thread, normal 
bandwidth (UK only) BBC Radio 3 Listen Again encodes
(delivered through rtmp Flash-based protocol) normally use AAC LC 
@192kbpsVBR. If one wishes to transcode to MP3 from "within"
get_iplayer using the --aactomp3 option, one ends up with an 128kbpsCBR mp3 
encode, with a considerable loss of quality.
I am currently on a patched 2.79 script, I read though in the mailing list 
about the addition of the --mp3vbr option in v2.80;
this uses LAME (uncertain whether it uses libmp3lame inside FFmpeg or the 
standalone version - I haven't installed the latter).
At what value should the N parameter be set for these Radio 3 downloads for 
optimum results? (Sorry, I'm not familiar with CLI LAME,
I mostly use GUIs and choose CBR).
My portable player is very "naggy" about VBR mp3s, what I ideally want is 
some patch for get_iplayer to tell it to produce a (at least) 192kbpsCBR
mp3 file when it deals with "flashaacstd" Radio 3 files in conjuction with 
the  --aactomp3 option. This, of course, is a niche situation, I currently 
transcode
the m4a file at a second stage with FFmpeg (it can export most mp4 metadata 
to the mp3 file!).

Greetings, Vangelis

(Apologies for the length of the mail...)