WAV file in CCITT uLaw format strangely does not play in CVP

[geoff]

Greetings,

I came across an interesting problem today and wonder if this has happened to any other NetPro members.

I have recently built an internal application for a customer that requests employee number and PIN, does a DB dip to find out if things are kosher and returns a flag that controls the menu tree they hear. The application actually has 4 different (and substantial) menu trees depending on the DB value returned. I used a TTS engine to generate the 100 or so prompts required during the development and sent the prompt dictionary information to the customer. I also sent specifications for the recording format.

After a little back and forth to confirm they understood how to verify CCITT uLaw files, they made the recordings and sent them to me. They used the file names I sent them and it looked like a straightforward effort to drop these in the right place and stale the cache. But no.

I could not understand why these failed to play on the gateway in CVP.

They trace in CVP VXML as a badfetch exception in the activity log, and in a microapp as a BAD FETCH in the CVP log file.

But Sound recorder shows them as CCITT uLaw, 8kHz, 8-bit mono, and  the properties are the same.

There were also some recordings the customer made that worked just fine. This took me a while to sort out.

If I look at these files with a hex editor (like the plugin for Notepad++ which is excellent) I can see that the problem ones all have the same header, and this is different from the ones that work. Here is a shot of the hex editor on one of the bad ones.

Clearly they have been made on different systems. I've asked the customer to provide the recording details.

We had a slightly similar issue in Europe last year where the CCITT conversion done by the recording studio was bad and failed to work. If we took the PCM files and converted them with Audacity or similar, they worked. We had to convince the studio that their method of conversion was producing a file that the gateway would not play, despite looking to be correct.

It seems that the IVR Media Player in the gateway is picky. Has anyone else had issues like this?

Regards,

Geoff

[david.macias]

I've seen something similar, but for the life of me can't find what project it was on.  Regardless, if I remember correctly our issue came down to the sampling rate was something like 64k instead of the usuall 8k.  Sorry I can't remember much more, I'll keep lookinng to see if I run into the documentation about it.

david

[Sunil_Vs1]

Couple of days back we did face the same problem and we suspected that gateway has some security problem in playing this file  and replaced this with the right one. I am not sure whether the customer used diff method/studio to record this file but it looked good in terms of everything. Here's how it looks…

Regards,

Sunil

[Edward Umansky]

The wave format should have the ASCII characters "data" preceding the actual data bytes. Looks like in your example this is missing along with some other potentially required information. The rest of the standard header is all there (sample rate, number of channels, etc.). I'm guessing windows is just more tolerant of this error and that is why it works ok there. Some more wav file format info here: http://www-mmsp.ece.mcgill.ca/documents/audioformats/wave/wave.html

[Edward Umansky]

On second thought I can't see past the "JUNK" data in your screenshot so the other fields are probably there if you scroll down. Assuming everything else is there, it's possible that the gateway cannot process the "JUNK" field so it throws an error. Unknown or nonstandard field should typically be ignored by audio players, the gateway may just be very picky about this. Either way there is no reason for the audio provider to send you files with junk or filler data, that only makes sense for data alignment on audio CD's or something similar.