[BC] IBOC in trouble?

[Phil Alexander]

Mike,

The problem is comments addressing the Ibiquity single source issue, IOW a
plea for multiple standards, are essentially "out of order" at this stage 
and would be ignored although I suppose they could be filed as a reply to 
Hardis who said multiple standards should not be done for the sake of 
portability. It's possible he's unaware of what T-I has done, but that's 
unlikely, so I'm genuinely puzzled by his comment in that regard.

However, if I sort out a real mess successfully during the next week,
I may take a swing at it. Or ... if you want to come down here and
fix a few thing while I'm writing .... ;-)


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

On 27 Jul 2005 at 6:38, Mike McCarthy wrote:

> Phil,
> 
> You should file these as reply comments to both the NIST and MS comments.
> 
> At 11:19 PM 7/26/2005 -0500, you wrote:
> >On 26 Jul 2005 at 21:31, Barry McLarnon wrote:
> >
> > > Then read this one by Jonathon Hardis of NIST, who, unlike Microsoft,
> > > has no dog in this race:
> > >
> > > 
> > http://gullfoss2.fcc.gov/prod/ecfs/retrieve.cgi?native_or_pdf=pdf&id_document=6518010460
> > >
> > > This is a tremendous piece of work that eclipses all the other filings
> > > on NRSC-5, and yet the online radio mags haven't even mentioned it.
> > > I wonder why...
> >
> >It is indeed a great work, and carefully lays out the battleground for
> >the litigation that is almost sure to follow if NRSC-5 is codified
> >without change.
> >
> >In hindsight I believe the FCC erred in three areas in formulation of
> >the policy for a standard for IBOC. (It's pointless to debate the wisdom
> >of IBOC one more time IMHO. It is what it is and few including myself are
> >happy with it.)
> >
> >1. They treated both the modulation/demod schemes and the codec essentially
> >         as hardware devices that could not be changed, when, in fact, 
> > they are
> >         essentially software or firmware that could be changed by means 
> > common
> >         in the computer world
> >
> >2. Not realizing the potential for change demonstrated by computer technology,
> >         they did not require a means for upgrading the receiver 
> > demodulation system
> >         via OTA transmission.
> >
> >3. They also failed to require a means for similarly upgrading the codec, and
> >         did not require codec identification that would allow multiple 
> > codecs in
> >         the future.
> >
> >Considering the 25 year record of evolution in computer technology it is
> >reasonable to expect significant evolution in DAB, but as NRSC-5 now stands,
> >there is no provision for it, except by never ending transitions of
> >receiver hardware.
> >
> >Hopefully, the Commission will correct at least some of their errors to
> >prevent the litigation that will likely arise from the comments by
> >Mr. Hardis and Microsoft.
> >
> >An idle thought: I wonder if Ibiquity has the RIGHT to reveal any of the
> >codec information? IOW, did they simply buy the use of a private label
> >codec with just enough changes to make it non-compatible with AAC+ ???
> >
> >Perhaps, now, Ibiquity will get their ducks in a row before IBOC stalls
> >and they face bankruptcy. This would only set deployment back about a
> >year IMHO, because Chapter 7 is unlikely, but it would mean a new
> >management team would enter the picture. Wouldn't that be nice? <g>
> >
> >
> >Phil Alexander, CSRE, AMD



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 7/28/05