Re: [codec] Format for the codec specification

[Jean-Marc Valin <[e-mail]>]

On 10-09-28 10:28 PM, Stephen Botzko wrote:
> Though I've never heard clear reasons, it seems to me that the
> "decoder-only" folks are mostly focused on applications with a massive
> encoder/decoder imbalance, while the "encoder and decoder" folks tend to
> be focused on applications with equal numbers of encoder and decoders.

I think the main logic here is that when your codec leaves very few 
degrees of freedom to the encoder (the extreme case being an ADPCM 
codec, but CELP generally falls into that as well), then it's fine to 
have the encoder being normative. Voice codecs have typically fallen 
into that category because they were smaller than music codecs. Where I 
think it makes sense to *not* have a normative encoder is when the 
encoder has a lot of freedom. For example, an MP3 encoder has the 
freedom to define it's own psycho acoustic model, decide when to use 
short windows, and so on. And we have seen just how much MP3 encoders 
have improved over the years. This would have been impossible if the 
encoder had been specified normatively.

I would say that the current codec we have here is closer to MP3 than it 
is to (e.g.) G.729. There is a *lot* of freedom in the encoder. Not only 
in how to switch between its three main modes (SILK, CELT, hybrid), but 
within each of these modes. Because of that, I believe that encoders 
will continue to evolve and get better over time, just like they did for 
MP3.

> So I am thinking that making the encoder normative makes sense, given
> that this application is centered on VOIP, so we want to ensure
> consistent quality in all endpoints.

I don't really see a problem with quality. Most implementors will likely 
end up using either the reference encoder, or improvement that got made 
over time. I don't think anyone will complain with having better quality 
than the standard specified.

Cheers,

	Jean-Marc