Subject: [codec] Transparency or intelligibility?

From: Gregory Maxwell <[email-masked]>
Date: Tue, 10 Nov 2009 06:45:42 -0800

One source of disagreement over requirements which I've seen crop up with respect to audio
codecs arises out of what appears to be a lack of agreement on the end goal: Is the expectation 
that the result will be transparent, or that it will be merely intelligible and/or 'good sounding'?

By transparent I mean something roughly like "an experienced listener is unable to distinguish in a
blind listening test even with material selected to be especially challenging for the codec".

While it's is not possible to deliver transparency without intelligibility, it is possible to deliver excellent
intelligibility without a hope of transparency.   So optimizing for one vs the other can lead to different
engineering trade-offs.

For example,  a 7kHz low-pass will produce speech with perfect intelligibility but at the same time
would have absolutely no hope of being transparent.  If you had a goal of even near transparency
you would probably not even consider a codec with a low-pass lower than about 18kHz or so.
(For general audio— for pure speech and adult listeners you could possibly go a bit lower but 7kHz is
far too low)

It was my thought that for the transmission of sound typical Internet bandwidths are high enough that
we really have little excuse but to provide transparency under good operating conditions.

Of course, during levels of high loss or congestion transparency will not be possible and in that case
a codec should maintain intelligibility under adverse conditions and that should be an absolute
requirement too, but in the normal case transparency should be expected.

Is this thinking consistent with the thoughts of other working group participants?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 10 Nov 2009 17:20:36 +0100 (CET)

> Is this thinking consistent with the thoughts of other working group 

I agree wholly that whatever we come up with should have excellent 
(transparent) sound quality when conditions are good, and should be able 
to be intelligible when conditions are really bad.

I would like to have the application tell the system whether delay is 
important or not, if delay is not important then delay can be traded for 
higher sound quality, if delay is important then quality can be traded for 
intelligibility.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Koen Vos <[email-masked]>
Date: Tue, 10 Nov 2009 08:38:12 -0800

Quoting Mikael Abrahamsson:
> I would like to have the application tell the system whether delay  
> is important or not, if delay is not important then delay can be  
> traded for higher sound quality, if delay is important then quality  
> can be traded for intelligibility.

We're addressing a codec for real-time communications, so delay is  
important by definition. For applications where delay is not  
important, good solutions already exist - Ogg-Vorbis for example.

There may be subtle trade-offs between delay and quality, e.g with  
network jitter, where additional jitter buffer delay can reduce the  
effective packet loss rate. That seems like a design choice for the  
jitter buffer however.

koen.