Hi, Re 700C being equivalent to all other rates - that's a curious result - all other reports (and the samples we have) show the quality improving with bit rate. 700C tends to overlap 1300 in quality (better for some samples, worse for others). 2400 and 3200 use much faster frame rates.
I can't imagine Russian being _that_ different to English - it's not a tonal language for example. So I don't think it's language. Other possibilities are: 1/ Range of samples you are testing over. Some samples code better than others. 2/ Recording conditions, e.g. band pass response, spectral slope, microphone, levels, clipping. This is an interesting area that I am making some progress on with the lower bit rate modes. 3/ Listening conditions, e.g. speaker type, versus headphones. So while you results are interesting, I would be careful drawing broad conclusions from your tests (like the intelligibility of 700C == 3200). -/- Yes, some of the 700C algorithms could be used for higher bit rates. If anyone is interested in working on such a project, pls let me now. I'm rather busy with other projects, but happy to advise/work with someone on it. Cheers, David On 14/1/20 2:16 am, Maxim Karpov wrote: > 11.01.2020, 23:04, "David Rowe" <[email protected]>: >> 2/ With noisy speech the MELP samples appear to have removed the >> interfering noise - the noise is suppressed in the output samples, and >> not faithfully reproduced. This suggests the MELP implementation you >> have used also has a pre-processing step to remove noise. > > Yes, you were right. As noise preprocessor was a separate function in that > source code, I thought that just omitting it would be sufficient. Turns out > that > it was not, and call to the function was also in the codec itself. I had > patched > out these calls and updated samples on the page. > > 11.01.2020, 23:04, "David Rowe" <[email protected]>: >> 1/ On the noise free English samples, codec 2 at 1200/2400 is slightly >> worse than MELP at the same rates. This is consistent with other tests >> (e.g. academic papers using the two codecs as references). >> >> ... >> >> 3/ It's difficult for me to evaluate the Russian samples, as I don't >> speak the language, but thanks for the feedback. Yes, Codec 2 was >> developed on just English samples. > > The main issue with intelligibility that I see is that it does not improve > when > you give it more bitrate. When you have a good channel with [relatively] high > SNR, or just UHF/VHF radio, you can't get any better output from it. Consider > AMBE that does not have anything below 2 kbits, but is still heavily used on > UHF/VHF just because you can afford more bandwidth there. Bitrates between, > say, 1.2k and 6k are a large gap that does not have any open-source solutions. > Opus can work from 6k onwards, Codec2 has good quality to bitrate ratio at > 700C and below, but there is nothing in between. > > I had conducted a small listening test on Russian samples asking people to > listen to the text and they mostly agreed that while 700C sounds much better > than 450, 2400 sounds similar to 700C, despite having 3.5x bandwidth. They > were unable to extract from 1200 or 2400 recording any additional words that > were unintelligible on 700C. 1200 MELP encoding was perfectly intelligible, by > the way. I think that distorted "robotic" sound affects intelligibility too, > but it is > just an assumption. MELP sounds much more naturally than Codec2. > > Unfortunately, I can't conduct similar test for English, since I think that > it's not > quite correct to measure intelligibility on non-native speakers. > > When I made audio samples that switches between two bitrates back and > forth every 5 seconds (they can be found on samples page), I found that > these 2400/3200 are virtually indistinguishable from 700C: it feels like you > are just listening to a single solid recording instead of two interleaved. > This, > however, can be considered a good news - if 700C has almost the same > intelligibility as 2400, then 2400 has a large room for improvements. This is > also a good metric of a progress: your codec is now 3.5x more efficient than > it was 5 years ago :) Or, considering that 3200 bitrate is also > indistinguishable > from 700C - even 4.6x more efficient. > > I'm not so much fluent in a coding theory and don't know whether knowledge > gained from 700C development can be 'extrapolated' to a higher bit rates to > make something like 1200B and 2400B modes, but it would be very nice to > have a codec that operates in a 1k-3k bitrate range. > > 11.01.2020, 23:04, "David Rowe" <[email protected]>: >> Hi Макс, >> >> Nice work on your tests! OK so this is what I hear: >> >> 1/ On the noise free English samples, codec 2 at 1200/2400 is slightly >> worse than MELP at the same rates. This is consistent with other tests >> (e.g. academic papers using the two codecs as references). >> >> 2/ With noisy speech the MELP samples appear to have removed the >> interfering noise - the noise is suppressed in the output samples, and >> not faithfully reproduced. This suggests the MELP implementation you >> have used also has a pre-processing step to remove noise. >> >> So it's not quite an A/B comparison - the core MELP codec is being >> tested on audio that has had the noise suppressed. >> >> With noisy input speech, the Codec 2 samples are distorted and >> unpleasant to listen too, but still (as you suggest) intelligible. >> >> For noise suppression in Codec 2 applications we use the Speex noise >> suppressor (codec2/misc/speexnoisesup.c for a command line version). >> >> 3/ It's difficult for me to evaluate the Russian samples, as I don't >> speak the language, but thanks for the feedback. Yes, Codec 2 was >> developed on just English samples. >> >> 4/ You are correct Codec 2 1200/2400 hasn't been actively developed in >> over 5 years, recent efforts have been at lower bit rates, and LPCNet >> (at 1733 bit/s). In particular to support digital voice systems for HF >> radio. >> >> Cheers, >> David >> _______________________________________________ >> Freetel-codec2 mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > > > _______________________________________________ > Freetel-codec2 mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/freetel-codec2 > _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
