VOIP, Call Center, and DTMF errors...

[David Morgan \(MAMS\)]

Not very clear, I know... but I have a question that I'd love to have
addressed by anyone with experience in SRC for telephone call
center software using low-Khz voice files for automated prompting.



Issue:

Distortion within a compressed audio file triggers randon DTMF tone,
interrupting or altering end user's software application which interfaces
with incoming caller.



Background:

Recording system in vocal booth creates audio files of voice talent at
16 / 22,050Khz

Audio files are edited into single 'prompts' and batch processed with filtering
and the end result is an 8Khz file used by the software handling the calls.

Updates to the voice 'prompts' for the software package are sent to the
client via VOIP.

Audio files are used by software in automated call centers to route calls
and handle customer service, etc... (Press one for english)


Front end recording setup:

I have determined that there is a gain staging problem between at least
two devices in the path, but there are also equipment quality issues which
may or may not be related to the end result.

Bear in mind that this equipment has put this company (and it's unique
take on the software that uses these audio files) on the map to ten years
of multi-million dollar success.

Nice vocal booth... talent operates Cool-Edit on quiet PC (Hush) to self-
record voice. (These files are networked to another office for editing)

ATM-33 on desk boom
DBX 286A - Mic Pre / channel strip
E-MU 2 channel mic pre (used only as A/D convertor to PC via
proprietary wired CAT-5 cable)



One problem cured.... but is there anything else ???

The output of the DBX was overdriving the line input to the E-MU, and the
problem may be cured... but a multi-million dollar business is not going
to be happy if their incoming calls are dropped again when they bring the
software package back on line with the new voice prompts.

I want to see the E-MU replaced... it has faaar too much self noise.
I'd like to see them working with an RE-20 or something more than
the little AT.... but it's been making them happy for many years so
I don't know exactly how to recommend the change. The DBX may
be suffering from slow capacitor death, as many of the process
controls seem sluggish and possible randomly inaccurate.

I think that altering the gain stages to eliminate any more potential
distortion in the initial recordings may cure the issue, but what if
(and *could*) the problem actually be occurring later in the conversion
process to 8Khz? Are there any other possible causes of random
DTMF tone generation besides the light distortion in the originating
files which was creating some rather blatant crackling after the final
conversion to 8K?

I just don't want to overlook any potential problems and this isn't
something I address every day.

AM I wrong to think that some light distortion on the front end may
have been 100% the culprit? After all, the company has been doing
just fine on this gear (unattended) for many years.

TIA for any input...



--
David Morgan (MAMS)
http://www.m-a-m-s DOT com
Morgan Audio Media Service
Dallas, Texas (214) 662-9901
_______________________________________
http://www.artisan-recordingstudio.com

[Mark]

On Apr 10, 3:38 am, "David Morgan \(MAMS\)" /Odm>
wrote:
> Not very clear, I know... but I have a question that I'd love to have
> addressed by anyone with experience in SRC for telephone call
> center software using low-Khz voice files for automated prompting.
>
> Issue:
>
> Distortion within a compressed audio file triggers randon DTMF tone,
> interrupting or altering end user's software application which interfaces
> with incoming caller.
>
> Background:
>
> Recording system in vocal booth creates audio files of voice talent at
> 16 / 22,050Khz
>
> Audio files are edited into single 'prompts' and batch processed with filtering
> and the end result is an 8Khz file used by the software handling the calls.
>
> Updates to the voice 'prompts' for the software package are sent to the
> client via VOIP.
>
> Audio files are used by software in automated call centers to route calls
> and handle customer service, etc... (Press one for english)
>
> Front end recording setup:
>
> I have determined that there is a gain staging problem between at least
> two devices in the path, but there are also equipment quality issues which
> may or may not be related to the end result.
>
> Bear in mind that this equipment has put this company (and it's unique
> take on the software that uses these audio files) on the map to ten years
> of multi-million dollar success.
>
> Nice vocal booth... talent operates Cool-Edit on quiet PC (Hush) to self-
> record voice. (These files are networked to another office for editing)
>
> ATM-33 on desk boom
> DBX 286A - Mic Pre / channel strip
> E-MU 2 channel mic pre (used only as A/D convertor to PC via
> proprietary wired CAT-5 cable)
>
> One problem cured.... but is there anything else ???
>
> The output of the DBX was overdriving the line input to the E-MU, and the
> problem may be cured... but a multi-million dollar business is not going
> to be happy if their incoming calls are dropped again when they bring the
> software package back on line with the new voice prompts.
>
> I want to see the E-MU replaced... it has faaar too much self noise.
> I'd like to see them working with an RE-20 or something more than
> the little AT.... but it's been making them happy for many years so
> I don't know exactly how to recommend the change. The DBX may
> be suffering from slow capacitor death, as many of the process
> controls seem sluggish and possible randomly inaccurate.
>
> I think that altering the gain stages to eliminate any more potential
> distortion in the initial recordings may cure the issue, but what if
> (and *could*) the problem actually be occurring later in the conversion
> process to 8Khz? Are there any other possible causes of random
> DTMF tone generation besides the light distortion in the originating
> files which was creating some rather blatant crackling after the final
> conversion to 8K?
>
> I just don't want to overlook any potential problems and this isn't
> something I address every day.
>
> AM I wrong to think that some light distortion on the front end may
> have been 100% the culprit? After all, the company has been doing
> just fine on this gear (unattended) for many years.
>
> TIA for any input...
>
> --
> David Morgan (MAMS)http://www.m-a-m-sDOT com
> Morgan Audio Media Service
> Dallas, Texas (214) 662-9901
> _______________________________________http://www.artisan-recordingstudio.com

this issue goes by the term "talk off"

I suggest the problem is not your audio files at all but rather the
DTMF decoder or the hybrid that splits the outgoing and incomming
audio..

I also suggest you ask this question over at comp.dsp.

Mark

[David Morgan \(MAMS\)]

"David Morgan (MAMS)" /Odm> wrote in message news:C9HSh.1026$Z66.558@trnddc06...

Any other input here before I move to another forum on this one?

TIA

[David Morgan \(MAMS\)]

"Mark" > wrote in message oups.com...
> On Apr 10, 3:38 am, "David Morgan \(MAMS\)" /Odm>
> wrote:
> > Not very clear, I know... but I have a question that I'd love to have
> > addressed by anyone with experience in SRC for telephone call
> > center software using low-Khz voice files for automated prompting.
> >
> > Issue:
> >
> > Distortion within a compressed audio file triggers randon DTMF tone,
> > interrupting or altering end user's software application which interfaces
> > with incoming caller.
> >
> > Background:
> >
> > Recording system in vocal booth creates audio files of voice talent at
> > 16 / 22,050Khz
> >
> > Audio files are edited into single 'prompts' and batch processed with filtering
> > and the end result is an 8Khz file used by the software handling the calls.
> >
> > Updates to the voice 'prompts' for the software package are sent to the
> > client via VOIP.
> >
> > Audio files are used by software in automated call centers to route calls
> > and handle customer service, etc... (Press one for english)
> >
> > Front end recording setup:
> >
> > I have determined that there is a gain staging problem between at least
> > two devices in the path, but there are also equipment quality issues which
> > may or may not be related to the end result.
> >
> > Bear in mind that this equipment has put this company (and it's unique
> > take on the software that uses these audio files) on the map to ten years
> > of multi-million dollar success.
> >
> > Nice vocal booth... talent operates Cool-Edit on quiet PC (Hush) to self-
> > record voice. (These files are networked to another office for editing)
> >
> > ATM-33 on desk boom
> > DBX 286A - Mic Pre / channel strip
> > E-MU 2 channel mic pre (used only as A/D convertor to PC via
> > proprietary wired CAT-5 cable)
> >
> > One problem cured.... but is there anything else ???
> >
> > The output of the DBX was overdriving the line input to the E-MU, and the
> > problem may be cured... but a multi-million dollar business is not going
> > to be happy if their incoming calls are dropped again when they bring the
> > software package back on line with the new voice prompts.
> >
> > I want to see the E-MU replaced... it has faaar too much self noise.
> > I'd like to see them working with an RE-20 or something more than
> > the little AT.... but it's been making them happy for many years so
> > I don't know exactly how to recommend the change. The DBX may
> > be suffering from slow capacitor death, as many of the process
> > controls seem sluggish and possible randomly inaccurate.
> >
> > I think that altering the gain stages to eliminate any more potential
> > distortion in the initial recordings may cure the issue, but what if
> > (and *could*) the problem actually be occurring later in the conversion
> > process to 8Khz? Are there any other possible causes of random
> > DTMF tone generation besides the light distortion in the originating
> > files which was creating some rather blatant crackling after the final
> > conversion to 8K?
> >
> > I just don't want to overlook any potential problems and this isn't
> > something I address every day.
> >
> > AM I wrong to think that some light distortion on the front end may
> > have been 100% the culprit? After all, the company has been doing
> > just fine on this gear (unattended) for many years.
> >
> > TIA for any input...
> >
> > --
> > David Morgan (MAMS)
> > http://www.m-a-m-sDOTcom
> > Morgan Audio Media Service
> > Dallas, Texas (214) 662-9901
> > _______________________________________
> > http://www.artisan-recordingstudio.com


> this issue goes by the term "talk off"
>
> I suggest the problem is not your audio files at all but rather the
> DTMF decoder or the hybrid that splits the outgoing and incomming
> audio..
>
> I also suggest you ask this question over at comp.dsp.
>
> Mark


I haven't signed up to post on 'dsp' yet, but I've been reading. I don't
think this is a 'talk-off' issue. It seems that the call is being dropped
or moved forward during the outgoing prompt. My best guess is that
the distortion (which I have eliminated) was being interpreted as a VR
preparation spike and interrupting the system. This is not my forte', but
I'd love to gain enough knowledge on the workings of call-center software
and implementation in order to converse logically with my contractor.

Thanks again,

DM

[Mark]

>
> > It seems that the call is being dropped
> or moved forward during the outgoing prompt.


If the call center equipment is interpretting the outgoing audio voice
prompt as a touch tone, then that is "talk off". Lowering the
outgoing audio level a few dB can make a big difference.

comp.dsp is a newsgroup like this one, nothing to sign up for, just
post...

Mark

[[email protected]]

On Apr 11, 6:10 pm, "David Morgan \(MAMS\)" /Odm>
wrote:
> "David Morgan (MAMS)" /Odm> wrote in messagenews:C9HSh.1026$Z66.558@trnddc06...
>
> Any other input here before I move to another forum on this one?
>
> TIA

David,

Do you know exactly how the conversion from 22x16 to 8x16 is done,
what anti-aliasing filtering before sample rate decimation? Does the
client then employ a data compression codec such as G.723.1 or ADPCM
etc. for the final voice prompt format? It might be instructive to
model the client's process and then inspect spectrograms of the final
voice prompts. Listen and look for chirping that falls into the DTMF
frequencies. If the client could tell you which DTMFs are being
triggered and by which voice prompts the inspection could be focussed
rather quickly.

As an aside, voice prompts at 8 KHz become ugly rather quickly. A
lot of the consonant energy is diminished or lost completely. When
these prompts are heard by cell phone users the result is truly
hideous. Now think about hearing aid users.

bobs

Bob Smith
BS Studios
we organize chaos
http://www.bsstudios.com

[David Morgan \(MAMS\)]

> wrote in message oups.com...
> On Apr 11, 6:10 pm, "David Morgan \(MAMS\)" /Odm>
> wrote:
> > "David Morgan (MAMS)" /Odm> wrote in messagenews:C9HSh.1026$Z66.558@trnddc06...
> >
> > Any other input here before I move to another forum on this one?
> >
> > TIA
>
> David,
>
> Do you know exactly how the conversion from 22x16 to 8x16 is done,
> what anti-aliasing filtering before sample rate decimation?

The editor could not tell me what all was in the batch script that does the
final conversion to 8K. (I know... he's a button-pusher and not a tech).
Someone else write the scripts that have been in place for years.

One of my first recommendations was to bump the original recording
level up to 48Khz.... making the conversion even numbered math.

> Does the client then employ a data compression codec such as G.723.1
> or ADPCM etc. for the final voice prompt format?

I'll dig into that... I believe that I remember seeing .pcm on the 8K files
being shipped, but I'll ask about what goes on on the client side.

> It might be instructive to
> model the client's process and then inspect spectrograms of the final
> voice prompts. Listen and look for chirping that falls into the DTMF
> frequencies. If the client could tell you which DTMFs are being
> triggered and by which voice prompts the inspection could be focussed
> rather quickly.

Thanks a million for the tips.... too bad this is just a 'fix-it' and go gig, 'cause
I'm learning a great deal about this stuff.

> As an aside, voice prompts at 8 KHz become ugly rather quickly. A
> lot of the consonant energy is diminished or lost completely. When
> these prompts are heard by cell phone users the result is truly
> hideous. Now think about hearing aid users.

I said the same thing on day 2, but they easily proved to me that because
of the wretched harmonics created along the phone lines, that the 8K
speech is actually enhanced again by the faulty characteristics on the
phone lines. It sounds a lot better when listening over the phone than
it does when listening to the raw 8K filtered files in the lab.


--
David Morgan (MAMS)
http://www.m-a-m-s DOT com
Morgan Audio Media Service
Dallas, Texas (214) 662-9901
_______________________________________
http://www.artisan-recordingstudio.com


> bobs
>
> Bob Smith
> BS Studios
> we organize chaos
> http://www.bsstudios.com
>

[David Morgan \(MAMS\)]

"Mark" > wrote in message ps.com...
> >
> > > It seems that the call is being dropped
> > or moved forward during the outgoing prompt.

> If the call center equipment is interpretting the outgoing audio voice
> prompt as a touch tone, then that is "talk off".

OK... that does seem to be the problem with this client.

> Lowering the
> outgoing audio level a few dB can make a big difference.

Great tip. The primary editing phase does in fact fully normalize the
voice prompt at this time.

> comp.dsp is a newsgroup like this one, nothing to sign up for, just
> post...

OK... I just saw the log-in and password box and assumed sign-up
was required. I'll search my newsgroups and get off the web.

Cheers...

[[email protected]]

On Apr 12, 11:07 am, "David Morgan \(MAMS\)" /Odm>
wrote:
> > wrote in ooglegroups.com...

> > As an aside, voice prompts at 8 KHz become ugly rather quickly. A
> > lot of the consonant energy is diminished or lost completely. When
> > these prompts are heard by cell phone users the result is truly
> > hideous. Now think about hearing aid users.
>
> I said the same thing on day 2, but they easily proved to me that because
> of the wretched harmonics created along the phone lines, that the 8K
> speech is actually enhanced again by the faulty characteristics on the
> phone lines. It sounds a lot better when listening over the phone than
> it does when listening to the raw 8K filtered files in the lab.

That doesn't always work. They have a system (or two) for which they
can show it somewhat working but I can show you others where it
doesn't. Here is a good paper to look at:

http:www.polycom.com/common/pw_cmp_updateDocKeywords/
0,1687,1809,00.pdf

bobs

Bob Smith
BS Studios
we organize chaos

[David Morgan \(MAMS\)]

> wrote in message...

> That doesn't always work. They have a system (or two) for which they
> can show it somewhat working but I can show you others where it
> doesn't. Here is a good paper to look at:

> http:www.polycom.com/common/pw_cmp_updateDocKeywords/0,1687,1809,00.pdf


Cheers...

[[email protected]]

On 2007-04-12 /Odm said:
Dave, I hope you saw the email I sent to your verizon
address.
>> I suggest the problem is not your audio files at all but rather
>>the DTMF decoder or the hybrid that splits the outgoing and
>>incomming audio..
>> I also suggest you ask this question over at comp.dsp.
I would agree, as I told you in that email, I've seen dtmf
decoders key on certain voices before in repeater and radio
link applications.

I"d still have a start by listening to the phone lines that
the troublesome system is connected to with a spectrum
analyzer and an o-scope.

YOu might try doing some filtration of harmonic frequencies
of the dtmf tones produced. Any comm characteristics such
as row or column of tones produced? AFter all, you know
dtmf is made up of two tones, one generated from the row
(1-3 etcetera) and the other from the column, i.e. 1 4 7 *
etc.
FInd the common tone to those being errantly produced, and
filter that frequency and/or its harmonics when you record
the audio or downsample.

tHere's one certain fellow I used to talk to on a repeater
down in NEW ORleans all the time who would always trigger
repeater controller functions when in his car, but not on
his handheld radio or at home on his base rig.
I finally figured that if he turned the audio down a little
bit on his car rig and solved the alternator whine maybe
we'd get rid of the problem, and when he solved the
alternator problem it cured it.




Richard webb,
Electric Spider Productions
Replace anything before the @ symbol with elspider for real
email address.



Great audio is never heard by the average person, but bad
audio is heard by everyone.

[David Morgan \(MAMS\)]

> wrote in message ...
>
> On 2007-04-12 /Odm said:
> Dave, I hope you saw the email I sent to your verizon
> address.
> >> I suggest the problem is not your audio files at all but rather
> >>the DTMF decoder or the hybrid that splits the outgoing and
> >>incomming audio..
> >> I also suggest you ask this question over at comp.dsp.
> I would agree, as I told you in that email, I've seen dtmf
> decoders key on certain voices before in repeater and radio
> link applications.
>
> I"d still have a start by listening to the phone lines that
> the troublesome system is connected to with a spectrum
> analyzer and an o-scope.
>
> YOu might try doing some filtration of harmonic frequencies
> of the dtmf tones produced. Any comm characteristics such
> as row or column of tones produced? AFter all, you know
> dtmf is made up of two tones, one generated from the row
> (1-3 etcetera) and the other from the column, i.e. 1 4 7 *
> etc.
> FInd the common tone to those being errantly produced, and
> filter that frequency and/or its harmonics when you record
> the audio or downsample.
>
> tHere's one certain fellow I used to talk to on a repeater
> down in NEW ORleans all the time who would always trigger
> repeater controller functions when in his car, but not on
> his handheld radio or at home on his base rig.
> I finally figured that if he turned the audio down a little
> bit on his car rig and solved the alternator whine maybe
> we'd get rid of the problem, and when he solved the
> alternator problem it cured it.
>
>
>
>
> Richard webb,
> Electric Spider Productions


Cheers Rich.... thanks for the study points, defintely good clues.

[David Morgan \(MAMS\)]

"Mark" > wrote in message ps.com...
> >
> > > It seems that the call is being dropped
> > or moved forward during the outgoing prompt.
>
>
> If the call center equipment is interpretting the outgoing audio voice
> prompt as a touch tone, then that is "talk off". Lowering the
> outgoing audio level a few dB can make a big difference.
>
> comp.dsp is a newsgroup like this one, nothing to sign up for, just
> post...
>
> Mark


Four days and not one single response on comp.dsp

[Richard Crowley]

"David Morgan (MAMS)" wrote ...
> "Mark" wrote ...
>> >
>> > > It seems that the call is being dropped
>> > or moved forward during the outgoing prompt.
>>
>>
>> If the call center equipment is interpretting the outgoing audio
>> voice
>> prompt as a touch tone, then that is "talk off". Lowering the
>> outgoing audio level a few dB can make a big difference.
>>
>> comp.dsp is a newsgroup like this one, nothing to sign up for, just
>> post...
>>
>> Mark
>
>
> Four days and not one single response on comp.dsp

One equation, seventeen variables.

[David Morgan \(MAMS\)]

"Richard Crowley" > wrote in message ...
> "David Morgan (MAMS)" wrote ...
> > "Mark" wrote ...
> >> >
> >> > > It seems that the call is being dropped
> >> > or moved forward during the outgoing prompt.
> >>
> >>
> >> If the call center equipment is interpretting the outgoing audio
> >> voice
> >> prompt as a touch tone, then that is "talk off". Lowering the
> >> outgoing audio level a few dB can make a big difference.
> >>
> >> comp.dsp is a newsgroup like this one, nothing to sign up for, just
> >> post...
> >>
> >> Mark


> > Four days and not one single response on comp.dsp


> One equation, seventeen variables.


Uhh... care to elaborate, or am I missing the smiley-face?

DM

[Richard Crowley]

"David Morgan (MAMS)" wrote...
> "Richard Crowley" wrote ...
>> "David Morgan (MAMS)" wrote ...
>> > "Mark" wrote ...
>> >> >
>> >> > > It seems that the call is being dropped
>> >> > or moved forward during the outgoing prompt.
>> >>
>> >>
>> >> If the call center equipment is interpretting the outgoing audio
>> >> voice
>> >> prompt as a touch tone, then that is "talk off". Lowering the
>> >> outgoing audio level a few dB can make a big difference.
>> >>
>> >> comp.dsp is a newsgroup like this one, nothing to sign up for,
>> >> just
>> >> post...
>> >>
>> >> Mark
>
>
>> > Four days and not one single response on comp.dsp
>
>
>> One equation, seventeen variables.
>
>
> Uhh... care to elaborate, or am I missing the smiley-face?

It seemed like you had a great many different parameters
in the situation which made it a less likely candidate for a
problem that could be solved at long distance here on a
newsgroup.

[David Morgan \(MAMS\)]

"Richard Crowley" > wrote in message ...
> "David Morgan (MAMS)" wrote...
> > "Richard Crowley" wrote ...
> >> "David Morgan (MAMS)" wrote ...
> >> > "Mark" wrote ...
> >> >> >
> >> >> > > It seems that the call is being dropped
> >> >> > or moved forward during the outgoing prompt.
> >> >>
> >> >>
> >> >> If the call center equipment is interpretting the outgoing audio
> >> >> voice
> >> >> prompt as a touch tone, then that is "talk off". Lowering the
> >> >> outgoing audio level a few dB can make a big difference.
> >> >>
> >> >> comp.dsp is a newsgroup like this one, nothing to sign up for,
> >> >> just
> >> >> post...
> >> >>
> >> >> Mark
> >
> >
> >> > Four days and not one single response on comp.dsp
> >
> >
> >> One equation, seventeen variables.
> >
> >
> > Uhh... care to elaborate, or am I missing the smiley-face?

> It seemed like you had a great many different parameters
> in the situation which made it a less likely candidate for a
> problem that could be solved at long distance here on a
> newsgroup.

The basic parameters were the gear and recorded distortion.

I believe that I have solved the problem on the surface, at the
initial point of the recording of voice prompts.... but I'd like to
understand more about how the end user of this automated
response software implements it with the phone lines, in the
event there are more opportunities for such an anomaly to
creep in further down the path.

DM

[David Morgan \(MAMS\)]

"David Morgan (MAMS)" /Odm> wrote in message news:Q4fUh.3418$h8.2551@trnddc06...
>
> "Richard Crowley" > wrote in message ...
> > "David Morgan (MAMS)" wrote...
> > > "Richard Crowley" wrote ...
> > >> "David Morgan (MAMS)" wrote ...
> > >> > "Mark" wrote ...
> > >> >> >
> > >> >> > > It seems that the call is being dropped
> > >> >> > > or moved forward during the outgoing prompt.


> > >> >> If the call center equipment is interpretting the outgoing audio
> > >> >> voice'prompt as a touch tone, then that is "talk off". Lowering
> > >> >> the outgoing audio level a few dB can make a big difference.
> > >> >>
> > >> >> comp.dsp is a newsgroup like this one, nothing to sign up for,
> > >> >> just
> > >> >> post...
> > >> >>
> > >> >> Mark

> > >> > Four days and not one single response on comp.dsp

> > >> One equation, seventeen variables.

> > > Uhh... care to elaborate, or am I missing the smiley-face?

> > It seemed like you had a great many different parameters
> > in the situation which made it a less likely candidate for a
> > problem that could be solved at long distance here on a
> > newsgroup.

> The basic parameters were the gear and recorded distortion.
>
> I believe that I have solved the problem on the surface, at the
> initial point of the recording of voice prompts.... but I'd like to
> understand more about how the end user of this automated
> response software implements it with the phone lines, in the
> event there are more opportunities for such an anomaly to
> creep in further down the path.
>
> DM

[[email protected]]

On 2007-04-15 /Odm said:
>I believe that I have solved the problem on the surface, at the
>initial point of the recording of voice prompts.... but I'd like to
>understand more about how the end user of this automated
>response software implements it with the phone lines, in the
>event there are more opportunities for such an anomaly to
>creep in further down the path.
HOpe I steered you toward the solution. I've found dtmf
decoding to be a tricky business, mucho level dependent, and
harmonics and other noise can even make it a further
adventure. MOSt of my experience has been with interfacing
dtmf decoding with radio systems though.



Richard webb,
Electric Spider Productions
Replace anything before the @ symbol with elspider for real
email address.



Braille: support true literacy for the blind.

[David Morgan \(MAMS\)]

"Mark" > wrote in message ps.com...
> >
> > > It seems that the call is being dropped
> > or moved forward during the outgoing prompt.
>
>
> If the call center equipment is interpretting the outgoing audio voice
> prompt as a touch tone, then that is "talk off". Lowering the
> outgoing audio level a few dB can make a big difference.
>
> comp.dsp is a newsgroup like this one, nothing to sign up for, just
> post...
>
> Mark


Thanks for the invite... but what a waste of time that place was for me.

My problem is actually solved now, because the employer is setting up
another complete testing facility of the end-user's software package and
telephone line interfacing devices for full-on testing of the audio, in-house,
in an exact replication of the customer's usage (except for the phone line
peculiarities), before anything is shipped to his clients... so I will have a
first-hand, hands-on ability to learn everything from direct observation.


Thanks for trying to help,

--
David Morgan (MAMS)
http://www.m-a-m-s DOT com
Morgan Audio Media Service
Dallas, Texas (214) 662-9901
_______________________________________
http://www.artisan-recordingstudio.com

[Mark]

On Apr 18, 3:20 am, "David Morgan \(MAMS\)" /Odm>
wrote:
> "Mark" > wrote in glegroups.com...
>
> > > > It seems that the call is being dropped
> > > or moved forward during the outgoing prompt.
>
> > If the call center equipment is interpretting the outgoing audio voice
> > prompt as a touch tone, then that is "talk off". Lowering the
> > outgoing audio level a few dB can make a big difference.
>
> > comp.dsp is a newsgroup like this one, nothing to sign up for, just
> > post...
>
> > Mark
>
> Thanks for the invite... but what a waste of time that place was for me.
>
> My problem is actually solved now, because the employer is setting up
> another complete testing facility of the end-user's software package and
> telephone line interfacing devices for full-on testing of the audio, in-house,
> in an exact replication of the customer's usage (except for the phone line
> peculiarities), before anything is shipped to his clients... so I will have a
> first-hand, hands-on ability to learn everything from direct observation.
>
> Thanks for trying to help,
>
> --
> David Morgan (MAMS)http://www.m-a-m-sDOT com
> Morgan Audio Media Service
> Dallas, Texas (214) 662-9901
> _______________________________________http://www.artisan-recordingstudio.com

If you want to ask the folks that DESIGN DTMF desoders about "talk
off" , comp.dsp is the place... You can Google some past
discussions about talk off.
Mark

[[email protected]]

On Apr 18, 12:20 am, "David Morgan \(MAMS\)" /Odm>
wrote:
> "Mark" > wrote in glegroups.com...
>
> > > > It seems that the call is being dropped
> > > or moved forward during the outgoing prompt.
>
> > If the call center equipment is interpretting the outgoing audio voice
> > prompt as a touch tone, then that is "talk off". Lowering the
> > outgoing audio level a few dB can make a big difference.
>
> > comp.dsp is a newsgroup like this one, nothing to sign up for, just
> > post...
>
> > Mark
>
> Thanks for the invite... but what a waste of time that place was for me.
>
> My problem is actually solved now, because the employer is setting up
> another complete testing facility of the end-user's software package and
> telephone line interfacing devices for full-on testing of the audio, in-house,
> in an exact replication of the customer's usage (except for the phone line
> peculiarities), before anything is shipped to his clients... so I will have a
> first-hand, hands-on ability to learn everything from direct observation.
>
> Thanks for trying to help,
>
> --
> David Morgan (MAMS)http://www.m-a-m-sDOT com
> Morgan Audio Media Service
> Dallas, Texas (214) 662-9901
> _______________________________________http://www.artisan-recordingstudio.com

The employer should at least acquire a basic telephone line simulator
as well. The basic units are only a couple of hundred dollers. The
advanced units where one can simulate all kinds of signal degradations
possibly experienced are in the tens of thousands of dollars. If they
are seriously in this business, they should know that their
competitors do this. I have done this kind of work occasionally and
still keep a TLS in the lab.

bobs

Bob Smith
BS Studios
we organize chaos
http://www.bsstudios.com

[David Morgan \(MAMS\)]

"Mark" > wrote in message oups.com...
> On Apr 18, 3:20 am, "David Morgan \(MAMS\)" /Odm>
> wrote:
> > "Mark" > wrote in glegroups.com...
> >
> > > > > It seems that the call is being dropped
> > > > or moved forward during the outgoing prompt.
> >
> > > If the call center equipment is interpretting the outgoing audio voice
> > > prompt as a touch tone, then that is "talk off". Lowering the
> > > outgoing audio level a few dB can make a big difference.
> >
> > > comp.dsp is a newsgroup like this one, nothing to sign up for, just
> > > post...
> >
> > > Mark
> >
> > Thanks for the invite... but what a waste of time that place was for me.
> >
> > My problem is actually solved now, because the employer is setting up
> > another complete testing facility of the end-user's software package and
> > telephone line interfacing devices for full-on testing of the audio, in-house,
> > in an exact replication of the customer's usage (except for the phone line
> > peculiarities), before anything is shipped to his clients... so I will have a
> > first-hand, hands-on ability to learn everything from direct observation.
> >
> > Thanks for trying to help,
> >
> > --
> > David Morgan (MAMS)http://www.m-a-m-sDOT com
> > Morgan Audio Media Service
> > Dallas, Texas (214) 662-9901
> > _______________________________________
> > http://www.artisan-recordingstudio.com

> If you want to ask the folks that DESIGN DTMF desoders about "talk
> off" , comp.dsp is the place... You can Google some past
> discussions about talk off.
> Mark


Thanks again... I'll Google some more, but a week there was long enough.

Cheers

[David Morgan \(MAMS\)]

> wrote in message ps.com...
> On Apr 18, 12:20 am, "David Morgan \(MAMS\)" /Odm>
> wrote:
> > "Mark" > wrote in glegroups.com...
> >
> > > > > It seems that the call is being dropped
> > > > or moved forward during the outgoing prompt.
> >
> > > If the call center equipment is interpretting the outgoing audio voice
> > > prompt as a touch tone, then that is "talk off". Lowering the
> > > outgoing audio level a few dB can make a big difference.
> >
> > > comp.dsp is a newsgroup like this one, nothing to sign up for, just
> > > post...
> >
> > > Mark
> >
> > Thanks for the invite... but what a waste of time that place was for me.
> >
> > My problem is actually solved now, because the employer is setting up
> > another complete testing facility of the end-user's software package and
> > telephone line interfacing devices for full-on testing of the audio, in-house,
> > in an exact replication of the customer's usage (except for the phone line
> > peculiarities), before anything is shipped to his clients... so I will have a
> > first-hand, hands-on ability to learn everything from direct observation.
> >
> > Thanks for trying to help,
> >
> > --
> > David Morgan (MAMS)http://www.m-a-m-sDOT com
> > Morgan Audio Media Service
> > Dallas, Texas (214) 662-9901
> > _______________________________________
> > http://www.artisan-recordingstudio.com

> The employer should at least acquire a basic telephone line simulator
> as well. The basic units are only a couple of hundred dollers. The
> advanced units where one can simulate all kinds of signal degradations
> possibly experienced are in the tens of thousands of dollars. If they
> are seriously in this business, they should know that their
> competitors do this. I have done this kind of work occasionally and
> still keep a TLS in the lab.
>
> bobs
>
> Bob Smith
> BS Studios
> we organize chaos
> http://www.bsstudios.com


Sometime within the next few days, a new QC lab will be brought
back on line... I'll be able to dive in from there. I'm relatively certain
that such a facility and device existed (and will exist again) but must
have became a bit relaxed via success.

[[email protected]]

On 2007-04-18 KxkVh.1188$Da6.602@trnddc02 said:
>The employer should at least acquire a basic telephone line
>simulator as well. The basic units are only a couple of hundred
>dollers. The advanced units where one can simulate all kinds of
>signal degradations possibly experienced are in the tens of
>thousands of dollars. If they are seriously in this business, they
>should know that their competitors do this. I have done this kind
>of work occasionally and still keep a TLS in the lab.
I would agree with Bob here. All sorts of things can happen
to that signal between telephone sets while on its journey
through switches and along miles of wire, through cell phone
repeaters, etc.
From my limited experience with dtmf decode problems I've
found that you can get everything humming on the bench, but
as soon as you deploy this thing at the almost inaccessible
relay site on a mountaintop or in that locked closet on the
upper floor of the high rise office building or at the
broadcaster's transmitter site where you can't get in but
occasionally the problems will show themselves immediately.
All sorts of neat little noise sources from rf interference
and other causes travel with the wanted audio signal
through all that equipment.

I"d strongly suggest they acquire one of these simulators
for their testing facility.



Richard webb,
Electric Spider Productions
Replace anything before the @ symbol with elspider for real
email address.



Great audio is never heard by the average person, but bad
audio is heard by everyone.