Discussion:
[Freetel-codec2] codec Specification?
Sebastien F4GRX
8 years ago
Permalink
de F4GRX

Hello,

Is there somewhere a detailed specification of codec2 that would allow
implementation from scratch without looking at the current code?

I'm not talking about the modulation here, only from speech samples to/from raw
bitstream.

Thanks,

Sebastien
Tomas Härdin
8 years ago
Permalink
Hi

"The truth is in the code", as they say :)

Writing a spec yourself may be worthwhile as a way of understanding the
code. David's blog is a good resource as well

/Tomas SA2TMS
Post by Sebastien F4GRX
de F4GRX
Hello,
Is there somewhere a detailed specification of codec2 that would allow
implementation from scratch without looking at the current code?
I'm not talking about the modulation here, only from speech samples to/from raw
bitstream.
Thanks,
Sebastien
David Rowe
8 years ago
Permalink
Post by Sebastien F4GRX
Is there somewhere a detailed specification of codec2 that would allow
implementation from scratch without looking at the current code?
No.

Thinking about it, my preference is to express the Codec in source code.
I've implemented speech codecs in the past from written specifications
and it's a messy business. Plus a maintenance nightmare to keep the
specification and code aligned.

- David
Sebastien F4GRX
8 years ago
Permalink
Hello

well, this is a problem for me.

Imagine if one of my projects was to write a BSD licenced codec2 implementation.

So my only option would be to reverse engineer a bunch of open source gpl
licenced code?

I guess the problems you had were related to bad specifications, not an
intrinsic problem of formal specifications.

But thanks for the clear status update, now I know what I have to do :)

73 de Sebastien
...
Alexandru Csete
8 years ago
Permalink
Sebastien,

Just bo clear, the codec2 library itself comes with LGPL license, not GPL.

If you need codec2 in a closed source application you can use the
current LGPL implementation as long as dynamic linking is sufficient.

If static linking is required, perhaps David can be persuaded to sell
a license with static linking exception.

The only other use case I can think of is to have the possibility for
making and distributing derivatives, without obligation to share the
changes with the community, who created the original work. I strongly
feel that such things would go against the spirit of this project and
everything it stands for, and it will probably not have much sympathy
amongst the project owners.

So please consider whether your use case truly requires a BSD
implementation or the existing LGPL library is sufficient.

Alex
...
Ricardo Andere de Mello
8 years ago
Permalink
hum...

I understand the value of the source code, but for me at least, that would
like to mantain a java and a as3 version of the codec, the lack of
specification was also the reason to not trying to do it at all.
I saw maybe two attempts of java versions, but I did not bother to look at
them because:
1 - There was no way to see if it was correct without I reading the
original C source code
2 - They would be deprecated in minutes, because the code is always
evolving and there is not a "version" number with specifics implementation
details.
See, if it is trouble for you, that own the code, and made it, to mantain
the specification of a "moving target", imagine for five or six
implementers, that are more interested in using your code, than
understanding it.
Without a specification we cant even say, at all, if it is hard or easy to
implement it in any other language.

I know it is fun to keep the development forever, but codec2 maybe coulda
be codec2.1, codec2.2, codec2.3, etc...:)

[]s, Ricardo Mello
...
Bruce Perens
8 years ago
Permalink
The codec is LGPL, not GPL. You have a right to read it and do not have to
reverse-engineer it, but do not cut and paste the code or its _structure_
if you want to avoid David's copyright. If you want to do something useful
rather than just a BSD version of LGPL code, make it fixed-point instead of
float.

Bruce

On Mon, Mar 20, 2017, 06:00 Ricardo Andere de Mello <
...
Sebastien F4GRX
8 years ago
Permalink
Hello all,

I am happy that my question triggered interest from such an interesting group of
people.

The BSD was just a thought experiment, please do not worry. I am very well aware
of the importance of keeping this code open and ensure it *stays* open.

My real goal is to understand this codec as best as possible, so a specification
would have helped.

Code, well, is only one possible implementation and has some added complexities.

After all, the important thing about codec2 is that we are able to understand it
from A to Z...

I think that writing a specification myself is the best possible action to
achieve this goal.

Several code bases are available: the reference C code, the java test code
previously published by Steve, and the Octave scripts.

I am not interested in a rewrite for the sake of changing the licence. This
makes no sense! I am interested in the embedded side of things, so a fixed point
version is exactly what I think is interesting. This fits in my wider personal
plans. And if I ever write something like this, it will be GPL licenced.

Thank you to everyone.

73's de F4GRX Sebastien
...
David Rowe
8 years ago
Permalink
Hello Sebastien,
Post by Sebastien F4GRX
I think that writing a specification myself is the best possible action to
achieve this goal.
I'm happy to advise on teh structure and review it for you. As an
intermediate step, more "how it works" documentation would be useful.

A way to verify implementations would be useful, like test vectors of
the codec input/output and internal processing steps. I do quite a lot
of that when I port algorithms from Octave to C.

Cheers,

David
Sebastien F4GRX
8 years ago
Permalink
Hello

Yes test vectors could be useful, but it's not easy since a lot of values are
floating point. Also, intermediate values and model internal parameters.

I mean, small ones, just enough data to feed the analysis steps and produce
output, 320 samples if I understand correctly.


I have started to write a document after looking at Steve's java code, It seems
to be a close translation from C code.

I will have a look at your C code in the coming days but I have a busy DIY
schedule. I will ask questions on this list.

Thanks for the support.

Sebastien
...
Steve
8 years ago
Permalink
Post by Sebastien F4GRX
I have started to write a document after looking at Steve's java code, It seems
to be a close translation from C code.
Since Java doesn't have pointers, I had to kludge in a few places. C
allows a lot of shortcuts with pointers.
The Java may help to understand the algorithms, but I would use the C
code as the primary guide in
developing a higher level description.

A better example might be:

https://github.com/ObjectToolworks/Vocoder1300

Which is a version I was working on, where the 50 MHz transmitter and
receiver were separated by 20 miles,
so I split out the encoder and decoder parts.

This is not to deprecate the main code, only in that the main code is
sometimes hard to discern which code is
relevant to which bit rate.

Have fun
Sebastien F4GRX
8 years ago
Permalink
Hello Steve,

Thank you for the pointer, I have added this to my study list.

I now have a mountain of fun things to study!

Hello Bruce,

Communicating about FreeDV and codec2 is in my todo list too. Maybe there is an
opportunity in June, in Paris, France. I will get back to this list when the
time comes but for now I just have to "lurk moar!".

73 de Sebastien
...
David Rowe
8 years ago
Permalink
Hello,

I'm putting together a blog post comparing various vocoders? Can any
one point me at a link for some TWELP 600 samples? They don't seem to
be on the DSP Innovations web site.

Thanks,

David
Steve
8 years ago
Permalink
If you scroll down a bit there are some samples. I'm pretty sure Codan
uses TWELP for 600 bps. It also uses MELPe for higher rates.

https://www.codanradio.com/product/2110manpack/

It is interesting that the manufacturer has no audio samples on their
own product :-)

It doesn't sound very good, but it sounds a lot better than the analog version.
David Rowe
8 years ago
Permalink
Thanks Steve yes I have found those samples, but the original speech
sample is not present.

Cheers,

David
...
David Rowe
8 years ago
Permalink
Some samples and discussion here:

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

- David
...
Steve
8 years ago
Permalink
Post by Sebastien F4GRX
I think that writing a specification myself is the best possible action
to achieve this goal.

Specifications are neat things. Especially for programmers who have little
knowledge/desire of/for the underlying math. For example:

*Analog specification*. The recommended analog requirements for the Codec2
coder are for a nominal bandwidth ranging from 100 Hz to 3800 Hz. To ensure
proper operation of the Codec2 coder, the A-D conversion process should
produce peak values of (or near) -32768 and 32767. Additionally, the coder
should have unity gain, which means that the output speech level should
match that of the input speech.

The specifications could be greatly simplified, in that the codec2 library
contains a lot of code that will never be used. The only two vocoders that
have been implemented with an user interface, are the 1300 bit/s, and the
700 bit/s. All the other vocoders are academic, and of no use to
implementer's.

There is a lot of common code though. Mostly the codebooks and method of
quantization being the difference.

Onward...
Bruce Perens
8 years ago
Permalink
Short of a full specification, you could publish a paper on observations of
David's codec, going from the source code, his blog posts, and his Ph.D.
thesis. Any number of technical publications would take that, and it's a
sure thing that the TAPR/ARRL DCC journal would take that paper if some
other journal doesn't. Since the codec itself is a moving target, explain
the concepts and algorithms first. That would equip more people to read
and/or write a spec and keep it up to date.

Bruce
...
David Rowe
8 years ago
Permalink
Only the new 700 modes are evolving, the earlier 3200-1200 bit/s modes
have been stable for years.

I'm happy to accept patches that deal with versioning, there is a
versioning function for the freeDV API, freedv_get_version(void).

I'm also happy to assist others to work on documentation, e.g. with
discussion and review.

- David
...
Loading...