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...)
_______________________________________________
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer
