Radio Modes

[Vangelis forthnet]

On Sun Nov 6 13:42:46 GMT 2016, Mike Casswell wrote:

> I am a little confused

LOL! Aren't we all in this day and age?
Want to migrate to Greece?
Then you'll be VERY confused!...

> I would like to know what is the best mode for my radio downloads.
> (snip)
> I have no prefs currently set for radio mode
> so I will be getting the default, whatever that is.
> (snip)
> Also, I have an impression that one or more
> of the modes are not reliable

Mike, you fail to inform us on the version of GiP
you're currently on, also used OS might be of
further interest; the "default" radio modes have changed
since the previous GiP versions, so I'll assume
you're on the latest version 2.97 (with latest FFmpeg
for your OS), as previous ones are unsupported
(certainly by the developer and the support forum...).

Instead of me repeating the WIKI here (which should be
your first choice for additional help), I'll forward you
to the relative wiki links:

https://github.com/get-iplayer/get_iplayer/wiki/release296#3-combined-dash-haf-and-hlsaac-modes-now-default-for-radio-programmes-dash-preferred

https://github.com/get-iplayer/get_iplayer/wiki/modes#quality-levels

https://github.com/get-iplayer/get_iplayer/wiki/modes#radio

https://github.com/get-iplayer/get_iplayer/wiki/modesref#radio-modes

dash, hlsaac and haf radiomodes (AOD) all represent
segmented streams and are delegated to the
internal (native) perl downloader.

flashaac radiomode has been deprecated
(flagged as about to be removed in the next
major release of GiP), but continues to
function as expected as of this writing;
has the advantage of being resumable
in case of timed-out connections...

> I convert all to 128kbps MP3 to suit the legacy hardware players I use.

Is this done in GiP via the (now deprecated)
--aactomp3 (--mp3) switch?

In previous GiP versions, it used to be
that by default the transncoding (AAC->MP3)
would take place at 128kbpsCBR
no matter the bitrate of the initial source file.

However, in a surprisingly UNADVERTISED change,
which is nowhere to be found in the latest
documentation (only the deprecation status
is communicated towards us in many instances),
the --aactomp3 switch transcodes to an MP3
bitrate matching the AAC bitrate of the source file!

Browsing through the commits log (history),
you won't be able to find easily the specific commit
that implemented that change, because
the commt's title isn't indicative of the change;
shift through "closed issues" in the tracker and you'll hit:

https://github.com/get-iplayer/get_iplayer/issues/227

thus

https://github.com/get-iplayer/get_iplayer/commit/0d5c99c1f0ded4d7c8c9403e58fe63427c48b80c

So, if you are on 2.96+ and using the defaults,
--aactomp3 may already produce MP3 at 320kbps
transcodes...

> I'm sure that it is wasteful given the conversion, as above.

If you are concerned about used bandwidth,
then yes, an .m4a file @320kbpsABR uses
roughly 2.5x the bandwidth (and disk
space) as an .m4a file at 128kbpsABR.

About the conversion itself to MP3 at 128kbpsCBR,
assuming you are doing this outside GiP,
remember you are going from a lossy compression
(AAC) to a second lossy compression (with an
inferior codec, especially at lower bitrates), so
what is described as "generational loss" always
takes place.
>From an audio quality standpoint, it'd be always best
to have the highest-quality-possible source audio file!

I guess I've given you enough to digest already...

Many regards,
Vangelis.