On Fri, Oct 15, 2010 at 9:35 AM, Danny Nicholas <span dir="ltr"><<a href="mailto:danny@debsinc.com">danny@debsinc.com</a>></span> wrote:<br><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Don't know if this will make "acceptable" GSM files, but should help with<br>
the WAV ones.<br></blockquote><div><br><br>Are you using GSM to talk to an ITSP (the idea of banking voice calls going across the internet makes me cringe)? If not, what are you using GSM for? GSM always sounds like garbage (and see below - it's not what you are hearing on your mobile phone! It's not as good as mobile phone codecs). If you are using GSM to save bandwidth, you should really look at a better codec - but I would think a banking system wouldn't use the internet for the voice channel. If you are using a private network and bandwidth is still a concern, I'd look at any of the other codecs (except maybe ilbc, which is even worse than GSM). Any of them would sound better.<br>
<br>Somehow, to get to a mobile handset user (who uses GSM), the call will hit the PTSN. The PTSN, as others mentioned, is 8K alaw or ulaw (depending on your country). Get the recordings to sound good on the PTSN (convert to alaw or ulaw 8K, as that's what will happen NO MATTER WHAT when your call hits the PTSN) - don't even try to optimize anything else until then.<br>
<br>If you're hitting the PTSN at all (versus a direct connection within an IP-based GSM provider's network - unlikely that you have this), even though the handset user is on GSM, you do NOT want to use GSM as your encoding. Use 8K alaw/ulaw ("wav" format). I suspect your GSM providers in your area have spent literally millions of dollars on their GSM encoding systems - let them do the work. They'll have to do it even if you played the GSM file, it'll just sound worse if you play GSM, convert it to 8K alaw/ulaw over the PTSN, then have it converted using a different algorithm at the cell site.<br>
<br>Finally, not all mobile calls on even GSM networks are "gsm" format. If they are a different format, converting from one compressed algorithm (gsm) to another (whatever the carrier uses) is going to sound horrible.<br>
<br>So don't bother with the GSM format. Few people you are calling/called-by use that codec (not even the mobile phone users). It'll get resampled into something else. You'd be better off using the raw, basically-uncompressed (I know, I know, not quite accurate) alaw/ulaw - which everyone's codecs are designed to handle very well (since every single PTSN call uses it).<br>
<br>For reference, Asterisk uses (I believe) the "full rate" GSM codec. Mobile phones on most GSM networks are using an AMR (not "full rate") codec, as it simply sounds better, can deal with bad connections better, and can even use less bandwidth. Of course it is licensed and patented, so Asterisk doesn't implement it. But because of this, Asterisk's "gsm" doesn't sound as good as a call on a GSM network. Why would you want that? Just don't use it!<br>
<br>See <a href="http://en.wikipedia.org/wiki/Adaptive_Multi-Rate">http://en.wikipedia.org/wiki/Adaptive_Multi-Rate</a> (What mobile companies use)<br><br>And <a href="http://en.wikipedia.org/wiki/Full_Rate">http://en.wikipedia.org/wiki/Full_Rate</a> (What Asterisk uses)<br>
<br></div></div>