[CELT-dev] Artifacts in One Channel of Stereo C55x Implementation
jmvalin at jmvalin.ca
Thu Feb 3 07:00:28 PST 2011
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.
> 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.
> 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
> 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
> during the audio stream.
> Anyone ever run across this? Have any insight?
> celt-dev mailing list
> celt-dev at xiph.org <mailto:celt-dev at xiph.org>
> celt-dev mailing list
> celt-dev at xiph.org
More information about the celt-dev