[Freetel-codec2] integrating codec2 into anything

[Jerome Shawstad]

And hopefully in text format this time so more people can read it since I dont see my own things in the digest.

Concerning "integrating codec2 into opus" there still might be some possible way to suggest, petition, discuss, or offer... I considered more of a question of interest here since it was created here and i'm not wanting someone to give away their baby. If its all about propagation and adoption and use though i'd still consider it - even if opus is now standardized, MP3 went through something similar I thought with their very low bitrate (for them) level they called layer 2.5 I thought, which was only compatible on newer hardware (eventually everything) but the early stuff was bitrate limited to like 48kbit and above for instance.

Integration into firefox or anything else I still think is a good idea, i'm just for seeing who else might be willing to work with you guys. You have a great codec, with somewhat specialized usage admittedly, but even if it was "for" realtime radio the more it gets known hopefully the more developers will later help out as well.

I'm still figuring out if there's anything I can even do to contribute. I don't code, my main offer is as a data hoarder and fan of audiobook/radio who is always using well below spec phones without much space, turning into i'm willing to transcode my normal multihour content that I listen to daily at lower and lower bitrates, trying to do critical listening (under various conditions but often in the car/testing a "real world noise environment" if you will) for conditions where the codec seems unusually challenged or vocal recognition is lost... to eventually include multilanguage (or at least some nonenglish as I study language tapes later) and trying to write it down/timecode it for further analysis. I just have no convenient way to encode or realtime decode it either on PC or Android right now making that more difficult.

[Stuart Marsden]

I think this is a good idea but I think the licences are in-compatible at
the moment. If you include codec2(LGPL) in to Opus(BSD) then the whole
thing would have to be LGPL. I think the developers would have to agree to
re/dual-licence codec2 to BSD for this to be possible. This is not always
easy as you should get the permission of all contributors.

Post by Jerome Shawstad
And hopefully in text format this time so more people can read it since I
dont see my own things in the digest.
Concerning "integrating codec2 into opus" there still might be some
possible way to suggest, petition, discuss, or offer... I considered more
of a question of interest here since it was created here and i'm not
wanting someone to give away their baby. If its all about propagation and
adoption and use though i'd still consider it - even if opus is now
standardized, MP3 went through something similar I thought with their very
low bitrate (for them) level they called layer 2.5 I thought, which was
only compatible on newer hardware (eventually everything) but the early
stuff was bitrate limited to like 48kbit and above for instance.
Integration into firefox or anything else I still think is a good idea,
i'm just for seeing who else might be willing to work with you guys. You
have a great codec, with somewhat specialized usage admittedly, but even if
it was "for" realtime radio the more it gets known hopefully the more
developers will later help out as well.
I'm still figuring out if there's anything I can even do to contribute. I
don't code, my main offer is as a data hoarder and fan of audiobook/radio
who is always using well below spec phones without much space, turning into
i'm willing to transcode my normal multihour content that I listen to daily
at lower and lower bitrates, trying to do critical listening (under various
conditions but often in the car/testing a "real world noise environment" if
you will) for conditions where the codec seems unusually challenged or
vocal recognition is lost... to eventually include multilanguage (or at
least some nonenglish as I study language tapes later) and trying to write
it down/timecode it for further analysis. I just have no convenient way to
encode or realtime decode it either on PC or Android right now making that
more difficult.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hello Lists,

Here is a blog post on the new, and somewhat experimental, Codec 2 700C
mode:

http://www.rowetel.com/?p=5373

Cheers,

David

[Tomas Härdin]

Hey, some of the 700C ones sounds better than 1300. Nice work! :)

/Tomas

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David

[Jean-Marc Valin]

Hi David,

Pretty impressive what you can do with just 700 kb/s and (especially)
with just 40 ms frames (as opposed to "batches" of 80-200 ms). Just a
few thoughts I had while reading and listening to the samples:

1) Noise: it seems like performance gets worse with background noise.
This is of course perfectly normal for a low bitrate codec (and
especially a vocoder), but I was thinking you might be able to improve
coding performance (and intelligibility) by applying noise suppression
on the input. For uncompressed audio, noise suppression doesn't improve
intelligibility because our brain can do a better job, but with a
vocoder, noise suppression may help reducing coding artefacts.

2) Prediction: You mention not using prediction to make the codec more
robust to packet loss, but I think some amount of prediction could be
used safely. The idea is that if you get the wrong gain, the speech will
still be intelligible during convergence, it's just the level that will
be slightly wrong. For pitch, if you make the voiced/unvoiced decision
separate, you can predict across voiced frames, so the deltas will be
very small and again getting out of sync will just cause the pitch to be
slightly off for a few frames, again not hurting intelligibility. When
you think about it, even a constant pitch would still be intelligible!
I'm pretty sure you can do better than what I had published in
http://jmspeex.livejournal.com/10446.html and still be robust to packet
loss. You might be able to get away with just 6 or 7 bits, saving 3-4
bits that you can then spend on a better spectrum

3) spectrum: I was wondering how much the 40 ms frames are hurting
compared to 20 ms, but maybe there's a way to get some of it back by
coding some temporal information.

4) LSP VQ: Your results are especially impressive considering the VQ was
trained on just 120 seconds of speech. Also, I'm not sure what's in
these 120 seconds, but it's probably a good idea to include as many
different conditions (frequency responses, noise conditions, speakers,
...) as possible. In Speex I made the mistake of having only a single
condition (clean with modified IRS filter) and that made the LSP
quantizer not very good for anything else. Even with a single clean
database, it's easy to add filtering and different types of background
noise.

Cheers,

Jean-Marc

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hi Jean Marc,

Thanks for your comments. Yes it's a nice step forward from 1300. I've
tried VQ of the mag spectrum several times in the past but this time
it's come together. Experience and attention to detail I guess.

1) I agree - in fact we use your speex noise suppressor on the FreeDV
GUI program.

2) It's worth a try but last time we tried joint pitch/energy
quantisation with prediction it was the most sensitive part of the codec
to bit errors. So this would need to be tested carefully, or combined
with FEC.

3) 40ms is pushing it, there is some reduction in quality, and I'm quite
surprised it works so well. Good interpolation helps. I even played
with some "analysis by synthesis" interpolation where we try different
combinations of 3 source 10ms frames over a 80ms period and choose the
best 3 positions. Like non-linear sampling. Didn't get any major
improvement over simple 1:4 decimation/interpolation (so far).

4) It's direct VQ of the resampled harmonic amplitude samples - no LPC
or LSP any more. I agree 120 seconds is way short. It was just a
starting point to test the VQ code but then, well it worked, so I forged
ahead! Need to come back to this area. Yes different low pass/high
pass filtering makes a difference - as it did for LPC/LSP (e.g. cq_ref
sample breaks 1300 due to it's slope).

However it is very nice working directly in the magnitude spectral
domain. For example different filters (+/- 6dB/octave slope) could be
applied to the source vectors before VQ searching. The slope wouldn't
even need to be transmitted, as we don't really care when we listen.

Cheers,

David

Post by Jean-Marc Valin
Hi David,
Pretty impressive what you can do with just 700 kb/s and (especially)
with just 40 ms frames (as opposed to "batches" of 80-200 ms). Just a
1) Noise: it seems like performance gets worse with background noise.
This is of course perfectly normal for a low bitrate codec (and
especially a vocoder), but I was thinking you might be able to improve
coding performance (and intelligibility) by applying noise suppression
on the input. For uncompressed audio, noise suppression doesn't improve
intelligibility because our brain can do a better job, but with a
vocoder, noise suppression may help reducing coding artefacts.
2) Prediction: You mention not using prediction to make the codec more
robust to packet loss, but I think some amount of prediction could be
used safely. The idea is that if you get the wrong gain, the speech will
still be intelligible during convergence, it's just the level that will
be slightly wrong. For pitch, if you make the voiced/unvoiced decision
separate, you can predict across voiced frames, so the deltas will be
very small and again getting out of sync will just cause the pitch to be
slightly off for a few frames, again not hurting intelligibility. When
you think about it, even a constant pitch would still be intelligible!
I'm pretty sure you can do better than what I had published in
http://jmspeex.livejournal.com/10446.html and still be robust to packet
loss. You might be able to get away with just 6 or 7 bits, saving 3-4
bits that you can then spend on a better spectrum
3) spectrum: I was wondering how much the 40 ms frames are hurting
compared to 20 ms, but maybe there's a way to get some of it back by
coding some temporal information.
4) LSP VQ: Your results are especially impressive considering the VQ was
trained on just 120 seconds of speech. Also, I'm not sure what's in
these 120 seconds, but it's probably a good idea to include as many
different conditions (frequency responses, noise conditions, speakers,
...) as possible. In Speex I made the mistake of having only a single
condition (clean with modified IRS filter) and that made the LSP
quantizer not very good for anything else. Even with a single clean
database, it's easy to add filtering and different types of background
noise.
Cheers,
Jean-Marc

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Steve]

I created a DLL version of just the 700C codec. The encoder worked just
fine, but the decoder caused me great difficulty.

It turns out I was using the "-fsingle-precision-constant" compiler option
(C89) and by taking that out, I finally had binary compatibility of encode
and decode.

I'm 99% certain that no one else would be interested in this, but I'll
stick it out there. I'm playing with a cohpsk and 700c DLL's for a project
idea.

https://github.com/ObjectToolworks/vocoder700c

[David Rowe]

Fast work Steve - I wonder where the sensitivity to single precision
came in?

Cheers,

David

Post by Steve
I created a DLL version of just the 700C codec. The encoder worked just
fine, but the decoder caused me great difficulty.
It turns out I was using the "-fsingle-precision-constant" compiler
option (C89) and by taking that out, I finally had binary compatibility
of encode and decode.
I'm 99% certain that no one else would be interested in this, but I'll
stick it out there. I'm playing with a cohpsk and 700c DLL's for a
project idea.
https://github.com/ObjectToolworks/vocoder700c
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Steve]

I'll probably research that after a nap. It's 2 am and I'm out of beer :-)

It's just the decode side though. The c2 files were compatible with or
without the flag.

I'm using: gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)

Great vocoder! Sounds good. I'll have to see how it works with my 32
Ford spark gap engine, ha...

73, Steve

Post by David Rowe
Fast work Steve - I wonder where the sensitivity to single precision
came in?
Cheers,
David

Post by Steve
I created a DLL version of just the 700C codec. The encoder worked just
fine, but the decoder caused me great difficulty.
It turns out I was using the "-fsingle-precision-constant" compiler
option (C89) and by taking that out, I finally had binary compatibility
of encode and decode.
I'm 99% certain that no one else would be interested in this, but I'll
stick it out there. I'm playing with a cohpsk and 700c DLL's for a
project idea.
https://github.com/ObjectToolworks/vocoder700c
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Jean-Marc Valin]

Hi David,

Post by David Rowe
Thanks for your comments. Yes it's a nice step forward from 1300. I've
tried VQ of the mag spectrum several times in the past but this time
it's come together. Experience and attention to detail I guess.

What do you mean by "mag spectrum"? The actual interpolated spectral
envelope or the discrete sinusoids (in which case what do you do about
variable pitch)?

Post by David Rowe
2) It's worth a try but last time we tried joint pitch/energy
quantisation with prediction it was the most sensitive part of the codec
to bit errors. So this would need to be tested carefully, or combined
with FEC.

Maybe instead of going straight to prediction+VQ like I did, you can try
predicting one parameter at a time. Like many things, it's all about the
details. For example, for the gain, the level of the "zero" is important
because because that's the point towards which prediction will tend
converge in case of error. So usually want it somewhere in the middle,
but maybe it's better if it's slightly closer to the gain of active
speech or silence. Forcing some sort of gain normalization (AGC) can
probably help too, regardless of whether you use prediction. For pitch
prediction, you probably want to avoid pitch doubling so that most
frames have the same pitch and any error doesn't cause much problem.

Post by David Rowe
3) 40ms is pushing it, there is some reduction in quality, and I'm quite
surprised it works so well. Good interpolation helps. I even played
with some "analysis by synthesis" interpolation where we try different
combinations of 3 source 10ms frames over a 80ms period and choose the
best 3 positions. Like non-linear sampling. Didn't get any major
improvement over simple 1:4 decimation/interpolation (so far).

One thing I've always thought might be a good approach for very long
frames would be to compute a 2D DCT of the log spectrum. In 1D the DCT
is just the cepstrum, but in 2D you can capture the temporal shape at
the same time. That way you can remove both the spectral and temporal
redundancy.

Post by David Rowe
However it is very nice working directly in the magnitude spectral
domain. For example different filters (+/- 6dB/octave slope) could be
applied to the source vectors before VQ searching. The slope wouldn't
even need to be transmitted, as we don't really care when we listen.

By slope, I assume you mean a constant slope over time? I guess it's one
step further in the normalization I was suggesting for gain and indeed,
you'd probably save a few bits by equalizing the input. ...or you could
use prediction of the spectrum over time, which would give you
normalization essentially for free.

Cheers,

Jean-Marc

[s***@gmx.de]

I did a short test, there is clearly some improvement on the female
sample hts2a in 700C which was poor in 700B before, but the male sample
hts1a sounds better in 700B in my opinion as it sounds more nasal now
and "attacked" had a clear 'ck'-noise before and now it sounds more like
"attached".
I also wonder if we could get even lower bitrate now, like 300-400 b/s
that sounds similar to 700(A).

Greets
Simon the Sorcerer

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Oh dear I just spent 18 months on 700c to have it sounding worse than
700B! Ahhhhhhh. Meh, can't win 'em all :-)

Post by s***@gmx.de
I did a short test, there is clearly some improvement on the female
sample hts2a in 700C which was poor in 700B before, but the male sample
hts1a sounds better in 700B in my opinion as it sounds more nasal now
and "attacked" had a clear 'ck'-noise before and now it sounds more like
"attached".
I also wonder if we could get even lower bitrate now, like 300-400 b/s
that sounds similar to 700(A).
Greets
Simon the Sorcerer

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[s***@gmx.de]

Well it's not always worse, but the distorted 'ck' noise is probably the
next thing to look at for even more improvement, I wonder where this
distortion comes from, probably there is some kind of too aggressive
gaussian smoothing in the codec?

Post by David Rowe
Oh dear I just spent 18 months on 700c to have it sounding worse than
700B! Ahhhhhhh. Meh, can't win 'em all :-)

Post by s***@gmx.de
I did a short test, there is clearly some improvement on the female
sample hts2a in 700C which was poor in 700B before, but the male sample
hts1a sounds better in 700B in my opinion as it sounds more nasal now
and "attacked" had a clear 'ck'-noise before and now it sounds more like
"attached".
I also wonder if we could get even lower bitrate now, like 300-400 b/s
that sounds similar to 700(A).
Greets
Simon the Sorcerer

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Jeroen Vreeken]

Hi David,

The new samples sound really impressive.
I added support for the new mode to my DML code and hope to do some more
extensive testing soon.
I also made a small patch to get the 'energy' of a 700C frame. Hopefully
I got it about right...

Looking at the codec2_encode_700c function I noticed that the indexes
are determined after just one call to the analyse_one_frame function and
that the other 3 frames are analysed after that, but don't influence the
indexes at all anymore.
I might be wrong, but to me it looks like this order introduces 30ms of
latency for no real reason... Would it not be better to just call
analyse_one_frame four times before creating the indexes?

Another thing I was wondering about: Would this method also
significantly improve the modes with a higher bitrate? How good would a
'1300C' mode sound?

Regards,
Jeroen

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hi Jeroen,

Thanks for your patch, compiles and checked in.

-/-

We need to call analyse_one_frame() every 10ms as that's the internal
frame rate of the core sinusoidal modeling inside Codec 2. Note the ptr
into the input speech vector is offset by 80 samples (10ms) each time.
We need the input speech sample driver to supply us with a 320 sample
(40ms) input vector. Various states need to be updated even though we
toss the output model parameters away for 3/4 of the frames in 700C.

Just transmitting the model parameters 1 in every 4 frames is like
"decimation in time" of any sampled sequence. At the decoder, to
reconstruct the missing frames (say 2,3,4) we interpolate between need
frames 1 and 5.

So we could send a sequence of frames 1,5,9 or 2,6,10 ... either way you
get a 40ms latency.

-/-

Yes it would be nice to try the same VQ ideas at a higher bit rate and
hopefully higher quality. If anyone would like to attempt that I can
show you how.

Cheers,

David

Post by Jean-Marc Valin
Hi David,
The new samples sound really impressive.
I added support for the new mode to my DML code and hope to do some more
extensive testing soon.
I also made a small patch to get the 'energy' of a 700C frame. Hopefully
I got it about right...
Looking at the codec2_encode_700c function I noticed that the indexes
are determined after just one call to the analyse_one_frame function and
that the other 3 frames are analysed after that, but don't influence the
indexes at all anymore.
I might be wrong, but to me it looks like this order introduces 30ms of
latency for no real reason... Would it not be better to just call
analyse_one_frame four times before creating the indexes?
Another thing I was wondering about: Would this method also
significantly improve the modes with a higher bitrate? How good would a
'1300C' mode sound?
Regards,
Jeroen

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[vk4gra]

Hi David  vk4gra here
Whats wrong sending messages a 300b/s My mother used to send using 0 b/s  its called telepathy 😀
All jokes aside the sample supplied sound great  , will done top marks Graham 
Sent from Samsung tablet.
-------- Original message --------From: David Rowe <***@rowetel.com> Date: 15/01/2017 7:11 PM (GMT+10:00) To: freetel-***@lists.sourceforge.net Subject: Re: [Freetel-codec2] Codec 2 700C
Oh dear I just spent 18 months on 700c to have it sounding worse than
700B! Ahhhhhhh.  Meh, can't win 'em all :-)

Post by s***@gmx.de
I did a short test, there is clearly some improvement on the female
sample hts2a in 700C which was poor in 700B before, but the male sample
hts1a sounds better in 700B in my opinion as it sounds more nasal now
and "attacked" had a clear 'ck'-noise before and now it sounds more like
"attached".
I also wonder if we could get even lower bitrate now, like 300-400 b/s
that sounds similar to 700(A).
Greets
Simon the Sorcerer

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
    http://www.rowetel.com/?p=5373
Cheers,
David
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[s***@gmx.de]

Well 300b/s is not telepathy, found out there is already a modified
codec2 with 300b/s by some Brian Smith:
https://sites.google.com/site/300bpsspeechcodec/home

gz
Simon

Hi David vk4gra here
Whats wrong sending messages a 300b/s
My mother used to send using 0 b/s its called telepathy 😀
All jokes aside the sample supplied sound great , will done top marks
Graham
Sent from Samsung tablet.
-------- Original message --------
Date: 15/01/2017 7:11 PM (GMT+10:00)
Subject: Re: [Freetel-codec2] Codec 2 700C
Oh dear I just spent 18 months on 700c to have it sounding worse than
700B! Ahhhhhhh. Meh, can't win 'em all :-)

Post by s***@gmx.de
I did a short test, there is clearly some improvement on the female
sample hts2a in 700C which was poor in 700B before, but the male sample
hts1a sounds better in 700B in my opinion as it sounds more nasal now
and "attacked" had a clear 'ck'-noise before and now it sounds more like
"attached".
I also wonder if we could get even lower bitrate now, like 300-400 b/s
that sounds similar to 700(A).
Greets
Simon the Sorcerer

Post by David Rowe
Hello Lists,
Here is a blog post on the new, and somewhat experimental, Codec 2 700C
http://www.rowetel.com/?p=5373
Cheers,
David

------------------------------------------------------------------------------

Post by s***@gmx.de

Post by David Rowe
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------

Post by s***@gmx.de
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Jeroen Vreeken]

Post by David Rowe
We need to call analyse_one_frame() every 10ms as that's the internal
frame rate of the core sinusoidal modeling inside Codec 2. Note the ptr
into the input speech vector is offset by 80 samples (10ms) each time.
We need the input speech sample driver to supply us with a 320 sample
(40ms) input vector. Various states need to be updated even though we
toss the output model parameters away for 3/4 of the frames in 700C.
Just transmitting the model parameters 1 in every 4 frames is like
"decimation in time" of any sampled sequence. At the decoder, to
reconstruct the missing frames (say 2,3,4) we interpolate between need
frames 1 and 5.
So we could send a sequence of frames 1,5,9 or 2,6,10 ... either way you
get a 40ms latency.

The 40ms I get, but to me the current code looks like it is introducing
yet another 30ms latency by not taking the updated model into account
untill the next call to the function. I can even see it in the energy
output of the different frames, it is almost a whole frame delayed
compared to the other modes.
Wouldn't the following change remove the 30ms without changing the reset
of the interpolation?

--- src/codec2.c (revision 2964)
+++ src/codec2.c (working copy)
@@ -1797,8 +1797,11 @@

memset(bits, '\0', ((codec2_bits_per_frame(c2) + 7) / 8));

- analyse_one_frame(c2, &model, speech);
+ for(i=0; i<M; i++) {
+ analyse_one_frame(c2, &model, &speech[i*N_SAMP]);
+ }

+
int K = 20;
float rate_K_vec[K], mean;
float rate_K_vec_no_mean[K], rate_K_vec_no_mean_[K];
@@ -1812,10 +1815,6 @@
rate_K_vec_no_mean,
rate_K_vec_no_mean_);

- for(i=1; i<M; i++) {
- analyse_one_frame(c2, &model, &speech[i*N_SAMP]);
- }
-
pack_natural_or_gray(bits, &nbit, indexes[0], 9, 0);
pack_natural_or_gray(bits, &nbit, indexes[1], 9, 0);
pack_natural_or_gray(bits, &nbit, indexes[2], 4, 0);

[David Rowe]

Yes I think you're right Jereon! Well done - that's a subtle one and I
had to drink 2 cups of coffee and mess about with pencil and paper to
see the issue :-)

I've updated codec2.c and the C<->Octave unit tests with your fix.

Thanks,

David

Post by Jeroen Vreeken

Post by David Rowe
We need to call analyse_one_frame() every 10ms as that's the internal
frame rate of the core sinusoidal modeling inside Codec 2. Note the ptr
into the input speech vector is offset by 80 samples (10ms) each time.
We need the input speech sample driver to supply us with a 320 sample
(40ms) input vector. Various states need to be updated even though we
toss the output model parameters away for 3/4 of the frames in 700C.
Just transmitting the model parameters 1 in every 4 frames is like
"decimation in time" of any sampled sequence. At the decoder, to
reconstruct the missing frames (say 2,3,4) we interpolate between need
frames 1 and 5.
So we could send a sequence of frames 1,5,9 or 2,6,10 ... either way you
get a 40ms latency.

The 40ms I get, but to me the current code looks like it is introducing
yet another 30ms latency by not taking the updated model into account
untill the next call to the function. I can even see it in the energy
output of the different frames, it is almost a whole frame delayed
compared to the other modes.
Wouldn't the following change remove the 30ms without changing the reset
of the interpolation?
--- src/codec2.c (revision 2964)
+++ src/codec2.c (working copy)
@@ -1797,8 +1797,11 @@
memset(bits, '\0', ((codec2_bits_per_frame(c2) + 7) / 8));
- analyse_one_frame(c2, &model, speech);
+ for(i=0; i<M; i++) {
+ analyse_one_frame(c2, &model, &speech[i*N_SAMP]);
+ }
+
int K = 20;
float rate_K_vec[K], mean;
float rate_K_vec_no_mean[K], rate_K_vec_no_mean_[K];
@@ -1812,10 +1815,6 @@
rate_K_vec_no_mean,
rate_K_vec_no_mean_);
- for(i=1; i<M; i++) {
- analyse_one_frame(c2, &model, &speech[i*N_SAMP]);
- }
-
pack_natural_or_gray(bits, &nbit, indexes[0], 9, 0);
pack_natural_or_gray(bits, &nbit, indexes[1], 9, 0);
pack_natural_or_gray(bits, &nbit, indexes[2], 4, 0);
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Hello,

Over the weekend I have integrated the 700C Codec 2 with the FreeDV API
and FreeDV GUI programs. The 700C FreeDV mode uses the 700C codec and
the 700 bit/s coherent PSK modem developed a few years ago. It works OK
for me between radios on the bench.

With Brady's help, the 800XA mode has also been added. This also uses
the 700C codec but is teamed with the 4FSK modem we have developed for
VHF/UHF work. The extra 100 bit/s is for frame synchronization. This is
a bit experimental for HF work, but has the advantage of being a
constant power waveform. I tested it today and managed to smoke up the
balun in my end fed antenna (which is rated for SSB I guess not CW)!

On my bench tests 800XA still has issues with losing sync with non-flat
SSB filters, Brady and I will work on that over the next few weeks. The
same modem is working really well with 100 kbit/s UHF SSTV:

http://www.rowetel.com/?p=5344

The FreeDV code is all checked in, so some of you might like to build
and try it it. We will look at getting some Windows versions built shortly.

It's early days for 700C and 800XA. My first goal is to see if FreeDV
700C works at least as well as FreeDV 1600 in terms of speech quality
and robustness.

Next steps will include making 700C more robust to HF channel issues,
and another lap around the codec development to see if we can improve
speech quality. Once we are happy that it's an improvement on FreeDV
1600 we'll see about a SM1000 port.

Thanks,

David

[Walter Holmes]

Anyone had a chance to spin up a Windows version yet?

Walter/K5WH

-----Original Message-----
From: David Rowe [mailto:***@rowetel.com]
Sent: Monday, January 16, 2017 1:06 AM
To: freetel-***@lists.sourceforge.net
Subject: [Freetel-codec2] FreeDV 700C and 800XA

Hello,

Over the weekend I have integrated the 700C Codec 2 with the FreeDV API and
FreeDV GUI programs. The 700C FreeDV mode uses the 700C codec and the 700
bit/s coherent PSK modem developed a few years ago. It works OK for me
between radios on the bench.

With Brady's help, the 800XA mode has also been added. This also uses the
700C codec but is teamed with the 4FSK modem we have developed for VHF/UHF
work. The extra 100 bit/s is for frame synchronization. This is a bit
experimental for HF work, but has the advantage of being a constant power
waveform. I tested it today and managed to smoke up the balun in my end fed
antenna (which is rated for SSB I guess not CW)!

On my bench tests 800XA still has issues with losing sync with non-flat SSB
filters, Brady and I will work on that over the next few weeks. The same
modem is working really well with 100 kbit/s UHF SSTV:

http://www.rowetel.com/?p=5344

The FreeDV code is all checked in, so some of you might like to build and
try it it. We will look at getting some Windows versions built shortly.

It's early days for 700C and 800XA. My first goal is to see if FreeDV 700C
works at least as well as FreeDV 1600 in terms of speech quality and
robustness.

Next steps will include making 700C more robust to HF channel issues, and
another lap around the codec development to see if we can improve speech
quality. Once we are happy that it's an improvement on FreeDV
1600 we'll see about a SM1000 port.

Thanks,

David


----------------------------------------------------------------------------
--
Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon
Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Freetel-codec2 mailing list
Freetel-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Jeroen Vreeken]

Hi David,

I tried to run the octave code today buty seem to be missing a file
called 'train_120_vq'.
Do I have to generate it first? I could not find any reference in the
rest of the code besides the octave scripts trying to load it...

Regards,
Jeroen

[David Rowe]

Here you go:

http://rowetel.com/downloads/codec2/train_120_vq

It's the vector quantiser, for some reason it's rather big in Octave
format (10M). Same files as C source are more reasonable 200k.

Can show you how it was trained up if that's of interest. One possible
area of optimisation.

Cheers,

David

Post by Jean-Marc Valin
Hi David,
I tried to run the octave code today buty seem to be missing a file
called 'train_120_vq'.
Do I have to generate it first? I could not find any reference in the
rest of the code besides the octave scripts trying to load it...
Regards,
Jeroen
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[Steve]

I think your file has other data in it. The last data at the bottom
seems to be the good stuff. Well anyway, it looks like the data in the
codebook directory.

Not a professional detective though :-)

Post by David Rowe
http://rowetel.com/downloads/codec2/train_120_vq
It's the vector quantiser, for some reason it's rather big in Octave
format (10M). Same files as C source are more reasonable 200k.
Can show you how it was trained up if that's of interest. One possible
area of optimisation.
Cheers,
David

Post by Jean-Marc Valin
Hi David,
I tried to run the octave code today buty seem to be missing a file
called 'train_120_vq'.
Do I have to generate it first? I could not find any reference in the
rest of the code besides the octave scripts trying to load it...
Regards,
Jeroen
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

[David Rowe]

Ok that explains it - thanks Steve.

Post by Steve
I think your file has other data in it. The last data at the bottom
seems to be the good stuff. Well anyway, it looks like the data in the
codebook directory.
Not a professional detective though :-)

Post by David Rowe
http://rowetel.com/downloads/codec2/train_120_vq
It's the vector quantiser, for some reason it's rather big in Octave
format (10M). Same files as C source are more reasonable 200k.
Can show you how it was trained up if that's of interest. One possible
area of optimisation.
Cheers,
David

Post by Jean-Marc Valin
Hi David,
I tried to run the octave code today buty seem to be missing a file
called 'train_120_vq'.
Do I have to generate it first? I could not find any reference in the
rest of the code besides the octave scripts trying to load it...
Regards,
Jeroen
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
https://lists.sourceforge.net/lists/listinfo/freetel-codec2