On the female sample, I hear a lot of squeaking or pinging noises, regardless of the bit rate, except in the original sample of course.
On Sep 14, 2012, at 5:48 PM, David Rowe <[email protected]> wrote: > Hello, > > SVN rev 714 contains the latest 1200, 1400, 2400 and a new 3200 bit/s > mode, which all use the new LPC post filter. Samples are available on > the Codec 2 page: > > http://www.rowetel.com/blog/?page_id=452 > > I think the quality is significantly improved, but pls tell me what you > think. With the 3200 bit/s mode I have included some higher rate VOIP > type codec samples for comparison. > > Thanks, > > David > > On Tue, 2012-09-11 at 14:39 -0600, Steve Strobel wrote: >> On Fri, Sep 7, 2012 at 1:26 AM, Kristoff Bonne <[email protected]> wrote: >> >>> I haven't had time to look at BCH in detail but do you suggest that >>> (64,32)BCH >>> is simply 5 times (12,6)BCH or am I missing something. >> >> I don't know much at all about BCH, but I was suggesting that a >> theoretical (48,24) code was NOT the same as (was potentially better >> than) using a (12,6) code four times. I referred to BCH only because >> it apparently has variations that work on different numbers of bits at >> a time (what I would call a "FEC frame", 48 or 12 in these examples). >> >>> Well, I will of course interleaving. >>> >>> Depending on option-bits in the stream-header, it will be using blocks >>> of 1 (i.e. only inside the frame) or 2, 4 or 16 frames. The latter modes >>> will greatly increase latency, but is designed only be used for -say- 10 >>> meter DXing; to deal with fading. >> >> There is obviously a tradeoff between the block size and latency. >> Given a certain block size, my argument is that the optimal FEC would >> treat the entire block as a single "FEC frame" (not to be confused >> with codec2 frames). >> >> Consider for example that we wanted to add 50% additional bits for FEC >> and the block size is 16 codec2 frames of 56 bits each for a total of >> 896 codec2 bits and 448 FEC bits. One way to handle it would be to >> split the 896 bits into 28 FEC frames of 32 bits each and use a >> (32,16) FEC code on it. Let us assume that a theoretical (32,16) code >> can correct three bit errors. With 28 such FEC frames, it should be >> possible to correct 28*3 = 84 bit errors per block, but only if they >> are perfectly distributed. Interleaving can help distribute the bit >> errors more uniformly, but as the number of errors per block gets >> close to 84, it is likely that some of the FEC frames will have more >> than three errors and not be correctable while others will have less >> than three and "waste" some of their ability to correct. >> >> By contrast, if the entire 896 bits were treated as a single FEC frame >> and a (896,448) FEC code (same total number of FEC bits) could correct >> 84 bits (the same total number of errors per block), it wouldn't >> matter how the bit errors were distributed within the block. If there >> were 84 or less errors, the entire block would get corrected >> perfectly. Note that this suggests that interleaving would be of no >> value; up to 84 bit errors per block could be corrected no matter how >> they were distributed. >> >> I can think of a few reasons that taking the large FEC frame technique >> to an extreme might be problematic. It might take more processing >> time or memory to execute than multiple iterations with a smaller FEC >> frame. And if there are more errors in the block than can be >> corrected (more than 84 in the example above), it might affect more >> codec2 frames than if the FEC was done on smaller frames. I suppose >> that argument could also be made against interleaving bits among >> multiple codec2 voice frames; a single burst of errors too long to >> correct would mess up more voice frames than if interleaving was not >> done. I hadn't considered it before, but maybe interleaving for FEC >> is part of the reason digital radio tends to "fall off the cliff" >> rather than degrading gradually when the signal gets weak. >> >> Steve >> >> > > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
