[CELT-dev] Variable frame size and API changes

Hamid Zare Doust hzdoust at gmail.com
Tue May 18 09:45:47 PDT 2010


Hi Jean-Marc,

Having variable audio frame size will be very helpful, but I think
still celt needs to support radix-2 frame sizes.
- standard high quality sample rate 48k, 44k1 and 32k, it's very hard
to find a sound system to have buit-in 51k2 sampling
- software resampling is too costly, also when it comes to fractional
resampling it's always adds some distortion due to interpolation.

For dynamic frame sizes I suggest that in addition to those mentioned
in your email, supporting another set of frame sizes regardless of
sample rate, and that is:
64, 128, 256, 512 samples.


Thanks,
Hamid


On Tue, May 18, 2010 at 4:17 AM, Jean-Marc Valin
<jean-marc.valin at usherbrooke.ca> wrote:
> Hi everyone,
>
> I've recently been making various changes to the way the modes work and
> the supported frame size. On new feature that may be of interest to some
> is that CELT should soon support changing the frame size dynamically
> within a stream. By that I mean varying the amount of audio (in time)
> transmitted at once, not the compressed size -- which has always been
> variable. That would allow dynamically trading compression efficiency
> for delay.
>
> Now, one potential side effect of this work is that I may actually
> remove some of the flexibility in the frame size. So far, CELT has
> always been insanely flexible when it came to choosing the frame size.
> For example, you could encode with frames of (e.g. 494 samples if you
> wanted to). What I'm now considering is restricting the available frame
> sizes to 2.5 ms, 5 ms, 10 ms and 20 ms. Those could be supported at any
> sampling rate where 2.5 ms represents an even number of samples, e.g. 32
> kHz or 48 kHz. However, that would exclude 44.1 kHz, so I'd like to know
> if people are actually using CELT at that sampling rate? One other side
> effect is that you would no longer have frames that are a power of two
> in samples -- unless you use 51.2 kHz as the sampling rate (which would
> be supported).
>
> Any comments on this? Anyone has major reasons not to do that?
>
> Cheers,
>
>        Jean-Marc
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev
>



More information about the celt-dev mailing list