PDA

View Full Version : Codec2 - Call To Action! - open source DSTAR alternative



AD7N
06-05-2010, 07:42 PM
ICOM's DSTAR protocol wasn't invented by ICOM, but rather by the Japanese Amateur Radio League (JARL). A *host* of information on the DSTAR (Digital Smart Technologies for Amateur Radio) protocol can be found here: http://en.wikipedia.org/wiki/D-STAR

How does the DSTAR protocol actually work?

The easiest to understand description I've found is in a PDF format attached to this post below. (Source here (enterprise.teqsys.net/ham/D-Star/G1-Lessons/Lesson%25203.pdf))

The DSTAR protocol packages not only voice into its digital packets but a "header" (much like Internet TCP/IP packets):

http://imgur.com/wtwlM.gif

In order to shoehorn voice (a very chaotic data set!) into a tiny digital channel, the JARL chose the AMBE voice codec by DVSI (http://www.dvsinc.com/papers/toll.htm).

So, what is the big complaint about AMBE?

Codec2 developer David Rowe, VK5DGR talks about this extensively: http://www.rowetel.com/blog/?p=128


Due to patents and the amount of confidential information surrounding these codecs (AMBE) I don’t think it is possible to make an open codec compatible with these closed codecs. It is however possible to develop a open source, free-as-in-speech codec with similar performance at similar bit rates. [...] A free codec helps a large amount of people and promotes development and innovation

Codec2 is an open source, developed-by-a-ham voice encoder algorithm that is in a highly experimental stage at this current point. It's advocates include Bruce Perens, K6BP (http://codec2.org/), who is well known in the Linux realm (helped found Debian Linux) and is a huge Free Software advocate.

Its current development is being spearheaded by David Rowe, VK5DGR. David helped write the famous & free SPEEX vocoder (http://www.speex.org/).

Why not use Speex then?

Well, Bruce Perens points out: (http://codec2.org/)

the existing Open Source codecs, like Speex, are designed for VoIP rather than an imperfect radio link, and are not generally able to cope with single-bit errors. Thus, they don't match the performance of AMBE over the air.

Thus, Codec2 was born. David Rowe has been working on it, however active development at this time is stalled (from an email I got from him). He is actively searching for funding to help keep him focused (and pay for family expenses) to help him keep going.
----------

It is tough to develop a codec that can compare to a commercially developed, heavily funded protocol like AMBE.

However, a fully open D-STAR protocol with open source vocoder technology opens up a whole exciting new prospect of ham experimentation. Rather than having the stumbling block of a closed source, proprietary technology powering it, a ham-hackable voice encoding algorithm allows for porting D-STAR to current handhelds and radios through simply hooking up a computer sound card, no proprietary hardware chip required.

N0SYA
06-05-2010, 08:28 PM
cool!



. . . and I realised he had read my document and understood it, and was now telling the Press about this. Now if you're like just a guy on the net who's not doing this for a job at all and you sort of write a manifesto and it spreads out through the World, and a year later the Vice President of Microsoft is talking about that you'd think you were on drugs wouldn't you? But that's what really happened.
—Bruce Perens

EI8DRB
06-05-2010, 09:34 PM
This is excellent news. The closed nature of the DStar voice codec is the reason I have had no interest in it... up to now. I will be making a personal contribution, however, this would only be a drop in the ocean... it would be excellent if industry or academia got behind this.

Funny... I always had it in my head that Bruce Perens would be an instigating influence in this.

WA4OTD
06-05-2010, 09:43 PM
I suspect there is more intellectual property than just the CODEC.

Just read through claims in this patent application. It is just an application so maybe never become patent but very likely.

http://www.google.com/patents?id=2HPNAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q&f=false

AD7N
06-05-2010, 09:51 PM
I suspect there is more intellectual property than just the CODEC.

Just read through claims in this patent application. It is just an application so maybe never become patent but very likely.

http://www.google.com/patents?id=2HPNAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q&f=false

The Crux of the issue is encoding - can a third party create a radio or software interface to existing radios to communicate with ICOM's DSTAR network?

I am no patent lawyer and can barely read through them to understand them without hours of re-reading.

AD7N
06-05-2010, 10:21 PM
If you want to help , check out David's section on his page for developers: http://www.rowetel.com/ucasterisk/codec2.html



check out the the Development Roadmap (http://www.rowetel.com/ucasterisk/codec2.html#plan) above and the latest version of the TODO (http://freetel.svn.sourceforge.net/viewvc/freetel/codec2/TODO.txt?view=log) list and and see if there is anything that interests you.

Not all of this project is DSP. There are many general C coding tasks like refactoring and writing a command line soft phone application for testing the codec over a LAN.

I will happily accept sponsorship for this project. For example research grants, or development contracts from companies interested in seeing an open source low bit rate speech codec. One interesting project would be funding a real time port to a single DSP/CPU chip.


Source code currently is available here: http://freetel.svn.sourceforge.net/viewvc/freetel/codec2/

Mailing List: https://lists.sourceforge.net/lists/listinfo/freetel-codec2

N0AZZ
06-06-2010, 12:57 AM
Why screw with something that works as well as D-Star and a world wide network that is already in place with radios and repeaters and plenty of ops and clubs supporting them.

Sounds like someone trying to reinvent the wheel or make a serious challenge against Microsoft for a OS it is not happening.

WA4OTD
06-06-2010, 01:16 AM
That is the step beyond the encoder. I think people assume the encoder is the key element, I think this is only the beginnning. This patent seems to cover this next step, the network and since they used a new packet format which has certain advantages I think you will need a license to even package data this way.

This is a quite complex patent and there are several more. THis is creating a monopoly within our hobby and every talks about how expensive D-Star is.

All we need is working group to layout the system and build this ourself using open tools. I think most companies like Yaesu, Alinco, Kenwood, etc would join an open standard group.

If you remember the VHS, D-Star = Beta the proprietary tape system created by Sony, for Sony and only Sony. It has been out 9 years and really only ICOM yet.


The Crux of the issue is encoding - can a third party create a radio or software interface to existing radios to communicate with ICOM's DSTAR network?

I am no patent lawyer and can barely read through them to understand them without hours of re-reading.

AD7N
06-06-2010, 01:47 AM
I heard from David Rowe who's been working on Codec2. Here's what his email read:


I should apologise for the lack of progress on codec2 since
last October. The project is still dear to my heart but I keep getting
distracted. However I am determined to complete the project. It will
happen. Just not sure when.

As Bruce suggests some sort of development/R&D contract or grant would
really help. Reporting to people paying me would focus me on the
project for a reasonable chunk of time and help prioritise it amongst
other paid work.

Re ICOM - I would be curious to know what they think of an open
standards alternative to DStar? It occurs to me that they may have a
lot invested in DStar which might make it hard to change directions.

Probably what Icom or any other manufacturer would need to see before
considering adoption is a working stack: voice codec-protocol-modem-FEC,
and an on-air comparison with DStar. Through the Ham community there
are ways to bootstrap this, e.g. come up with a PC based system first,
and get a community using it on air.

AD7N
06-06-2010, 01:49 AM
Why screw with something that works as well as D-Star and a world wide network that is already in place with radios and repeaters and plenty of ops and clubs supporting them.

Sounds like someone trying to reinvent the wheel or make a serious challenge against Microsoft for a OS it is not happening.

....and having the ability to simply download a program, plug your soundcard into your radio and access the DSTAR network doesn't sound sexy?

SV9OFO
06-06-2010, 07:55 AM
I suspect there is more intellectual property than just the CODEC.

Just read through claims in this patent application. It is just an application so maybe never become patent but very likely.

http://www.google.com/patents?id=2HPNAAAAEBAJ&printsec=abstract&zoom=4&source=gbs_overview_r&cad=0#v=onepage&q&f=false

IANAL, but AFAIK (:p) D-STAR is open source application.

I tried a bit to understand what are they patending, but I failed.

maybe tomorrow (yawn).

bonne nuit.

KS4VT
06-06-2010, 08:57 AM
IANAL, but AFAIK (:p) D-STAR is open source application.

I tried a bit to understand what are they patending, but I failed.

maybe tomorrow (yawn).

bonne nuit.

Pretty specific as to what is included in the application to include:

[0034] FIG. 1 is a diagram illustrating the D-STAR (Digital Smart Technologies for Amateur Radio) system, to which the data communication control apparatus according to the embodiment of the present invention is applied (D-STAR is a registered trademark of the Japan Amateur Radio League, Inc. in Japan).

KS4VT
06-06-2010, 09:05 AM
The Crux of the issue is encoding - can a third party create a radio or software interface to existing radios to communicate with ICOM's DSTAR network?

I am no patent lawyer and can barely read through them to understand them without hours of re-reading.

The patent seems to be focused on the infrastructure/call routing and not the end user devices after reading the whole thing last week, but I'm no patent attorney either.

Can someone invent a way to intergrate an analog radio? I shouldn't see why not, but how to they get around the AMBE vocoder patent/proprietary issues which is what this thread is really focused on.

G4ILO
06-06-2010, 10:13 AM
Why screw with something that works as well as D-Star and a world wide network that is already in place with radios and repeaters and plenty of ops and clubs supporting them.

Sounds like someone trying to reinvent the wheel or make a serious challenge against Microsoft for a OS it is not happening.

Competition is good. Alternative ways of using D-Star would bring down prices and increase its popularity. Many people's main objection to D-Star is that in order to participate they have to buy radios from Icom whose equipment many regard as overpriced already.

KA9MOT
06-06-2010, 10:20 AM
One step further........Overpriced Junk!

I base my opinion on my experience with Icom........

W9VER
06-06-2010, 12:44 PM
APCO-25 enough said.


(P25) is a set of standards produced through the joint efforts of the Association of Public Safety Communications Officials International (APCO), the National Association of State Telecommunications Directors (NASTD), selected Federal Agencies and the National Communications System (NCS), and standardized under the Telecommunications Industry Association (TIA)

N5RFX
06-06-2010, 01:24 PM
APCO-25 enough said.


The Telecommunications Industry Association (TIA) selected DVSI's vocoder as the standard for the APCO Project 25 North American land mobile radio communication system.

DVSI and APCO25 (http://www.dvsinc.com/prj25.htm)

One thing that is interesting about P25 is that it looks like patents issues have been addressed for P25 licensees. Motorola's P25 Essentials Licensing Program (http://business.motorola.com/publicsafety/licensing/programs_p25essentials.html)


Grants may include the right to make, distribute and sell P25-compliant TERMINALS and INFRASTRUCTURE EQUIPMENT.

I have not seen any amatuer development for P25 like there has been for DStar.

73,
Mark N5RFX

K5OKC
06-06-2010, 01:54 PM
I don't really understand why the project chose 2400 bps for the vocoder.

There's some reference to HF, but so far the AOR digital voice has been a complete failure (2400 + 1200 FEC) added to an OFDM modem results in a wide bandwidth that is easily jammed in a non-channelized environment.

It seems to me, they would do well to abandon 2400 and start at the next level 4800 or 9600. As a past user of secure phones at both 2400 and 9600, I can say the 9600 was a much better experience.

There is no need for 2400 bps vocoders at VHF and above. There's plenty of bandwidth. The modem does not have to fit in a 4 kHz bandwidth.

I'd rather have a modem do voice and data simultaneously, than some bulldozer design to smash the data down to some unreasonable value, for no other reason than given.

I discount the whole AMSAT thing. Those guys are not going to need a vocoder. All they have to do is repeat the bits, not what the bits mean.

Bonne journée

KS4VT
06-06-2010, 02:18 PM
One thing that is interesting about P25 is that it looks like patents issues have been addressed for P25 licensees. Motorola's P25 Essentials Licensing Program (http://business.motorola.com/publicsafety/licensing/programs_p25essentials.html)

I have not seen any amatuer development for P25 like there has been for DStar.

73,
Mark N5RFX


While Motorola has patented some what I would call enhancements to P25, this is a very important statement on their website:

Once identified, Motorola declares the patent to the TIA, and P25 licensees automatically gain access to these patents without additional cost or administrative burden.

I think one thing keeping AR development from occuring with P25 is the higher priced DVSI vocoders and licensing requirements for IMBE. If those AR developers wanted to be ahead of the curve I think they could be concentrating on a version of APCO Phase II/Amateur Radio technology. Now while it would still utilize the DVSI AMBE chip, that some have legitimate issues with, it could put us ahead of the developmental curve and think of things that the manufacturers haven't.

Just to make an operational statement, P25 users and repeater equipment outnumber D* in South Florida. The are only 2 D* repeaters in the area as compared to almost 10 mixed mode repeaters that welcome both analog and digital QSO's.

73

N5RFX
06-06-2010, 02:30 PM
It seems to me, they would do well to abandon 2400 and start at the next level 4800 or 9600. As a past user of secure phones at both 2400 and 9600, I can say the 9600 was a much better experience.

I agree, it would at least allow experimentation today, and I am sure improvements would follow. I would not discount the fact that some day we may need narrow occupied bandwidths on 70cm and above. Bill Cross, W3TN, a staff member in the FCC’s Mobility Division when speaking at the FCC forum mentioned:


Amateurs also have commercial interests, particularly the land mobile community, looking for an additional 30 MHz of spectrum, Cross explained. “Land mobile already is allocated 450-470 MHz,” he said. “You have 420-450 MHz on a secondary basis -- 30 MHz right next to an existing land mobile band. Although not ‘pure’ due to government radars like the PAVE PAWS systems and other uses, I would not be surprised if the land mobile community says we can make more efficient use of that spectrum than the hams do, and our use will create jobs. Stay tuned.”

More on Bill's speech here (http://www.arrl.org/news/bill-cross-w3tn-presents-fcc-forum-at-2010-dayton-hamvention).

73,
Mark N5RFX

N5RFX
06-06-2010, 02:54 PM
While Motorola has patented some what I would call enhancements to P25

Well here is a very important patent (http://www.freepatentsonline.com/5377229.html), that I would call more than just an enhancement.


Once identified, Motorola declares the patent to the TIA, and P25 licensees automatically gain access to these patents without additional cost or administrative burden.

Correct, after you are a licensee and have gone through the process and made the necessary payments they won't come back and ask you to re-negotiate the new patent disclosures.

What to Expect During the Licensing Process (http://business.motorola.com/publicsafety/licensing/process.html)


Just to make an operational statement, P25 users and repeater equipment outnumber D* in South Florida. The are only 2 D* repeaters in the area as compared to almost 10 mixed mode repeaters that welcome both analog and digital QSO's.

I wish that was the case in North Texas. I have P25 radios that I would like to try out on a repeater. The one P25 repeater that I know of is open for P25 use only for current Motorola club members. I tried to join the club, since I was a former Motorola employee, but the club only accepts current employees, retirees even aren’t invited.

I am going to be in Hollywood Fl. in two weeks. I think I should bring one of my P25 radios and check it out.

73,
Mark N5RFX

K5OKC
06-06-2010, 02:54 PM
...I would not discount the fact that some day we may need narrow occupied bandwidths on 70cm and above.

Now that the FCC is preparing to allow spread spectrum at 10 watts on 70cm, it may be the perfect band to deploy those experiments.

More virtual channels than physical. Maybe require repeater links to use SS in that band :-) (OK, no wars, just kidding...)

AE1PT
06-06-2010, 04:18 PM
Who says that history does not repeat itself?

An analogy to DSTAR might be found in the history of the PC. Once upon a time, there was only one company producing computers that seamlessly ran DOS and the applications written for it--IBM.

The trouble for any competitor was not in the actual hardware, but in the BIOS instructions that made it all work together. Several companies attacked this issue--and the solution was a reverse engineering "clean room" strategy in which the proprietary IBM BIOS was deconstructed to see what it did--and an entirely new set of instructions to accomplish the same ends created. This opened the door for new initiatives--most notably Compaq to offer a "PC Compatible" computer. I still have one of their first offerings in storage--the Compaq Portable Plus.

Is it not just the same challenge here?

What really seems to be the problem is that there is a cost attached to the DSTAR card. I suspect one could build one having the chip--but that is not the issue. Regardless of whether the DSTAR standard is reverse engineered or not--the reality is that the purchase of certain hardware components is necessary.

Too many people today want all the bells and whistles of everything for free. They expect talented individuals to create things and give them away. Some hobbyists might be happy to do this. Some find that the creation and continuing development of things becomes a full time endeavor to make it happen. Free just doesn't work there.

DSTAR is not a closed door. Sure, one has at least to buy a chip--something that I see as no different than having to buy a sound card to make other digital modes happen as well.

AD7N
06-06-2010, 04:55 PM
Who says that history does not repeat itself?

An analogy to DSTAR might be found in the history of the PC. Once upon a time, there was only one company producing computers that seamlessly ran DOS and the applications written for it--IBM.

The trouble for any competitor was not in the actual hardware, but in the BIOS instructions that made it all work together. Several companies attacked this issue--and the solution was a reverse engineering "clean room" strategy in which the proprietary IBM BIOS was deconstructed to see what it did--and an entirely new set of instructions to accomplish the same ends created. This opened the door for new initiatives--most notably Compaq to offer a "PC Compatible" computer. I still have one of their first offerings in storage--the Compaq Portable Plus.

Is it not just the same challenge here?

No. Codec2 is a *competitor* to AMBE, not a reverse-engineering project.

However, in order to make a *compatible* codec to AMBE, you are correct - a full-on reverse engineering project would have to be spear-headed. And this is something the Codec2 guys have suspected would be much, much harder than writing a seperate codec.



What really seems to be the problem is that there is a cost attached to the DSTAR card. I suspect one could build one having the chip--but that is not the issue. Regardless of whether the DSTAR standard is reverse engineered or not--the reality is that the purchase of certain hardware components is necessary.

No - existing digital-mode technology would be utilized if a purely software codec for DSTAR was available. The DSTAR protocol is open and has already been implemented for computer soundcards and decodable by multipurpose CPUs (netbooks, laptops, old PDAs, smartphones etc etc!). The Digital Voice decode/encode requires the DVdongle with the AMBE chip on it.



Too many people today want all the bells and whistles of everything for free. They expect talented individuals to create things and give them away. Some hobbyists might be happy to do this. Some find that the creation and continuing development of things becomes a full time endeavor to make it happen. Free just doesn't work there.


The Linux operating system would be where GNU Hurd is today (dead in the water) if it weren't for many developers donating time (and being paid with donations or contracts in some cases). David Rowe, VK5DGR has developed the preliminaries for the Codec2 already, and has hit several milestone's in its development. (http://www.rowetel.com/ucasterisk/codec2.html#plan)

He also noted this in a recent email:


It also helps just a lot when people like you contact me re the project. Helps raise it on my to-do list when I know there is interest :-)

Cheers,

David

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



DSTAR is not a closed door. Sure, one has at least to buy a chip--something that I see as no different than having to buy a sound card to make other digital modes happen as well.

DSTAR is the only major digital mode (outside of PACTOR II/III) that a ham radio op has to buy additional hardware outside of his current digital mode setup. Sure, AMBE is an awesome codec. Yet, it simply doesn't belong in the Amateur Radio world!

KC2UGV
06-06-2010, 04:59 PM
...clip...
This is a quite complex patent and there are several more. THis is creating a monopoly within our hobby and every talks about how expensive D-Star is.
...clip

An easy example of how the AMBE2020 is the only key part, the DV Dongle can convert any radio to a DStar unit.

Problem is, the AMBE2020 chip is closed, and single-sourced.


...clip...
DSTAR is not a closed door. Sure, one has at least to buy a chip--something that I see as no different than having to buy a sound card to make other digital modes happen as well.

No, the closer analogy would be MCA architecture vs. ISA. MCA was IBM's bus, and only available through licensing (And had the Blue tabs on the cards).

As for your "sounds card" analogy, you can buy a sound card from any number of sources. And they are more or less guaranteed to work with your hardware.

K5OKC
06-06-2010, 05:24 PM
As for your "sounds card" analogy, you can buy a sound card from any number of sources.

But why buy a soundcard for $50 when you can buy a chip for $25 :-)

AD7N
06-06-2010, 05:27 PM
But why buy a soundcard for $50 when you can buy a chip for $25 :-)

Because a $25 chip is just that, a postage-stamp chip with raw leads and silicon :D

Unless you can work voodoo to pull the signals from the raw chip, you'll need a BUNCH of supporting hardware! Its MUCH more than just a $25 chip!

AE1PT
06-06-2010, 09:25 PM
DSTAR is the only major digital mode (outside of PACTOR II/III) that a ham radio op has to buy additional hardware outside of his current digital mode setup. Sure, AMBE is an awesome codec. Yet, it simply doesn't belong in the Amateur Radio world!

The real point here is that digital modes are contingent upon support OUTSIDE of the radio in its simple transmit/receive design--both in the hardware and software domains. Try PSK without a computer, or RTTY without a computer or bulky TTY console. DSTAR utilizes a "black box" algorithm that is embedded in a LSIC device--which is then incorporated inside the transceiver package. Yes, there are dongles, but that is a different case that is most often used in fixed or repeater installations. I think that we can concede that a software based algorithm/decoding program could be created if enough focus were directed at the process.

Yet this does nothing for the fact of how a large percentage of hams use DSTAR--through HT and mobile transceiver setups. To make such rigs able to process DSTAR--we are still looking at a "DSTAR Compatible" hardware solution. Unless of course, the plan is for the DSTAR HT operator to tote a notebook on their backs...:cool:

So necessarily, whatever "new codec" were to be applied to the pragmatic use of DSTAR protocols must still reside in a hardware board of some sort--which must be either purchased or built by the ham intending to use it. Given the transceiver design influence of Icom in providing compact HT and mobile packages that are ready to "rock & roll" with the addition of a board--my feeling is that DSTAR under it's current proprietary algorithm will continue to lead the way for quite some time.

KC2UGV
06-06-2010, 10:17 PM
But why buy a soundcard for $50 when you can buy a chip for $25 :-)

Because a sound card can do more than just perform as a vocoder... And you can get a sound card for around $15 bucks.

AD7N
06-06-2010, 11:02 PM
The real point here is that digital modes are contingent upon support OUTSIDE of the radio in its simple transmit/receive design--both in the hardware and software domains. Try PSK without a computer, or RTTY without a computer or bulky TTY console.

The K3 and other high-end HF rigs have decoding right on the front panel. Sure there's plenty of differences (hardware, mode, etc) *but* DSTAR isn't the only "shack-in-a-box" digital mode implementation out there! Many new HF rigs have a USB port right on the back for a keyboard!


I think that we can concede that a software based algorithm/decoding program could be created if enough focus were directed at the process.


An AMBE-compatible software solution would come from one of two avenues:

1)AMBE reverse engineered and completely original software utilized - the hardest path (possible but not without *MASSIVE* development)
2)DVSI drops their software licensing cost (new car or AMBE software license?)

Is it *possible*? yes, but not without one of the above (both highly unlikely with current situation, but #1 is more likely).

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


Yet this does nothing for the fact of how a large percentage of hams use DSTAR--through HT and mobile transceiver setups. To make such rigs able to process DSTAR--we are still looking at a "DSTAR Compatible" hardware solution. Unless of course, the plan is for the DSTAR HT operator to tote a notebook on their backs...:cool:

So necessarily, whatever "new codec" were to be applied to the pragmatic use of DSTAR protocols must still reside in a hardware board of some sort--which must be either purchased or built by the ham intending to use it. Given the transceiver design influence of Icom in providing compact HT and mobile packages that are ready to "rock & roll" with the addition of a board--my feeling is that DSTAR under it's current proprietary algorithm will continue to lead the way for quite some time.

A "phase out" period over years would have to be implemented... this wouldn't be overnight!!

How?
Once Codec2 was comparable enough to AMBE to garner serious competition, approach the JARL with it! They're the gatekeepers of the DSTAR protocol. They are the ones who looked at open codecs almost a decade ago, and decided AMBE (then) was the best option. If they saw a serious open source, developed-by-a-ham codec, they would probably seriously look at adding it to the protocol!

If the JARL added it to the DSTAR protocol as an update, it would be relatively *easy* for ICOM to implement it as a firmware update. If they were hesitant (probably at first), it would simply boil down to an education campaign to get ICOM DSTAR owners hounding for it.
---------------

How could it be implemented guerrilla-warfare style?
Third-party daughter board! Its gotta include an AMBE chip & Codec2, and be able to autodetect which codec is being used and seamlessly switch between both. As market share of Codec2 increased, it would find higher and higher market share and eventually overtake AMBE...

Firstly, this third-party board would have to be manufactured cheaper or nearly the same cost as UT DSTAR drop-in boards - this is possible if an at-cost type model is used (see softrock40 for example of at-cost ham manufacturing) at least at first.

Secondly, ICOM DSTAR owners wouldn't be the only ones implementing Codec2! Mobile hams would implement laptop/radio setups next, and base station users. It'd start out in "fresh" areas that haven't used AMBE DSTAR yet - clubs etc.

These groups would have visibility and begin to show their influence.

This timespan of rollout is years, not months.

Codec2 market share would start off tiny for the first years until it matured and got a critical mass of users. When or how really? If I knew I'd be selling books on market economy!:cool:
--------------------------

KS4VT
06-06-2010, 11:27 PM
I am going to be in Hollywood Fl. in two weeks. I think I should bring one of my P25 radios and check it out.

73,
Mark N5RFX

Depending on your altitude of your accomodations, Motorola's 146.79 and 443.00 should be available to you. Mine are in Boca, a good 20+ miles away, so unless your staying over the 5th floor with a northern exposure I don't think you will be able to talk to 147.39 or 442.00.

AD7N
06-07-2010, 04:17 PM
How would Codec2 be best implemented? Joel Koltner, KE7CDV offers this brilliant tidbit from the Dstar_digital yahoo group:


most hams operate D*Star through repeaters anyway, one approach here would be to have the *repeater* have both AMBE and CODEC2 (or whatever) capabilities, and just translate between them on-the-fly. (This approach is used with public service radio systems, since there lots of different companies decided to build their own proprietary protocols and used different CODECs as well.) I would wager that repeater usage probably accounts for more than 90% of D*Star voice traffic, and getting repeater builders to incorporate a backwards compatible radio into their system (that has the same interface as the current Icom boxes) is nowhere near as daunting as getting everyone with an HT or mobile D*Star rig to buy something new.
The repeater could seamlessly translate to and from existing the D*Star gateway to both codecs!

AD7N
06-07-2010, 05:16 PM
I think hams have become senile with the proprietary codec, and asssume "its here, that's the way it should be and will always be". Sure, ICOM's radios and the DSTAR protocol itself dictate AMBE codec use. However, a open source codec allows infinite latitude to experimenters in software installations and inexpensive (FREE) soundcard etc etc experimentation *without* the need for a hardware chip layer.

AB9LZ
06-07-2010, 05:45 PM
I think hams have become senile with the proprietary codec, and asssume "its here, that's the way it should be and will always be".

I think the percentage of Hams that have a need for any codec of any kind, is ifintesimal... hence the reason why no one really cares.

73 m/4

AD7N
06-07-2010, 06:36 PM
I think the percentage of Hams that have a need for any codec of any kind, is ifintesimal... hence the reason why no one really cares.

73 m/4

And thus why D-STAR is still in the crib...

WB3BEL
06-07-2010, 06:47 PM
This looks like it's going into the weeds pretty fast.

Folks recommending 2 to 4 X the data rate for the same voice quality...

You do understand that if you keep everything else the same it takes 2X to 4X the transmit power to close the same link with the same quality?

The only real reasons to have higher rate is to:
a) have a more natural sounding voice. But the cost penalty is shorter range or using more power...There is no free lunch here.
b)Have integrated voice and packet data service. When you transmit higher data rate you need to use more power. If you just want to squeeze performance and only need voice, you need the low rate voice. It will work better if you are at range limit or in noisy environment with small terminal and crappy antenna. I think that the design tradeoff here to optimize for handheld was sensible and if you rethought it you would end up at the same solution.

Folks recommending transcoding between AMBE and "Some new low rate vocoder"

This is almost guaranteed to sound really really really crappy. On top of that those proposing it don't know the AMBE vocoder algorithm so that they can't implement the transcoder without two steps...

Folks proposing alternate Air Interface like CDMA over TDMA. Don't understand basic communication theory. CDMA does not offer any advantage over TDMA for noise limited not interference limited channel. Pop open a textbook or use your web browser to study Shannon limit. There is no magic here either.

K5OKC
06-07-2010, 06:56 PM
You do understand that if you keep everything else the same it takes 2X to 4X the transmit power to close the same link with the same quality?

You do understand that 2400 bps vocoders suck?

Most Hams use too much power anyway.

WB3BEL
06-07-2010, 07:16 PM
You do understand that 2400 bps vocoders suck?

Heh heh...I've heard loads of digital voice codecs...Tune your speech to match. Get in a quiet environment. Don't shout or panic...Lots of tradeoffs here.

The part I was amused by was a goal for a vocoder with poorer sounding voice quality operating at higher bit rate...Seemed like a really well thought through plan...


Most Hams use too much power anyway.

I can't really agree with this one tho...I don't know why the other guys choose the power they do. I honestly can't say as I care unless its interfering with a station I want to listen to. That's not all that common on VHF/UHF/SHF. Obviously I think that I am running the right amount of power. Actually wish I had more available at times...

N5RFX
06-07-2010, 07:23 PM
I think that the design tradeoff here to optimize for handheld was sensible and if you rethought it you would end up at the same solution.

You are correct. I believe there are two goals here:

1. Make the codec free.
2. Make the codec code open source so that it can be improved through experimentation

I don't think anyone is under the illusion that the CODEC2 will out perform AMBE in the beginning, or perhaps ever. If someone is under that illusion, then they need to rethink their objectives. Also, a new codec will most likely be software in an outboard device like a PC with a souncard. This makes it less than ideal in a portable situation. but allows enhanced experimentation.

The AMBE codec is great for most applications; the only complaint is that it is:

1. Not free
2. It is not open source

Some feel that this is necessary for Amateur radio. I like the idea, but don't set this as my litmus test for being appropriate for Amateur radio.

I have no problem with the current DStar implementation, but I would welcome CODEC2 for experimentation, it would not even have to be used with DStar.

73,
Mark N5RFX

KC2UGV
06-07-2010, 07:26 PM
You are correct. I believe there are two goals here:

1. Make the codec free.
2. Make the codec code open source so that it can be improved through experimentation

I don't think anyone is under the illusion that the CODEC2 will out perform AMBE in the beginning, or perhaps ever. If someone is under that illusion, then they need to rethink their objectives. Also, a new codec will most likely be an outboard device that connects to a PC. This makes is less than ideal in a portable situation. but allows enhanced experimentation.

The AMBE codec is great for most applications; the only complaint is that it is:

1. Not free
2. It is not open source

I have no problem with the current DStar implementation, but I would welcome CODEC2 for experimentation, it would not even have to be used with DStar.

73,
Mark N5RFX

I don't even care about the price for the AMBE chip. It's the closed, proprietary nature of it.

If DVIS would ship the source, and not blow the read fuses, I'd buy it from them.

K5OKC
06-07-2010, 07:31 PM
The part I was amused by was a goal for a vocoder with poorer sounding voice quality operating at higher bit rate...Seemed like a really well thought through plan...

I don't remember reading that, but the bottom line, is if you take-away the 2400 bps vocoder, and go to a 9600 bps one, then your problems go away, and you can do your vocoder in software at high quality. Even full duplex.

The problem is, I think the anti-AMBE folks want to keep the 4800 bps modem. That's the blinders they are wearing.

Forget about the 4800 modem.

AD7N
07-02-2010, 01:42 PM
FYI - David Rowe is accepting PayPal donations to help further Codec2 development - http://www.rowetel.com/ucasterisk/codec2.html#help

And, if you speak the C programming language and you'd like to help Codec2 development, contact him! His email is David @ Rowetel.com

AD7N
07-02-2010, 01:45 PM
I don't remember reading that, but the bottom line, is if you take-away the 2400 bps vocoder, and go to a 9600 bps one, then your problems go away, and you can do your vocoder in software at high quality. Even full duplex.


Higher bit rates are very sexy, I don't argue on that point. However, my concern for future development is higher bitrates won't do much to help the ever-growing crowding problem in highly urban areas on 2m/70cm. At 2400 bit/s, the number of frequencies a repeater can operate effectively doubles, allowing much more expansion and room for future growth.

K5OKC
07-03-2010, 01:26 PM
I think the rules have changed now, but back in the early 90's I petitioned the FCC to allow TDMA in the VHF and up bands. My mind is gone now, but it was legal to use TDMA with data, but not voice. Since the Ham rules ruled it voice even if digital, then you couldn't just call it all data. Where my memory may be gone, is maybe it was vice-versa.

TDMA in HAM Radio (http://www.n4zkf.com/files/T_DOCS/TDMA.TXT)

Anyway, a low-tech method of TDMA is called trunking. Basically you have X frequencies and time in the equation. Back in the early 90's we didn't have GPS yet, and I proposed a sync channel on the radio, whereby two users could sync to each other.

With GPS you can synchronise easily, and with that, you can allow multiple virtual channels on one frequency. APRS would do well to introduce time into its protocol, and then more users or a faster cycle can be used.

Basically, you divide a frequency into time slots and users then transmit on that virtual channel. Say, four users on a frequency that only allowed one before.

To me, that's the only real reason to go digital versus analog.

WA4OTD
07-03-2010, 01:51 PM
I would like to see the block diagram of this system.

Somehow just having an encoder doesn't seem to do a lot. Need to packetize it along with correct headers and other system info? Right?




The Crux of the issue is encoding - can a third party create a radio or software interface to existing radios to communicate with ICOM's DSTAR network?

I am no patent lawyer and can barely read through them to understand them without hours of re-reading.

AF6LJ
07-03-2010, 01:57 PM
I have been following this thread with interest.
Open standards are always preferable over a closed system, I guess that is why I really don't care for winlink.

N4CYA
07-03-2010, 01:59 PM
I like the private mode...it feels private! :D:o:D

AD7N
07-04-2010, 11:35 PM
I would like to see the block diagram of this system.

Somehow just having an encoder doesn't seem to do a lot. Need to packetize it along with correct headers and other system info? Right?

Here you go - The DSTAR protocol, as spelled out by the JARL: http://www.jarl.com/d-star/shogen.pdf
JARL's header, etc. protocol is all open. The *only* closed source aspect is the vocoder, patented by DVSI Inc. Hence, a "fully open" DSTAR protocol would be one in which the only thing that changed would be an open-source vocoder.


ICOM's DSTAR protocol wasn't invented by ICOM, but rather by the Japanese Amateur Radio League (JARL). A *host* of information on the DSTAR (Digital Smart Technologies for Amateur Radio) protocol can be found here: http://en.wikipedia.org/wiki/D-STAR

How does the DSTAR protocol actually work?

The easiest to understand description I've found is in a PDF format (Source here (enterprise.teqsys.net/ham/D-Star/G1-Lessons/Lesson%25203.pdf))

The DSTAR protocol packages not only voice into its digital packets but a "header" (much like Internet TCP/IP packets):

http://imgur.com/wtwlM.gif

In order to shoehorn voice (a very chaotic data set!) into a tiny digital channel, the JARL chose the AMBE voice codec by DVSI (http://www.dvsinc.com/papers/toll.htm).

KS4VT
07-04-2010, 11:49 PM
Here you go - The DSTAR protocol, as spelled out by the JARL: http://www.jarl.com/d-star/shogen.pdf
JARL's header, etc. protocol is all open. The *only* closed source aspect is the vocoder, patented by DVSI Inc. Hence, a "fully open" DSTAR protocol would be one in which the only thing that changed would be an open-source vocoder.

Actually just recently iCOM applied for both a US and Japanese patent for the whole D* infrastructure and controller. This will create more of a closed system once it is awarded.

KS4VT
07-04-2010, 11:53 PM
Anyway, a low-tech method of TDMA is called trunking. Basically you have X frequencies and time in the equation. Back in the early 90's we didn't have GPS yet, and I proposed a sync channel on the radio, whereby two users could sync to each other.

You can do TDMA without trunking. Motorola has a protocol called Mototrbo that allows for 2 slot TDMA in a 25 KHz channel and IP connectivity. The only issue is that the protocol is just as closed as any other proprietary system and only Motorola radios can be utilized on it. But my point being is that TDMA can be done without the "typical" trunking infrastructure.

KS4VT
07-04-2010, 11:55 PM
I like the private mode...it feels private! :D:o:D

Just like using encryption in Part 90... :D :rolleyes:

WA4OTD
07-05-2010, 12:06 AM
We went through this once before, ICOM is patenting DSTAR. OF course understanding a large companies patent is daunting task! However their pictures, and claims are pretty broad. That is why I lean toward a system using Ethernet and MPEG for Audio, Video and data.

http://www.google.com/patents?id=93zQAAAAEBAJ&printsec=abstract&zoom=4#v=onepage&q&f=false


Here you go - The DSTAR protocol, as spelled out by the JARL: http://www.jarl.com/d-star/shogen.pdf
JARL's header, etc. protocol is all open. The *only* closed source aspect is the vocoder, patented by DVSI Inc. Hence, a "fully open" DSTAR protocol would be one in which the only thing that changed would be an open-source vocoder.

N0WYO
07-05-2010, 01:26 AM
I've said this before here. I foresee a unit that can be used to make any vhf radio d-star compatible if codec 2 is successful. It may bring the price of Icom radios down as well.

WA4OTD
07-05-2010, 02:19 AM
Please explain the system, I'm interested? How does the codec work with any VHF radio?



I've said this before here. I foresee a unit that can be used to make any vhf radio d-star compatible if codec 2 is successful. It may bring the price of Icom radios down as well.

AD7N
07-05-2010, 07:53 AM
We went through this once before, ICOM is patenting DSTAR

A patent application is not a patent by any means! Sure, they're trying to, however it is yet to be determined how much of the patent will be approved.

N0WYO
07-05-2010, 12:44 PM
Please explain the system, I'm interested? How does the codec work with any VHF radio?

this would work either through a program made to utilize the codec with the sound card. Then something similar to a rigblaster could be used to interface the radio with the computer, OR...


A separate, self contained unit designed to decode and encode D-star protocols. similar to a sub audible tone board for older radios. codec 2 would make this a reality fairly cheaply.

G4ILO
07-08-2010, 12:10 PM
I'm not sure it would be that easy. Some of the discussions about this that I've seen elsewhere suggest that the radio would be modulated the way digital modes are sent using SSB, not FM. Also it is suggested that the digital channels would be narrower than those used for analog FM, so the filter bandwidths of your old FM radio would be too wide.

You might be able to use an SSB radio to do this, but not an FM one.

AD7N
07-08-2010, 01:39 PM
I'm not sure it would be that easy. Some of the discussions about this that I've seen elsewhere suggest that the radio would be modulated the way digital modes are sent using SSB, not FM. Also it is suggested that the digital channels would be narrower than those used for analog FM, so the filter bandwidths of your old FM radio would be too wide.

You might be able to use an SSB radio to do this, but not an FM one.

You have a very good point here, Julian.

The only usage that will occur in the near future would be over standard FM, which of course would not be narrow-bandwidth. This would be the "soundcard solution" I have been talking about, and would make the entry bar low enough for most hams to enjoy.

However, to really fully utilize bandwidth squeezing SSB is definitely the way to go I agree!

N4CYA
07-08-2010, 01:49 PM
Just like using encryption in Part 90... :D :rolleyes:

Private is good! Some what understandable in digital garble at times. :rolleyes:

WA4OTD
07-08-2010, 01:58 PM
that's true, but big company, looks like a patent, smells like a patent, patent office is letting lot more stuff through these days, I would count on this becoming patent.


A patent application is not a patent by any means! Sure, they're trying to, however it is yet to be determined how much of the patent will be approved.

KS4VT
07-08-2010, 02:10 PM
Private is good! Some what understandable in digital garble at times. :rolleyes:

No digital garble on my system, even 10 miles or more outside of its designed footprint. The encryption just scrambles the bits of APCO25 so there is no loss of coverage or intelligibility whether it is in the clear or coded. :cool:

WA4OTD
07-08-2010, 02:31 PM
Not a complete investigation, but it does sound like you sound be able to modulate almost any FM radio.

http://www.k0nr.com/wordpress/2008/12/investigating-d-star-modulation-format/


this would work either through a program made to utilize the codec with the sound card. Then something similar to a rigblaster could be used to interface the radio with the computer, OR...


A separate, self contained unit designed to decode and encode D-star protocols. similar to a sub audible tone board for older radios. codec 2 would make this a reality fairly cheaply.

AD7N
07-08-2010, 02:40 PM
Not a complete investigation, but it does sound like you sound be able to modulate almost any FM radio.

http://www.k0nr.com/wordpress/2008/12/investigating-d-star-modulation-format/

WA4OTD - you had a suggestion of making a microphone which would encode-decode, and that is a damn good idea!

I see a Heil-Mic ad on the top of my screen, they could introduce a third-party mic that was AMBE AND Codec2 capable!

N4CYA
07-11-2010, 04:36 AM
No digital garble on my system, even 10 miles or more outside of its designed footprint. The encryption just scrambles the bits of APCO25 so there is no loss of coverage or intelligibility whether it is in the clear or coded. :cool:

I agree. I like D-Star miss being on it, I'll be back soon. Let me ask you this Mark what is the difference between D-Star Digital, APCO25 and the MotoTurbo?

KY5U
07-11-2010, 05:11 AM
France has outlawed D-Star and Internet controlled rigs, New Zealand is looking at doing the same. Might be something for the IARU. Cool.

WA4OTD
07-11-2010, 03:38 PM
I really think we should design a DSTAR alternative that will take in analog, a new digital (based on ethernet), and offer all of the internet options of DSTAR. The mic module could have ethernet interface and the codec.

The repeater should be able to receive digital or analog equally well. In other words a module on the detected output that either provides just audio or recognizes digital and then decodes that. With ethernet pretty simple to provide all the services of PC to PC.

This is just random thoughts off the top of my head but there should be a much better system if we though about this for awhile.

I think the mission statement of something like existing analog FM users keep the service they have (repeaters and end users), digital users can have digital voice and ethernet (internet) (repeaters and end users). this is achieved with module added to the mic input for the end user and module on the detected output for repeater.


WA4OTD - you had a suggestion of making a microphone which would encode-decode, and that is a damn good idea!

I see a Heil-Mic ad on the top of my screen, they could introduce a third-party mic that was AMBE AND Codec2 capable!

KC6TOA
07-11-2010, 06:01 PM
France has outlawed D-Star and Internet controlled rigs, New Zealand is looking at doing the same. Might be something for the IARU. Cool.

Indeed.
What this needs is an independent steering committee to arbitrate a standard with the equal participation of all ham-radio manufacturers and pertinent amateur radio organization bodies around the world.
Similar in style to the way IEEE arbitrates 802.whatever standards. Balancing the needs of all interested parties while preventing a member from sneaking in a subtly proprietary standard which gives them a competitive advantage.
For preventing internet controlled radios: Its not an easy thing if you make a radio designed to transfer computer data. Perhaps its best to leave such things as computer transfer as an option to be only sold in countries which permit it.
For ham radio, no standard should be implemented which cant be home-brewed using freely available software algorithms; or off-the-shelf parts.

AD7N
07-26-2010, 03:10 AM
UPDATE! Codec2 development has be reinstated - with preliminary schedule for alpha release by the end of 2010!

Developer David Rowe released this note on the Codec2 mailing list (https://lists.sourceforge.net/lists/listinfo/freetel-codec2):


Hello,

I've started working on codec2 again. I plan to get an alpha 2400 bit/s
version released in 2010. Current tasks:

+ exploring LSP quantiser design

+ determine why phase models sound worse when combined with LPC/LSP

I would still really appreciate some help on C coding issues like
writing a command line codec2 VOIP client that uses codec2 and some
re-factoring of the C code.

Cheers,

David

KI4NGN
07-26-2010, 12:07 PM
I have been following this thread with interest.
Open standards are always preferable over a closed system, I guess that is why I really don't care for winlink.

And yet the developer is asking for money to continue development.

Very amusing because even as an advocate of "free" software, he requires money. That's why I always laugh at these things. Some people think that despite all of the work that goes into software development, the result should be free. :)

AD7N
07-26-2010, 01:39 PM
And yet the developer is asking for money to continue development.

Very amusing because even as an advocate of "free" software, he requires money. That's why I always laugh at these things. Some people think that despite all of the work that goes into software development, the result should be free. :)

Did you read my update post? He's started development again.

And why shouldn't developers ask for support? Ham radio deluxe developers put out the hat: http://www.ham-radio-deluxe.com/

N9XLC
07-26-2010, 02:50 PM
And yet the developer is asking for money to continue development.

Very amusing because even as an advocate of "free" software, he requires money. That's why I always laugh at these things. Some people think that despite all of the work that goes into software development, the result should be free. :)

It's a way for non-coders to contribute in a helpful manner. It is still free software in that it's open source. It's just like including a schematic with a radio. If a component breaks you can look at the schematic, open it up and fix it. If you know what you are doing. Classic ham radio.

KI4NGN
07-26-2010, 07:22 PM
It's a way for non-coders to contribute in a helpful manner. It is still free software in that it's open source. It's just like including a schematic with a radio. If a component breaks you can look at the schematic, open it up and fix it. If you know what you are doing. Classic ham radio.

My point was directed at those who believe that all software should be open and free, and there are a lot of them out there. My point was that it costs time and resources (money) to develop software, and if those so engaged don't want to give it away or make it public, that is a decision that should be respected, not criticized.

KI4NGN
07-26-2010, 07:23 PM
Did you read my update post? He's started development again.

And why shouldn't developers ask for support? Ham radio deluxe developers put out the hat: http://www.ham-radio-deluxe.com/

I didn't say they shouldn't ask for support. See above.

If the author of this DStar alternative decided that he wanted to license his code for a dollar, you can bet there'd be those out there complaining about his "proprietary" software because it's not free!

KK5WA
07-26-2010, 07:50 PM
And yet the developer is asking for money to continue development.

Very amusing because even as an advocate of "free" software, he requires money. That's why I always laugh at these things. Some people think that despite all of the work that goes into software development, the result should be free. :)
Open Source has two "free" categories:

Free as in speech - code is open and accessible to all
Free as in beer - product don't cost nuthin.

A lot of people (including figureheads in the IT/software development industry) automatically assume that open source only means free as in beer.

There's nothing wrong in asking for a little financial help for an open source project.

AD7N
07-26-2010, 10:15 PM
Another update from Codec2 mailing list (https://lists.sourceforge.net/lists/listinfo/freetel-codec2):


I spent yesterday listening to a bunch of closely spaced samples. For example the codec after phase modelling, LPC modelling, LSP quantisation
etc. Drives me slightly mad as it's all very subjective.

Anyway I think the current codec2 quality is in roughly in the range of
g729/Speex 8k/gsm 13k. I listen mainly through small loudspeakers on my
laptop, as I figure that's the most likely output transducer for Ham
use.

I have attached some samples for the 5 speakers I am testing against.
To compare with other codecs I have written some scripts that will run
on most Linux PCs:

$ svn co https://freetel.svn.sourceforge.net/svnroot/freetel/codec2
codec2
[save the attached samples to codec2/src]
cd codec2/src
$ ./listen.sh hts1a
$ ./listen.sh hts2a
etc...

Please tell me what you think of the speech quality. Is it good enough?

The artifact I like the least is a "clicky" sound to the low pitch males
hts1a and mmt1. But codec2 lacks the "roughness" of CELP codecs.

The frame rate of these samples is 10ms. LSPs (36 bits) and voicing (1
bit) are quantised but I haven't quantised frame energy (5 bits) and Wo
(7 bits), although these are straight forward. So it's about 36+1+5
+7=49 bit/s frame or 4900 bit/s with a 10ms frame rate.

Over the next few days I want to mess around with 20ms frame rates with
a view to dropping the bit rate closer to 2400 bit/s.

A simple command line VOIP client would be really useful to do some
conversational tests. A great way to compare would be to have an option
to switch codecs from codec2/speex/GSM in real time during the call,
like g-gsm, s-speex, c-codec2.

Does anyone have an off-line MELP implementation that they can run
source files though? I have processed samples of morig.raw and
forig.raw of AMBE at 2400 bit/s

Cheers,

David

AD7N
07-26-2010, 10:24 PM
My point was directed at those who believe that all software should be open and free, and there are a lot of them out there. My point was that it costs time and resources (money) to develop software, and if those so engaged don't want to give it away or make it public, that is a decision that should be respected, not criticized.

agreed....

AD7N
07-26-2010, 10:26 PM
For a taste of the current state of the project, here's the current Todo list, as found here: https://freetel.svn.sourceforge.net/svnroot/freetel/codec2/TODO.txt


TODO for codec2
---------------

[ ] Important Open Issues
[X] Why zero phase model doesn't work for mmt1
+ error in LPC window and accidental random phase component and
effect of background noise on interformant harmonics
[X] residual noise on zero phase model
+ "navy" on hts1a, "frog" on morig
+ perhaps due to mis-alignment of phases at frame boundaries?
+ or possibly pitch errors
+ need a way to research this
[X] Pitch errors on mmt1, morig
+ we may need a tracker
+ suggest manually step through each file, check for
pitch errors, design tracker and check again
+ or develop manual pitch tracks and check estimator
with tracker against these.
[X] removal of LPC modelling errors for males
+ first few haromic energies (e.g. mmt1, hts1a) get raised
+ added a single bit to compensate for these errors, works OK
[X] good quality LSP quantisation of {Am}
+ first pass at this, lots of futher work ideas below...
[ ] conversion to 20ms frames
+ without significant distortion

[ ] Planned tasks and half formed ideas for codec2.....
[X] Convert files from DOS to Unix
[X] Get sinenc and sinedec to build and run under gcc
[ ] refactor
[ ] each source file has it's own header
[ ] no globals
[ ] Consistent file headers
[X] GPL2 notice in each file
[ ] Replace Numerical Recipes in C (NRC) four1.c and four1.h with Gnu
Science Lib (GSL) SL FFT as NRC code has restrictive licencing
[X] A way to handle m=1 harmonic for males when LPC modelling
+ used a single bit to correct LPC modelling errors
[ ] Is BW expansion and Rk noise floor required before LSP quant?
+ initial tests lead to large LPC modelling errors
[ ] Go through papers referenced in thesis and credit various
techniques to papers.
+ sure there was something about zero phase synthesis is those papers
[ ] voicing errors can be clearly seen in synthesised speech using pl2.m
[ ] Voicing improvement idea
+ voicing tracker, if enery about the same in frame n-1,n,n+1, and n-1, n+1
are voiced then make frame n voiced.

[ ] mmt1 with zero phase model
+ male with lots of background noise
+ zero order synth model sounds more "clicky" on mmt1, this suggests less
dispersion
+ could be due to IRS filtering or background noise
+ exploring this could lead to better understanding on phase, e.g. add
noise to clean samples and explore effect on zero phase model
+ wrote plphase.m to start analysing this

[ ] LSP quantisation further work
+ need codebook search to match perceptual error
+ for example error in close LSPs has a large perceptual effect
+ PDF-optimised quantisation may not be ideal, check this assumption
+ test split VQ to make sure no silly errors
+ for example test MSE or index histogram for training data
+ this gets tricky with split codebooks
+ VQ could also be trained with perceptual distortion modelled
+ perhaps work on weighting function
+ try differential in time as well, voiced speech doesn't chnage much
+ LPC envelope (mag spectrum) could possibly be quantised using some
other form of VQ, use LPC just to get a constant sampling rate. This
is a bit blue sky

[ ] Blue Sky {Am} Spectral Envelope quantisation ideas #1
+ what is really important is location of formants
+ therefore how about we just locate peak of each format
and encode position and height, then interpolate between them
+ could perhaps locate anti-formants as half way and just encode
depth
+ interesting factoid: a gentle HP of LP (3-6dB/oct) wont affect
subjective quality much, but would have a big impact on
quantisation error measures. Maybe remove/normalise out
before before quantisation? Could try quantisation
with/without HP filter.
+ envelope could be time domain LPC or some other interpolation
technique (see #2 below)

[ ] Blue Sky {Am} Spectral Envelop quantisation ideas #2
+ encode spectral envelope directly
+ problem is variable number of harmonics L
+ use a pitch sync DFT, ie DFT of one pitch cycle to get continuous
envelope without harmonic pitch structure
+ then over sample this DFT to up/down sample to an appropriate rate
+ we effectively already have pitch-sync DFT in {Am}
+ they could be interpolated at a non-uniform rate, like a bark scale
+ can we somehow seperately encode shape and height?

ad: WarrenG-1