[BC] Multiple IBOC codexes /was/ Listening t ests... how valid?

Phil Alexander dynotherm
Sun Oct 23 10:05:49 CDT 2005


On 23 Oct 2005 at 13:43, Peter Smerdon wrote:


> Eek! - it's the "marketplace" decision all over again.
> "let the best Codex (sic) Win" - or the best lawyers win??

There is a significant difference between today's software
world and the hardware dominated world that brought the
"marketplace decision" debacle.

With a mandated codec flag in the IBOC header, receiver
codec selection could be fully transparent to the listener
except that some stations using the beat codecs might
sound better. IOW a TRUE marketplace decision is easily
possible.

There are two stumbling blocks to this. AFAIK although
one was advocated by some as recently as last spring's
NAB show, NRSC-5 does not include any sort of codec flag.
Second, assuming codec evolution, a transparent method
of stored algorithms updating is needed in the sets for
that purpose and other advances none of us can foresee at
this point. To be future compatible, IBOC needs a foolproof
OTA update/upgrade mechanism.

It appears that Ibiquity has no inclination toward either
of these keys to the future. In fact, it appears they
would quite happily be the sole custodians of a closed
end, dead end system they can milk for fees for the next
twenty years or so.

I doubt that the long term future of aural broadcasting
beyond that time is of further interest to them, however
their shortsighted approach may telescope their future
into an even shorter time frame.

Wouldn't it be interesting to see a groundswell demand
for a "quiet" "good" band like days of old about half
way through the Ibiquity "transition?" I'm sure they
could count on support from the engineering community,
the groundswellers I mean, not Ibiquity who has totally
ignored the true engineering aspects (IMHO) of IBOC
deployment and made no attempt AFAIK to garner support 
from the engineering community outside the NRSC.

However, popular groundswell is as dead as popular
support for our media, so I guess I'll go back to sleep
now. Still if it happened ... think of the fun. <g>


Phil Alexander, CSRE, AMD
Broadcast Engineering Services and Technology 
(a Div. of Advanced Parts Corporation) 
Ph. (317) 335-2065   FAX (317) 335-9037





-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.12.4/143 - Release Date: 10/19/05



More information about the Broadcast mailing list