RE: [AVT] File format for EVRC/SMV vocoder

[Harinath Garudadri <[e-mail]>]

At 08:04 AM 3/17/2003 +0900, Jae-Yong Lee wrote:
>Hi all,
>
>To my best knowledge, QT is supporting QCELP "codec"
>(in QT file format), not the .qcp file format.

I was able to create a qcp file in my Eudora client and send to someone who 
uses a different email client. When he launched Quicktime for this file, he 
was able to play the file as is and also convert the file to .mov format. 
Here is the .mov version of the file for those who have Quicktime.


>Jay
>
> >
> > Hi, Randy,
> >
> > Are there any intellectual property issues with the qcp format?
> >
> > Also, were the interoperable implementations of the qcp format really
> > done independently?  My understanding is that Eudora is a Qualcomm
> > product and that Apple acted merely as an integrator and distributer
> > of the PureVoice technology from Qualcomm.  If these implementations
> > are not independent it may be misleading for you to talk about
> > interoperability.
> >
> > -Pete
> >
> >
> > Randall Gellens writes:
> >  > At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote:
> >  >
> >  > >  OK, but why has not this issue been brought up earlier?
> >  >
> >  > Because of an unfortunate oversight.  Neither myself nor the other
> >  > authors of the evrc/smv draft were aware of the qcp
> > format.  I very
> >  > much regret this.  At the time we were working on the
> > evrc/smv draft,
> >  > we specified a file format to make the draft complete.
> > Had we been
> >  > aware of an existing format that was currently being used to
> >  > interoperably exchange vocoder frames, I'm sure it would have been
> >  > considered instead of inventing something new.
> >  >
> >  > >   The EVRC/SMV
> >  > >  format work in AVT has been going on for a long time,
> > and therefore one
> >  > >  can question whether it is correct (from a procedural
> > point of view) to
> >  > >  suddenly not use what has been developed in this WG,
> > but use something
> >  > >  defined elsewhere. IETF standardization is usually an
> > engineering
> >  > >  process, not rubber-stamping of already deployed
> > technical solutions.
> >  >
> >  > When I learned of the qcp format, my suggestion for how to proceed
> >  > was to register a new mime type (audio/qcp) so as to not risk
> >  > delaying the evrc draft.  (As one of the authors of that draft, I
> >  > have no desire to delay it at all.)  This is what the current qcp
> >  > draft says.  However, I was told to do the technically
> > correct thing
> >  > instead.
> >  >
> >  > >  Note that I am not aware of all the details in this
> > matter, but what
> >  > >  has been communicated on the list does not provide
> > enough material for
> >  > >  motivating what has been proposed. "We have already
> > deployed this
> >  > >  alternative format while you were trying to agree on a
> > standard, and
> >  > >  now we think you should use our format instead since it is more
> >  > >  widely deployed" is a rather strange way of arguing in standards
> >  > >  development, I think.
> >  >
> >  > The QCP format was in deployment when we started working on the
> >  > evrc/smv draft, but neither I not the other authors were aware of
> >  > this.  It's not the case that the qcp format was deployed
> > afterwards
> >  > or in parallel, in an attempt to circumvent process.
> >  >
> >  > The question now is how best to proceed.  As I said, my initial
> >  > suggestion was to take the easy path of not deleting the
> > file format
> >  > from the evrc/smv draft, and instead to use a kludge of
> > registering a
> >  > new mime type for the qcp file format.
> >
> >

Hari Garudadri (from Vancouver, B.C.)
mobile : [phone]