[Hpr] "HPR Dodgers, in the 21th-and-a-half centuryyyyy....." (Future HPR features)
epicanis+hpr at dogphilosophy.net
Mon Feb 9 16:14:56 PST 2015
> While we both may love metadata, we do need to keep in mind our mission
> of ensuring the maximum audience for HPR. To that end it explains why we
> still have a mp3 feed at all.
No argument there - actually even LESS of an argument from me than as recently
as last year, now that I believe there are ways of working around the
remaining Intellectual Precious issues (there'll be an HPR episode forthcoming
about this, I promise!)
I should point out that although I wouldn't shed any tears if HPR actually did
drop mp3, I'm not one of the participants who has actually advocated that.
> But keeping a simple mp3 file does not
> mean we cannot experiment with new features. There are loads of ways
> where we can move with the times. eg:
> - sending out a lower bitrate mp3, swapping the spx to opus
This may seem strange, but for mp3 what I'd personally advocate involves
sending a HIGHER bitrate mp3...
In order to be most compatible with the original standard and bypass the
remaining patents completely at the same time, some of the later features of
mp3 encoders ought to be switched off (constant bitrate rather than variable
or average, for example). In order to maintain similar quality, the bitrate
may need to be bumped up to 80kbps or 96kbps (if the quality at 64kbps with
the maximum-compatibility/legally-clear settings drops too much).
I'm trying to find the reference again, but years ago I would swear I saw a
guide to making the "most compatible" mp3 files that suggested only producing
STEREO (counterintuitively) files, as apparently some of the original mp3
players assumed that all files would be "music" and therefore hard-coded to
assume 2 channels. I think this would need to be "real" stereo (two identical
tracks in the case of HPR's mono source material) rather than "joint stereo"
if that was the case, though. I'm not sure
if this is any more of a compatibility problem than, say, id3 tags. I've never
actually heard of an mp3 player that had trouble with mono files, but on the
other hand I *did* once run into an ogg-vorbis-supporting mp3 player that
would lock up on mono .ogg files but play stereo ones.
I might also suggest dropping ID3v2.3 entirely and only including ID3v1, if
anything. HPR's currently-used minimal tag set is the same handful used in
ID3v1, except for the limited space for ID3v1 "comments" which could just be
summarily truncated or left out.) ID3v1 being a single frame stuck at then end
of the file, even if it's played on a REALLY bad old player, it should at
least play the file before choking. Alternatively, dump all the metadata
entirely, which would be a minor inconvenience for some listeners but would
increase the range of older players that could handle the files. I personally
wouldn't go to that extreme though.
> - adding links to the enhanced media
> - providing a experimental feature rss feed.
> Running an experimental feed would allow you to determine which players
> have issues and which don't. Additionally as the feed would be opt in,
> the participants would have motivation to report issues to you. This way
> we could build a database of known formats with known players. Something
> which would be of benefit to the podcasting community and would
> definitely meet our goal of sharing knowledge.
An experimental feed would be nice, especially if we can get more than just me
interested in doing experiments with it (and participating in the testing).
It could double as "the opus feed" until the time when we can replace .spx
with it. I like that idea.
More information about the Hpr