Hi Greg, Thanks for your comments, good to get a perspective from a non DSP person. Some thoughts:
1/ The modes are not interoperable. 2/ The "stable" question is a good one. I consider codec2 unstable, as I am dissatisfied with performance and enjoy experimenting. Having said that, the youngest mode is now 7 years old, and some haven't changed in a decade. I don't think we'd remove any existing modes that had a user base > 1. We do intend to converge on a smaller number of (improved) modes for Codec 2 and FreeDV over the course of the next few years. 3/ Re documenting (e.g. IETF style), I'm also pondering the best way to document Codec 2. Corner use-cases I can think of are alternative implementations (say on a FPGA or non-C99 compilers). I say corner cases as .... in 99% of cases why not just use the reference C code? My current position is to use a combination of doc, reference C code, and automated tests. There are so many moving parts to codecs that I feel the IETF paper-only style is not a strong approach. G729, for example, has come with C code since the mid 1990s. As a counter example - AMBE doesn't - which creates a barrier to entry. Also - in an open source world - why not use the other tools we have like the actual source code, and modern practices like automated tests? Thanks, David On Wed, 2023-12-13 at 10:08 -0500, Greg Troxel wrote: > david <da...@rowetel.com> writes: > > > Here is first version of some Codec 2 algorithm documentation: > > > > https://github.com/drowe67/codec2/blob/main/doc/codec2.pdf > > > > It has a description aimed at Hams (sort of thing that could go in > > a > > Ham magazine), plus a maths/signal processing section. It pulls > > together a bunch of work I've done since the start of the > > project. Kindly funded by our ARDC grant. > > > > I'm interested in review comments: > > > > 1/ Any typos/spelling, wording issues. A GitHub PR would be best > > for these if you are comfortable with Git. > > 2/ Anything that is not explained clearly? Other topics that you > > would like to see covered? > > I'm coming at this as someone who worked in network protocols (sort > of > IETF adjacent) and has a hazy understanding of speech coding. I've > been > lurking forever silently cheering you on. > > Some meta comments about issues belonging in a spec. These are > partly > about my impressions over the years, and a bit about the document. > > First, I think "codec2" is a family of codecs. There are various > modes > described by bitrate. A decoder for one probably does not process > the other. Or maybe it does and I'm confused. The first point > under > introduction says most of this, but it doesn't address interop. I > realize "a codec with modes" and "a family of codecs" is perhaps > just > wording choice, but to me the key point is that with the second > phrasing there is no expectation that a 700C decoder will decode a > 700A stream, and even less so that it will decode a 3200 stream. > > I have long been unclear on whether codec2 is stable, in that if > one > builds a device that uses a currently-defined mode that this can be > expected to remain interoperable over the long term. I'm getting > the > impression that each mode designation is by fiat stable, but that > some > modes get retired. And that therefore "implementing codec2" must > be > done in such a way that a slightly different algorithm needs to be > able to be loaded. But with an expectation the processing > requirements will not substantially change. It now seems to be > that > "700C" is a fixed definition, at least for the decoder, and that is > guaranteed to remain. But, there might be a 700D. (And yes, I get > it > that 700 is much harder than 2400 to sound ok and hence there are > more > revisions.) > > I have the impression that for a given mode, say 2400, there is a > single correct way to decode. But that encoding might have valid > choices within the spec, resulting in better estimated parameters, > with no need for the decoder to be different. > > I think there should be a document that specifies each mode. That > can > be one doc for all, or per mode, and referring to a common > doc. None > of that is important; the point is that someone who wishes to > implement a mode from scratch can assemble a pile of paper and > implement from that, without reading your source code, and come up > with an interoperable implementation. This is the IETF way, and i > think it has great merit. It's also a huge amount of work. In > the > codec2 part, the theory and the "why are we doing it this way" > seems > to be the hardest part, and "this is what the bitstream means" > seems > simpler. The document seems to be short of this, not explaining > the > bit format.s > > > I have downloaded the file to really read it. > > > > > I think it would be great if there were tools to unpack the bitstream > to say json, to make writing random analysis code easier, and to be > able > to have something that works like tcpdump. > > hope this helps... > > 73 de n1dam _______________________________________________ Freetel-codec2 mailing list Freetel-codec2@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freetel-codec2
