[CELT-dev] CELT in Digital Radio Mondiale

[Jean-Marc Valin]

Hi Michael,

The reason I was mentioning something like SECDED is that even if you 
know your packet is corrupted, you may still want to play it anyway. 
While an error in the first bits may result in completely corrupted 
audio for that frame, an error in later bits may have very little 
effect. So the idea is that 1) single errors in the first bits are 
corrected 2) errors in other bits are left alone 3) multiple errors on 
the first bits are detected and the frame is considered lost. Speaking 
of that, you probably want to use the PLC algorithm for cases where the 
frame is corrupted. There was also a bug for large frame sizes, which I 
fixed at the same time as your other bug.

There's an older graph on bit error rubustness in Fig. 10 of 
http://jmvalin.ca/papers/celt_tasl.pdf . That should give a bit of an 
idea, although things have improved since then -- the bit-stream is now 
more robust to errors and the PLC that handles frame erasures is also 
better. I have not made any measurements on the current code.

Cheers,

	Jean-Marc

On 10-06-01 03:57 AM, Feilen, Michael wrote:
> Hi Jean Marc.
>
> Wow, that was quick! Thank you very much for the patch :-) I'll test it as soon as I get the time.
>
> Some benefits of CRC bit-error protection: (CRC is a cyclic code with very good burst error detection and correction capabilities.)
>
> 1) With a high probability you could detect whether the whole frame is valid or not by spending a few CRC bits and sending them as overhead information.
> 2) You should be able to find a code which can correct around 4 burst errors with a 10 bit CRC on 32 bit of payload data (For header protection only). For optimum shortened cyclic codes see: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01057825
> 3) There is a>99% chance that the 16 bit CRC check on a 64 bit header will fail if there are bit-errors in the header block.
> 4) CRC is easy to implement.
>
> Best Regards,
> Michael Feilen
>
> -----Ursprüngliche Nachricht-----
> Von: Jean-Marc Valin [mailto:jean-marc.valin at usherbrooke.ca]
> Gesendet: Dienstag, 1. Juni 2010 04:02
> An: Feilen, Michael
> Cc: celt-dev at xiph.org
> Betreff: Re: [CELT-dev] CELT in Digital Radio Mondiale
>
> Hi Michael,
>
> As I suspected, the bug was simple and so was the fix. I checked it in
> for the git master branch, but that is *not* compatible with release
> 0.7.1. However, the patch should apply to 0.7.1:
> http://git.xiph.org/?p=celt.git;a=commitdiff;h=32589cd33e166ff62d0e842a1a9407542a104e22
>
> Let me know if that fixes the problem for you.
>
> Cheers,
>
> 	Jean-Marc
>
> On 10-05-31 07:38 AM, Feilen, Michael wrote:
>> Dear CELT Developers,
>>
>> I wrote a proposal on how to integrate CELT into Digital Radio Mondiale (DRM+). The CELT codec has been integrated in the Spark transmission software and SoDiRa receiver software.
>>
>> Please download the proposal here:
>> http://www.drm-sender.de/celt_in_drm.pdf
>> Suggestions and comments are welcome!
>>
>> A live on-air DRM+ transmission using CELT (v.0.7.1) for audio encoding was presented on May, 27th at the Symposium in Kaiserslautern:
>> http://www.drm-radio-kl.eu/symposium2010/symposium2010en.htm
>>
>> Although the codec delivers very good audio quality and runs stable if the bitstream is error-free, the decoder (v0.7.1) produces a segfault under Windows in case the bitstream contains bit-errors. Currently, we detect faulty frames by an additional CRC check and avoid decoding them.
>> I wonder if this behavior is intentional or if it might be a bug in the codec?
>>
>> Thank you!
>>
>> Best regards,
>> Michael Feilen
>> _______________________________________________
>> celt-dev mailing list
>> celt-dev at xiph.org
>> http://lists.xiph.org/mailman/listinfo/celt-dev
>>
>>
>
>