[digitalradio] DRCC numbers updated for PSK63 contest
I have updated the database of Digital Radio Century Club ahead of the European PSK Club PSK63 QSO party. The database is at http://groups.yahoo.com/group/digitalradio/database I updated it to include all recent new members of this group, at least those that had a callsign in their subscription information. If you are a member and do not see yourself in the database, email me and specify your callsign. To participate in the DRCC post-QSO party contest (see previous posts), your callsign must be listed in the DRCC database prior to UTC 18/11/07 -- Andy K3UK on-line log book www.obriensweb.com (QSL via N2RJ)
[digitalradio] Re: digital voice within 100 Hz bandwidth
In my opinion time delay is not even necessary, it is a matter of choosing the right compression at the right level. If I had time I would start the following project: * choose an existing speech-to-text converter (open source) * use cbh compression on the text, as normally no more than 250 different words are used anyway, so you can code 1 word in 1 character... * use pskmail to transmit the compressed text with PSK125 arq. * choose an existing open source text-to-speech converter (festival?) You would save some 5 man-years of development with that approach. 73, Rein PA0R --- In digitalradio@yahoogroups.com, Leigh L Klotz, Jr. [EMAIL PROTECTED] wrote: One thing to try might be an encoding that takes more time to send than the audio it encodes. If blank space compression is used, the effect can be reduced. But there is nothing that says the encoding must be able to transmit voice in 100% of real time to be interesting or useful. 73, Leigh/WA5ZNU
Re: [digitalradio] NIC issue
Jose A. Amador wrote: Most likely the module for the old NIC is no longer adequate for the new NIC. Look for the proper module and install it. Hi Jose, I know that the module for the old NIC (module ne) is no longer adequate, but also realized that Mdk 9.1 did not offer a module for 3c905 100BaseTX [Boomerang]. I tried to activate other 3c modules and eventually the one called 3c59x made it working. The other thing was to change a value within the computer's BIOS from 'Legacy ISA' to 'PCI/ISA PnP' because the new card is PCI and is not likely to work with settings for ISA cards. Thanks for suggestion, Misko YT7MPB Jose, CO2JA Miroslav Skoric (YT7MPB) wrote: Recently I changed the network card to one based on 3c905-tx chip. It makes me wonder how to make it working with Linux Mandrake 9.1 ? It is a PCI card (before it I used an ISA card that worked fine, but I moved it to another comp). Misko YT7MPB
[digitalradio] Re: A challenge to RTTY operators!
Robert, Thanks for pointing this out. The link is for 1999. Regarding WF1F/RITTY. The 1998 manual I have for WF1B (a DOS program) shows support for RITTY as a DOS TSR. Earlier manuals don't show it. I recall trying to get a sound card going in DOS. It was a real bear-- at least for the Soundblaster card I had. TSR's were flaky too. WF1B later became unusable as CPU speeds approached 1GHZ. It simply quit. Timing loop indicies became too large integers for their type in the code. Attempts to use CPU slow down programs to contiue to use WF1B were not too successful. The author had quit supporting WF1B at that time. The PASCAL source was available but nobody picked it up to fix this. RIP WF1B. All this history sort of indicates the 1999 to be the start of useful software/sound card RTTY for contesting or other use. 73 de Brian/K3KO --- In digitalradio@yahoogroups.com, Robert Chudek [EMAIL PROTECTED] wrote: Brian, A minor correction to the statement WF1B supported quite a few TU types but no sound cards. RTTY by WF1B supported the RITTY program by Brian, K6STI. http://www.eham.net/reviews/detail/235 73 de Bob - KØRC in MN - Original Message - From: Brian A To: digitalradio@yahoogroups.com Sent: Friday, November 16, 2007 2:45 PM Subject: [digitalradio] Re: A challenge to RTTY operators! Rick, I used a CP-1 TU up to the day the WF1B RTTY contest program became unsupported. WF1B supported quite a few TU types but no sound cards. That was around 1996 or 7. Here's a tidbit of info. Score required to win 1997 USA CQ WW RTTY single op assisted in 1997 = 553k points. I still have the plaque for it. It was done with a CP-1 and WF1B software. This was TU, not sound card era for RTTY. I don't believe MTTY and was created until several years later. MTTY by itself was pretty much useless as a contesting program. It couldn't even export its logs. It only supported a few rigs. It wasn't until codes like Writelog and N1MMLOGGER integrated MTTY and such engines in contesting programs that contesting became practical. K6STI RTTY was in there too about the same time with perhaps the best decoder available and a contesting interface. Piracy issues essentially killed the K6STI program. The author stopped supporting it. The last few years about 1.5 million points is required to win the same award. I ammend my statement. It wasn't just sound card RTTY but sound card RTTY plus having it integrated into contesting programs that released the contesting flood of RTTY stations. P.S. despite the sound card revolution, I stick with my HAL DXP38 DSP TU. Sound card apps seem to have a nasty habit of refusing to work for unknown reasons. One day they work, the next they don't. One has to be a computer Geek to bring them back to life. This isn't just my experience. 73 de Brian/K3KO --- In digitalradio@yahoogroups.com, Rick mrfarm@ wrote: I have to concur with Jose on this. I was a very active HF and VHF digital ham starting around 1981 with a homebrew XR2206/XR2211 TU that was from QST magazine and called The State of the Art TU. It most assuredly was not, but being naive and new to RTTY found it to be a very poor performer. It was actually only detecting one of the tones with the tone decoder! This was before computers became popular and I was interfacing with a Model 15 TTY and a homebrew loop circuit. I was able to borrow an huge tube ST-6 design TU and that was much better. Then computers started to be available at more affordable prices and I moved to the Commodore 64 and a ROM based software package. Later I had the Kantronics UTU, and eventually an AEA CP-1 using the BMKMulty DOS software. This was before it could do Pactor, but the program already cost $100 for basic RTTY/AMTOR and then you had to buy the CP-1 or some kind of interface to key the rig. BMKMulty eventually had a Pactor upgrade for I think another $100, but I have heard it was not that good. In fact, none of the third party hardware for Pactor was as good as the SCS modems, probably because they did not duplicate the memory ARQ. 73, Rick, KV9U Jose A. Amador wrote: Allow me to disagree (slightly) on the beginnings of RTTY popularity. I would blame Baycom, and the old Mix DOS versions. I used them (as well as quite few hams I know) way before PSK31 and the sound card modes appeared. Actually, after using them, I built a hardware modem that improved a LOT their performance, using both as terminals. I would say that PSK31 started the popularity of sound card modes. This is what I remember. Maybe others may have a different perspective. 73, Jose, CO2JA
[digitalradio] Re: digital voice within 100 Hz bandwidth
Hi Mike. I studied some aspects of voice recognition about 10 years ago when I thought of joining a research group at Czech Technical University in Prague. I have a 260 pages text book on my book shelf on voice recognition. Voice signal has high redundancy if compared to a text transcription. But there is additional information stored in the voice signal like pitch, intonation, speed. One could estimate for example mood of the speaker from the utterance. Voice tract could be described by a generator (tone for vowels, hiss for consonants) and filter. Translating voice into generator and filter coefficients greatly decreases voice data redundancy. This is roughly the technique that the common voice codecs do. GSM voice compression is a kind of Algebraic Code Excited Linear Prediction. Another interesting codec is AMBE (Advanced Multi-Band Excitation) used by DSTAR system. GSM half-rate codec squeezes voice to 5.6kbit/sec, AMBE to 3.6 kbps. Both systems use excitation tables, but AMBE is more efficient and closed source. I think the clue to the efficiency is in size and quality of the excitation tables. To create such an algorithm requires considerable amount of research and data analysis. The intelligibility of GSM or AMBE codecs is very good. You could buy the intelectual property of the AMBE codec by buying the chip. There are couple of projects running trying to built DSTAR into legacy transceivers. About 10 years ago we at OK1KPI club experimented with an echolink like system. We modified speakfreely software to control FM transceiver and we added web interface to control tuning and subtone of the transceiver. It was a lot of fun and a very unique system at that time. http://www.speakfreely.org/ The best compression factor offers LPC-10 codec (3460kbps), but the sound is very robot-like and quite hard to understand. At the end we reverted to GSM. I think IVOX is a variant of the LPC system that we tried. Your proposal is to increase compression rate by transmitting phonemes. I once had the same idea, but I quickly rejected it. Although it may be a nice exercise, I find it not very useless until good continuous speech multi-speaker multi-language recognition systems are available. I will try to explain my reasoning behind that statement. Let's classify voice recognition systems by the implementation complexity: 1) Single-speaker, limited set of utterances recognized (control your desktop by voice) 2) Multiple-speaker, limited set of utterances recognized (automated phone system) 3) dictating system 4) continuous speech transcription 5) speech recognition and understanding Your proposal will need implement most of the code from 4) or 5) to be really usable and it has to be reliable. State of the art voice recognition systems use hidden Markov models to detect phonemes. Phoneme is searched by traversing state diagram by evaluating multiple recorded spectra. The phoneme is soft-decoded. Output of the classifier is a list of phonemes with their probabilities of detection assigned. To cope with phoneme smearing on their boundaries, either sub-phonemes or phoneme pairs need to be detected. After the phonemes are classified, they are chained into words. Depending on the dictionary, most probable words are picked. You suppose that your system will not need it. But the trouble are consonants. They carry much less energy than vowels and are much easier to be confused. Dictionary is used to pick some second highest probability detected consonants in the word. Not only the dictionary, but also the phoneme classifier is language dependent. I think human brain works in the same way. Imagine learning foreign language. Even if you are able to recognize slowly pronounced words, you will be unable to pick them in a fast pronounced sentence. The word will sound different. Human needs considerable training to understand a language. You could decrease complexity of the decoder by constraining the detection to slowly dictated separate words. If you simply pick the high probability phoneme, you will experience comprehension problems of people with hearing loss. Oh yes, I am currently working for hearing instrument manufacturer (I have nothing to do with merck.com). from http://www.merck.com/mmhe/sec19/ch218/ch218a.html Loss of the ability to hear high-pitched sounds often makes it more difficult to understand speech. Although the loudness of speech appears normal to the person, certain consonant sounds—such as the sound of letters C, D, K, P, S, and T—become hard to distinguish, so that many people with hearing loss think the speaker is mumbling. Words can be misinterpreted. For example, a person may hear “bone” when the speaker said “stone.” For me, it would be very irritating to dictate slowly to a system knowing it will add some mumbling and not even having feedback about the errors the recognizer does. From my perspective, before good voice
[digitalradio] overnight 40M PSK31 report for 17/11/07.
Here is the overnight 40M PSK31 report for 17/11/07. Stations heard in Western New York State, antenna= Inverted V at 40 feet. Stations Heard list and signal strength calculations were generated by Winwarbler while I slept! Callsign DXCCCountryFreq Signal Strength AA4RPUnited States7,070.6 50 CO6DECuba 7,071.9 63 KG4TTQ United States 7,071.5 54 KD5HOP/QRP United States 7,071.2 69 NT3W United States 7,070.8 48 XE1/W7KOW Mexico 7,071.0 62 W9KAO United States 7,072.0 66 AA6YQ United States 7,072.1 65 LU7ER Argentina 7,072.1 45 KD8BIN United States 7,071.8 66 N8ZSG United States 7,071.6 60 W0NBP United States 7,071.3 64 LU7EH Argentina 7,072.1 52 KB5UNX United States 7,072.1 52 K1JOS United States7,071.3 54 K4WFM United States 7,071.6 66 EA5UB Spain7,071.1 31 WP3UX Puerto Rico 7,036.6 67 IK8GJS Italy 7,037.0 40 W5VZM United States 7,036.4 57 WT6X United States7,035.8 53 KG4ULT/KP4 Puerto Rico 7,036.8 50 WA6HZV United States 7,036.5 56 KC0VGC United States 7,036.8 53 PY7XC Brazil7,036.6 60 AG4QX United States 7,036.4 62 AE5BP United States7,036.3 52 WA6HZV United States 7,036.8 58 KG6MZS United States 7,036.0 54 AM5BZR Spain 7,036.1 41 CT1AYO Portugal 7,036.1 51 K6BR United States 7,036.6 63 CO3CJ Cuba 7,036.0 60 VE1SKY Canada 7,035.9 72 KF4HOU United States 7,036.5 65 N5UNB United States7,037.5 48 VE3ROY Canada 7,036.5 53 K1NOX United States7,036.0 59 KA1UJQ United States 7,035.6 70 -- Andy K3UK on-line log at www.obriensweb.com (QSL via N2RJ)
Re: [digitalradio] Re: A challenge to RTTY operators!
Brian, You're welcome. Yeah, back then the PC and soundcard technology was in its infancy compared to the technology we use today. I was aware of the RTTY-RITTY capability because Brian had sent me code to test before he released RITTY for sale. Ray and Brian were working together to make sure the softwares would play nicely with each other. And you're spot on about the piracy issue which drove Brian out of the amateur radio software business. That was a huge loss for the ham radio industry in my opinion. There were some big talkers that were going to step up to the plate and continue the development of the RTTY by WF1B product after Ray released it into the public domain. As we all know now, a new developer never developed. It takes a very special person (or team) to create and support a software product with ham radio as the target audience. My hat's off to those who have brought many low cost or freeware products into our hobby over the years. 73 de Bob - KØRC in MN - Original Message - From: Brian A To: digitalradio@yahoogroups.com Sent: Saturday, November 17, 2007 6:24 AM Subject: [digitalradio] Re: A challenge to RTTY operators! Robert, Thanks for pointing this out. The link is for 1999. Regarding WF1F/RITTY. The 1998 manual I have for WF1B (a DOS program) shows support for RITTY as a DOS TSR. Earlier manuals don't show it. I recall trying to get a sound card going in DOS. It was a real bear-- at least for the Soundblaster card I had. TSR's were flaky too. WF1B later became unusable as CPU speeds approached 1GHZ. It simply quit. Timing loop indicies became too large integers for their type in the code. Attempts to use CPU slow down programs to contiue to use WF1B were not too successful. The author had quit supporting WF1B at that time. The PASCAL source was available but nobody picked it up to fix this. RIP WF1B. All this history sort of indicates the 1999 to be the start of useful software/sound card RTTY for contesting or other use. 73 de Brian/K3KO --- In digitalradio@yahoogroups.com, Robert Chudek [EMAIL PROTECTED] wrote: Brian, A minor correction to the statement WF1B supported quite a few TU types but no sound cards. RTTY by WF1B supported the RITTY program by Brian, K6STI. http://www.eham.net/reviews/detail/235 73 de Bob - KØRC in MN - Original Message - From: Brian A To: digitalradio@yahoogroups.com Sent: Friday, November 16, 2007 2:45 PM Subject: [digitalradio] Re: A challenge to RTTY operators! Rick, I used a CP-1 TU up to the day the WF1B RTTY contest program became unsupported. WF1B supported quite a few TU types but no sound cards. That was around 1996 or 7. Here's a tidbit of info. Score required to win 1997 USA CQ WW RTTY single op assisted in 1997 = 553k points. I still have the plaque for it. It was done with a CP-1 and WF1B software. This was TU, not sound card era for RTTY. I don't believe MTTY and was created until several years later. MTTY by itself was pretty much useless as a contesting program. It couldn't even export its logs. It only supported a few rigs. It wasn't until codes like Writelog and N1MMLOGGER integrated MTTY and such engines in contesting programs that contesting became practical. K6STI RTTY was in there too about the same time with perhaps the best decoder available and a contesting interface. Piracy issues essentially killed the K6STI program. The author stopped supporting it. The last few years about 1.5 million points is required to win the same award. I ammend my statement. It wasn't just sound card RTTY but sound card RTTY plus having it integrated into contesting programs that released the contesting flood of RTTY stations. P.S. despite the sound card revolution, I stick with my HAL DXP38 DSP TU. Sound card apps seem to have a nasty habit of refusing to work for unknown reasons. One day they work, the next they don't. One has to be a computer Geek to bring them back to life. This isn't just my experience. 73 de Brian/K3KO --- In digitalradio@yahoogroups.com, Rick mrfarm@ wrote: I have to concur with Jose on this. I was a very active HF and VHF digital ham starting around 1981 with a homebrew XR2206/XR2211 TU that was from QST magazine and called The State of the Art TU. It most assuredly was not, but being naive and new to RTTY found it to be a very poor performer. It was actually only detecting one of the tones with the tone decoder! This was before computers became popular and I was interfacing with a Model 15 TTY and a homebrew loop circuit. I was able to borrow an huge tube ST-6 design TU and that was much better. Then computers started to be available at more affordable prices and I moved to the
[digitalradio] ALE400
Hi All; Yesterday used ALE400 in a long QSO with EA3AFR, Txema, on 14094.5 . Conditions were not the best, yet We were able to chat for about 30 minutes despite some QRM/QSB. The software was very impressive, Working well even down to my noise floor. Under poor conditions it is important to avoid collisions by typing and ending with an over sign, be it BT,K or -.- , and this avoids getting out of sync. Under strong signal conditions it doesn't seem to matter much who is typing, since it all comes through. Patrick you have a real winner with this software and am looking forward to playing more. I am currently on 14094.5 , 1625 centre, if anyone wants to try a connect... I won't be around but feel free to play. John VE5MU DO70QK
Re: [digitalradio] ALE400
Hello John, TKS for the report of this long QSO. Under poor conditions it is important to avoid collisions by typing and ending with an over sign, be it BT,K or In the last test version, I have integered a Sholto Fisher idea to limit collisions, which is the following: If A receives a frame from B there is a big probability that A receives a new frame from B. Previously, if A had something to send, A directly sent his frame if the channel was free. With a big probability there was a collision between the A frame and the B frame. Now, if A has to send something, in this configuration, there will be an enforced small delay before A transmission, so as to be able to detect a frame from B. So A will detect the B frame and will send his message with the acknowledgment of the B frame and there will be no collision. So I think this problem is partially solved, partially because it is impossible to avoid collisions. But collisions are managed by the protocol and there is no problem. However, if the channel is very noisy (let's say under -10 dB) it could be possibly difficult to recover the normal exchange. The softs (of A and B) have one minute to recover the link, afterwards there is an automatic disconnection. I think this delay (one minute) is superior to the duration of a simple QSB, during which the signal can be lost. 73 Patrick - Original Message - From: John Bradley To: digitalradio@yahoogroups.com ; [EMAIL PROTECTED] Sent: Saturday, November 17, 2007 6:23 PM Subject: [digitalradio] ALE400 Hi All; Yesterday used ALE400 in a long QSO with EA3AFR, Txema, on 14094.5 . Conditions were not the best, yet We were able to chat for about 30 minutes despite some QRM/QSB. The software was very impressive, Working well even down to my noise floor. Under poor conditions it is important to avoid collisions by typing and ending with an over sign, be it BT,K or -.- , and this avoids getting out of sync. Under strong signal conditions it doesn't seem to matter much who is typing, since it all comes through. Patrick you have a real winner with this software and am looking forward to playing more. I am currently on 14094.5 , 1625 centre, if anyone wants to try a connect... I won't be around but feel free to play. John VE5MU DO70QK
[digitalradio] DM780 and MFSK16
When using Simon's DM780 for MFSK16, I get a lot of question marks ? in the received text display. If I quickly switch to MultiPSK I don't get the question marks. It's kind of a pain. I assume the question mark is displayed because some unknown character has been received. Is there any way of turning this function off? Thanks--- Bob Christenson (WU9Q) Rock Island, IL
Re: [digitalradio] DM780 and MFSK16
Not at the moment... Simon Brown, HB9DRV - Original Message - From: Bob Christenson [EMAIL PROTECTED] When using Simon's DM780 for MFSK16, I get a lot of question marks ? in the received text display. If I quickly switch to MultiPSK I don't get the question marks. It's kind of a pain. I assume the question mark is displayed because some unknown character has been received. Is there any way of turning this function off?
[digitalradio] Re: digital voice within 100 Hz bandwidth
Leigh, I hope to have the project used throughout the world in less then a year, once I get started. My problem is that I need someone to help me start. If I don't find someone, the project will die with my two papers. 73's Mike n6ief --- In digitalradio@yahoogroups.com, pa0r [EMAIL PROTECTED] wrote: In my opinion time delay is not even necessary, it is a matter of choosing the right compression at the right level. If I had time I would start the following project: * choose an existing speech-to-text converter (open source) * use cbh compression on the text, as normally no more than 250 different words are used anyway, so you can code 1 word in 1 character... * use pskmail to transmit the compressed text with PSK125 arq. * choose an existing open source text-to-speech converter (festival?) You would save some 5 man-years of development with that approach. 73, Rein PA0R --- In digitalradio@yahoogroups.com, Leigh L Klotz, Jr. leigh@ wrote: One thing to try might be an encoding that takes more time to send than the audio it encodes. If blank space compression is used, the effect can be reduced. But there is nothing that says the encoding must be able to transmit voice in 100% of real time to be interesting or useful. 73, Leigh/WA5ZNU
Re: [digitalradio] DM780 and MFSK16
KB: 5100 and counting.. Mike Bob Christenson wrote: When using Simon's DM780 for MFSK16, I get a lot of question marks ? in the received text display. If I quickly switch to MultiPSK I don't get the question marks. It's kind of a pain. I assume the question mark is displayed because some unknown character has been received. Is there any way of turning this function off? Thanks--- Bob Christenson (WU9Q) Rock Island, IL Announce your digital presence via our Interactive Sked Page at http://www.obriensweb.com/drsked/drsked.php Yahoo! Groups Links
[digitalradio] RTTY contester's survey
Look at: http://rttycontesting.com/2007survey/2007octsurveyresults.html It reflects the comments of over 500 RTTY contesters. One major conclusion: More RTTY contests wanted. This is despite the fact that there are at least 32 now. So if you think RTTY contests are going to disappear, think again. So to paraphrase K3UK: Digital ops: Why not try RTTY? 73 de Brian/K3KO
Re: [digitalradio] RTTY contester's survey
Brian A wrote: Look at: http://rttycontesting.com/2007survey/2007octsurveyresults.html http://rttycontesting.com/2007survey/2007octsurveyresults.html It reflects the comments of over 500 RTTY contesters. One major conclusion: More RTTY contests wanted. This is despite the fact that there are at least 32 now. So if you think RTTY contests are going to disappear, think again. I don't think anyone thought that RTTY contests were going away. I do think that a) a lot of the RTTY contesters pretty much don't do much ham radio except contesting; and b) we need to learn to co-exist with contests such that a contest does not mean a suspension of the ordinary band plans, i.e. RTTY in the RTTY portion of the band, not on top of everyone else. Sure, some of these chaps probably would like there to be RTTY contests 52 weeks a year. I guess that is about what you are saying. de Roger W6VZV
[digitalradio] Re: RTTY contester's survey
Roger, What about shared resoures don't you understand? There isn't any RTTY portion of the band for US licensees other than what is contained in the regs. For example on 20M: 14.025-14.150 MHz: CW, RTTY/Data (for several classes of licenses.) There simply isn't enough room to fit 500 stations in the normal 14080-14090 area. So just like the 160M contests, the stations spread to other frequencies where they are allowed. The do this to not operate on top of everybody else. If they find 14070 clear, they have every right to operate RTTY there. Likewise other digital modes can and do move to the area between 14080-14090 and operate there. I think you do see RTTY stations, even in contests, not mobbing the frequencies normally used by PSK stations-- at least on 20M. 40M is a whole other story for many reasons. 73 de Brian/K3KO --- In digitalradio@yahoogroups.com, Roger J. Buffington [EMAIL PROTECTED] wrote: Brian A wrote: Look at: http://rttycontesting.com/2007survey/2007octsurveyresults.html http://rttycontesting.com/2007survey/2007octsurveyresults.html It reflects the comments of over 500 RTTY contesters. One major conclusion: More RTTY contests wanted. This is despite the fact that there are at least 32 now. So if you think RTTY contests are going to disappear, think again. I don't think anyone thought that RTTY contests were going away. I do think that a) a lot of the RTTY contesters pretty much don't do much ham radio except contesting; and b) we need to learn to co-exist with contests such that a contest does not mean a suspension of the ordinary band plans, i.e. RTTY in the RTTY portion of the band, not on top of everyone else. Sure, some of these chaps probably would like there to be RTTY contests 52 weeks a year. I guess that is about what you are saying. de Roger W6VZV
Re: [digitalradio] Re: RTTY contester's survey
Brian A wrote: Roger, What about shared resoures don't you understand? I don't particularly care for the tone of your post. Thanks for the lecture. Conversation ended. SK de Roger W6VZV
Re: [digitalradio] Re: RTTY contester's survey
On Nov 17, 2007 5:47 PM, Brian A [EMAIL PROTECTED] wrote: Roger, What about shared resoures don't you understand? The resoures part. Some sort of sour candy ? :) Andy.
RE: [digitalradio] Re: digital voice within 100 Hz bandwidth
I have a few radios (ARC-210-1851, PSC-5D, PRC-117F) at work that operate in MELP for a vocoder Mixed Excitation Linear Prediction. We have found MELP to be superior (more human-like voice qualities less Charlie Browns teacher) to LPC-10 but we use far larger bandwidths than 100 khz. I do not know how well any of this will play out at such a narrow bandwidth. Listening to Charlie Browns teacher will send you running away quickly and you should think of your listeners . . . they will tire very quickly. Just because voice can be sent at such narrower bandwidths does not necessarily mean that people will like to listen to it. Rick KH2DF _ From: digitalradio@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Vojtech Bubník Sent: Saturday, November 17, 2007 9:11 AM To: [EMAIL PROTECTED]; digitalradio@yahoogroups.com Subject: [digitalradio] Re: digital voice within 100 Hz bandwidth Hi Mike. I studied some aspects of voice recognition about 10 years ago when I thought of joining a research group at Czech Technical University in Prague. I have a 260 pages text book on my book shelf on voice recognition. Voice signal has high redundancy if compared to a text transcription. But there is additional information stored in the voice signal like pitch, intonation, speed. One could estimate for example mood of the speaker from the utterance. Voice tract could be described by a generator (tone for vowels, hiss for consonants) and filter. Translating voice into generator and filter coefficients greatly decreases voice data redundancy. This is roughly the technique that the common voice codecs do. GSM voice compression is a kind of Algebraic Code Excited Linear Prediction. Another interesting codec is AMBE (Advanced Multi-Band Excitation) used by DSTAR system. GSM half-rate codec squeezes voice to 5.6kbit/sec, AMBE to 3.6 kbps. Both systems use excitation tables, but AMBE is more efficient and closed source. I think the clue to the efficiency is in size and quality of the excitation tables. To create such an algorithm requires considerable amount of research and data analysis. The intelligibility of GSM or AMBE codecs is very good. You could buy the intelectual property of the AMBE codec by buying the chip. There are couple of projects running trying to built DSTAR into legacy transceivers. About 10 years ago we at OK1KPI club experimented with an echolink like system. We modified speakfreely software to control FM transceiver and we added web interface to control tuning and subtone of the transceiver. It was a lot of fun and a very unique system at that time. http://www.speakfre http://www.speakfreely.org/ ely.org/ The best compression factor offers LPC-10 codec (3460kbps), but the sound is very robot-like and quite hard to understand. At the end we reverted to GSM. I think IVOX is a variant of the LPC system that we tried. Your proposal is to increase compression rate by transmitting phonemes. I once had the same idea, but I quickly rejected it. Although it may be a nice exercise, I find it not very useless until good continuous speech multi-speaker multi-language recognition systems are available. I will try to explain my reasoning behind that statement. Let's classify voice recognition systems by the implementation complexity: 1) Single-speaker, limited set of utterances recognized (control your desktop by voice) 2) Multiple-speaker, limited set of utterances recognized (automated phone system) 3) dictating system 4) continuous speech transcription 5) speech recognition and understanding Your proposal will need implement most of the code from 4) or 5) to be really usable and it has to be reliable. State of the art voice recognition systems use hidden Markov models to detect phonemes. Phoneme is searched by traversing state diagram by evaluating multiple recorded spectra. The phoneme is soft-decoded. Output of the classifier is a list of phonemes with their probabilities of detection assigned. To cope with phoneme smearing on their boundaries, either sub-phonemes or phoneme pairs need to be detected. After the phonemes are classified, they are chained into words. Depending on the dictionary, most probable words are picked. You suppose that your system will not need it. But the trouble are consonants. They carry much less energy than vowels and are much easier to be confused. Dictionary is used to pick some second highest probability detected consonants in the word. Not only the dictionary, but also the phoneme classifier is language dependent. I think human brain works in the same way. Imagine learning foreign language. Even if you are able to recognize slowly pronounced words, you will be unable to pick them in a fast pronounced sentence. The word will sound different. Human needs considerable training to understand a language. You could decrease complexity of the decoder by constraining the detection to slowly dictated separate words. If you simply pick the high
[digitalradio] DRCC numbers
Hey, Andy - we have these great numbers now. How about we do something with them? Maybe something like a short-duration digital WAS contest? Maybe 6 to 12 hours, all bands (WARC excluded, of course) or something similar? Or even a DRCC DXCC digital contest? Even just a work all the DRCC numbers you can? Tnx es 73 Dave KB3MOW
