[CELT-dev] Possible Bug

[Riccardo Micci]

Hi,
Fiddling with Celt i found a possible bug. I'm using CELT 0.7.1, frame 
size 256, sample rate 32k and bitrate 64k.
Here is the scenario: decoding side, celt_decode function.
The "dec" structure is created at each function call and it's initialized 
with ec_dec_init  function. The attribute "end_byte" is not initialized 
though. Decoding a file the behaviour is the following: decoding the first 
frame the variable "shortBlocks" is true and then transient_shift == 3 
hence the function ec_dec_uint  is executed. In this function the 
attribute "end_byte" is written first and read next. That's ok. The 
problem comes decoding the next frame. Since now "shortBlocks" is false, 
"end_byte" is not initialized anymore and next functions read it before 
update.

Can someone confirm this behaviour? In my case i modified ec_dec_init  
function to initialize it as well. What is the correct value?

Thanks
Best Regards
Riccardo



Riccardo Micci
Senior DSP Engineer, Wireless Group 
Cambridge Consultants
Science Park, Milton Road 
Cambridge, CB4 0DW, England
Switchboard: +44 (0)1223 420024
Direct dial: +44 (0)1223 392402
Mobile: +44 (0)
Fax: +44 (0)1223 423373
riccardo.micci at cambridgeconsultants.com
www.CambridgeConsultants.com
 





This email is from Cambridge Consultants Limited, Science Park, Milton 
Road, Cambridge CB4 0DW with registered number 1036298 England. It may 
contain confidential information. It is intended for the addressee only 
and may not be copied or disclosed to any third party without our 
permission. If you are not the intended recipient please contact the 
sender as soon as possible and delete the material from any computer. If 
this email has been sent as a personal message to the addressee, the 
sender is not acting in his/her capacity as an employee or officer of 
Cambridge Consultants Limited and no liability is accepted for the content 
of any such email. Outgoing email may be monitored for the purpose of 
ensuring compliance with our email policy and relevant laws.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xiph.org/pipermail/opus/attachments/20100902/cc77e612/attachment-0002.htm