[CELT-dev] Artifacts in One Channel of Stereo C55x Implementation

[Jean-Marc Valin]

On 11-02-03 09:51 AM, Bob Bang wrote:
> Yes, the integer overflow was my first thought as well. I tested the the
> code on a PC with the "celtenc" and "celtdec" exe's.  I assume if I
> configured the compilation with "--enable-fixed-point" that the behavior
> would manifest itself. It did not, so it may be an issue specific to the
> DSP. I can try to track this down, or I may upgrade the CELT revision.
> What revision contains the newer constraint on frame size? (The prime
> factors of 2,3 & 5) My system is quite defined on a 100 sample frame
> size so obviously that newer constraint won't work.

Last I've heard, 100=2*2*5*5, so it *should* work with the latest 
version. I recommend updating, though it's likely that you'd just see 
different problems. Again, this is due to the fact that we have 
currently no way to test on 16-bit platforms.

> Also, in debugging my system I have seen that for a static frame input
> to the encoder, I see the exact same encoded buffer output , byte for
> byte, every call. Is this expected behavior? Is there no state
> information passed along to the decoder in the compressed buffer? So
> basically, for every input X[n], there is a defined output Y[n]?

There *is* a state, though depending on the exact input, the encoder may 
choose not to use any prediction. There's also a setting to disable 
prediction explicitly, but it's not set by default.

	Jean-Marc

> thanks for getting back to me, I appreciate the help and love what
> you're doing here.
>
>
>
> On Mon, Jan 31, 2011 at 9:46 PM, Jean-Marc Valin <jmvalin at jmvalin.ca
> <mailto:jmvalin at jmvalin.ca>> wrote:
>
>     I guess the first question is whether you can reproduce the problem
>     on a PC with the same code. If not, then the most likely issue is a
>     16-bit integer overflow. CELT *attmpts* to only use the "int" type
>     for values that won't overflow a 16-bit int. However, because we
>     have no 16-bit platform to test, it's likely that we missed something.
>
>     Cheers,
>
>             Jean-Marc
>
>
>     On 11-01-31 03:34 PM, Bob Bang wrote:
>
>         Hi guys,
>
>         I am on a C55x stereo implementation of CELT 0.7.1; I am using 100
>         sample frame size and writing 58 Bytes per Packet. At the output
>         of the
>         decoder I see one channel reconstructed perfectly, but the other
>         channel
>         has random corruption that appears to be a sinusoid with a
>         period of the
>         frame size.  The artifact is non-periodic and appears to happen
>         randomly
>         during the audio stream.
>
>         Anyone ever run across this? Have any insight?
>
>         thanks
>
>
>
>
>         _______________________________________________
>         celt-dev mailing list
>         celt-dev at xiph.org <mailto:celt-dev at xiph.org>
>         http://lists.xiph.org/mailman/listinfo/celt-dev
>
>
>
>
> _______________________________________________
> celt-dev mailing list
> celt-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/celt-dev