Re: [codec] requirements #8 (new): Sample rates?

["Pascal Pochol" <[e-mail]>]

Gregory,

> I'm very concerned that some people may believe that 44.1k is just
> another checkbox that can be added without cost or much consideration.

I don't think that's the case. We all know that if it was easy to handle
every sample rate imaginable that it would have been done already.

Again talking about our personal case which has nothing to do with VOIP we
have a lot of audio data handed to us in 44.1Khz and 22.5Khz. Other popular
rates for us are 16Khz and 8Khz which are already handled if I'm not
mistaken by opus? Easily derived from 48khz. Before using speex last year I
had never encountered anything at 32khz. It'll probably a few more years
before we're allowed to use cpus powerful enough and enough ram to handle
even 32khz. For now we'll most likely still down sample everything to
16khz. The artists don't like programmers massaging their data but they
understand technical limitations so for now we're in luck.

> I support Jean Marc's option (1), which I think allows us to have our
> cake and eat it too. It's the closest thing to a "cost free" option
> that I think we're going to get. This option basically separates the
> codec into two profiles, one which imposes sampling rate restrictions
> in exchange for many important advantages, and one which does not, but
> misses the advantages.

Out of curiosity, what would be the advantages that we miss in such case?

> JM's option (2) would also work. But I don't like the idea of the
> market confusion created by a totally separate codec which has
> significant overlap with Opus, but isn't Opus.  Basically, I think it's
> silly for part of the working group's output to compete with itself.
> I'd prefer to just have "Opus" and "Opus-custom" or whatever.

I totally agree.

> I expect that most users which care about the 'custom' modes are doing
> other specialized things and won't be expected to ever interop with a
> random Opus phone except (maybe) via a gateway, and that most of them
> won't even speak RTP— so the separation shouldn't even make much
> difference to them at all.

Absolutely right In our case we'd be using for things that wouldn't need to
interact with any other devices actually. We use it as a very efficient way
to decode stored pre-encoded music/speech streams.

-Pascal