Proper prompt gain/level
As part of creating prompts for my IVRs, I've tried to match the audio gain of my prompts with the gain of the stock English prompts. During this process, I noticed that the English Callie prompts are recorded extremely low (max gain around -16DB). I have the Cepstral Callie voice, and I must set the Cepstral volume to about 50% in order to match the gain of the English prompts. In conferences and other situations where prompts are played over conversations, the level of the prompts are obviously low. I can, of course, renormalize the gain of the prompts up to -10DB or more with a sound editor. However, I wonder if there is a better way to change the level of the prompts, or if there is a good reason for the prompts to be encoded at such a low level. I haven't considered all of the implications yet, but I'm fairly sure that encoding the prompts this quietly is not the best approach, even if it is desirable for the prompts to play quietly on a call. For each 6DB reduction in gain, there is a 50% reduction in perceived volume, and one less significant bit is used for storing the audio. In a 16-bit file, a maximum gain of -16 means that only the 14 least significant bits are actually used for encoding the audio. This results in a reduction in dynamic range, but the difference isn't really noticeable as long as the data remains 16-bit. The problem comes when the audio is converted to a different bit depth. For example, most quickie routines for converting 16-bit audio to 8-bit audio will simply chop off the 8 least significant bits. Therefore, when the prompts are converted to 8-bit audio for use by most of the narrow band codecs, the prompts are only using 6 bits of audio. If the volume of the channel is increased, then the 6 bits are promoted, and the dithering errors at the bottom become louder. In the worst case, since these prompts are only encoded with 14 bits of actual data, and converting to an 8-bit channel will only leave 6 bits of actual data, boosting the gain of the prompts on an 8-bit channel to full loudness would result in the noise floor (the level of the dithering crackle) being about -18DB. That's almost as loud as the prompts themselves sound at the moment. Anyway, regardless of observations, is there a reason why the prompts must be recorded so quietly? If I'd like them louder (without increasing the gain of the entire channel), is there a way other than running them through a tool to renormalize their max levels? Bryan
Wavepad is free and will do bulk changes to sound files. Won't AGC solve this? Jan -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Bryan Smart Sent: 26. juni 2011 22:32 To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Proper prompt gain/level As part of creating prompts for my IVRs, I've tried to match the audio gain of my prompts with the gain of the stock English prompts. During this process, I noticed that the English Callie prompts are recorded extremely low (max gain around -16DB). I have the Cepstral Callie voice, and I must set the Cepstral volume to about 50% in order to match the gain of the English prompts. In conferences and other situations where prompts are played over conversations, the level of the prompts are obviously low. I can, of course, renormalize the gain of the prompts up to -10DB or more with a sound editor. However, I wonder if there is a better way to change the level of the prompts, or if there is a good reason for the prompts to be encoded at such a low level. I haven't considered all of the implications yet, but I'm fairly sure that encoding the prompts this quietly is not the best approach, even if it is desirable for the prompts to play quietly on a call. For each 6DB reduction in gain, there is a 50% reduction in perceived volume, and one less significant bit is used for storing the audio. In a 16-bit file, a maximum gain of -16 means that only the 14 least significant bits are actually used for encoding the audio. This results in a reduction in dynamic range, but the difference isn't really noticeable as long as the data remains 16-bit. The problem comes when the audio is converted to a different bit depth. For example, most quickie routines for converting 16-bit audio to 8-bit audio will simply chop off the 8 least significant bits. Therefore, when the prompts are converted to 8-bit audio for use by most of the narrow band codecs, the prompts are only using 6 bits of audio. If the volume of the channel is increased, then the 6 bits are promoted, and the dithering errors at the bottom become louder. In the worst case, since these prompts are only encoded with 14 bits of actual data, and converting to an 8-bit channel will only leave 6 bits of actual data, boosting the gain of the prompts on an 8-bit channel to full loudness would result in the noise floor (the level of the dithering crackle) being about -18DB. That's almost as loud as the prompts themselves sound at the moment. Anyway, regardless of observations, is there a reason why the prompts must be recorded so quietly? If I'd like them louder (without increasing the gain of the entire channel), is there a way other than running them through a tool to renormalize their max levels? Bryan _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
you can also run sox on a script to change the volume of the sound files by batch. On Mon, Jun 27, 2011 at 5:20 AM, Jan Berger <jan.berger@video24.no> wrote:
Wavepad is free and will do bulk changes to sound files.
Won't AGC solve this?
Jan
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Bryan Smart Sent: 26. juni 2011 22:32 To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Proper prompt gain/level
As part of creating prompts for my IVRs, I've tried to match the audio gain of my prompts with the gain of the stock English prompts. During this process, I noticed that the English Callie prompts are recorded extremely low (max gain around -16DB). I have the Cepstral Callie voice, and I must set the Cepstral volume to about 50% in order to match the gain of the English prompts. In conferences and other situations where prompts are played over conversations, the level of the prompts are obviously low.
I can, of course, renormalize the gain of the prompts up to -10DB or more with a sound editor. However, I wonder if there is a better way to change the level of the prompts, or if there is a good reason for the prompts to be encoded at such a low level.
I haven't considered all of the implications yet, but I'm fairly sure that encoding the prompts this quietly is not the best approach, even if it is desirable for the prompts to play quietly on a call. For each 6DB reduction in gain, there is a 50% reduction in perceived volume, and one less significant bit is used for storing the audio. In a 16-bit file, a maximum gain of -16 means that only the 14 least significant bits are actually used for encoding the audio. This results in a reduction in dynamic range, but the difference isn't really noticeable as long as the data remains 16-bit. The problem comes when the audio is converted to a different bit depth. For example, most quickie routines for converting 16-bit audio to 8-bit audio will simply chop off the 8 least significant bits. Therefore, when the prompts are converted to 8-bit audio for use by most of the narrow band codecs, the prompts are only using 6 bits of audio. If the volume of the channel is increased, then the 6 bits are promoted, and the dithering errors at the bottom become louder. In the worst case, since these prompts are only encoded with 14 bits of actual data, and converting to an 8-bit channel will only leave 6 bits of actual data, boosting the gain of the prompts on an 8-bit channel to full loudness would result in the noise floor (the level of the dithering crackle) being about -18DB. That's almost as loud as the prompts themselves sound at the moment.
Anyway, regardless of observations, is there a reason why the prompts must be recorded so quietly? If I'd like them louder (without increasing the gain of the entire channel), is there a way other than running them through a tool to renormalize their max levels?
Bryan
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yeah sox is great for command line and batch changes to volume levels // this command invocation outputs the maximum volume increase <name-of-input-sound-file> can go through without any distortion. The maximum volume increase possible is stored as a decimal in max_vol.txt sox <name-of-input-sound-file> -n stat -v 2> max_vol.txt // This command actually boosts the volume level of the input file. Output is stored in <name-of-output-sound-file> sox -v `cat max_vol.txt` <name-of-input-sound-file> <name-of-output-sound-file> On Mon, Jun 27, 2011 at 4:34 AM, Nandy Dagondon <gcd@i.ph> wrote:
you can also run sox on a script to change the volume of the sound files by batch.
On Mon, Jun 27, 2011 at 5:20 AM, Jan Berger <jan.berger@video24.no> wrote:
Wavepad is free and will do bulk changes to sound files.
Won't AGC solve this?
Jan
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Bryan Smart Sent: 26. juni 2011 22:32 To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Proper prompt gain/level
As part of creating prompts for my IVRs, I've tried to match the audio gain of my prompts with the gain of the stock English prompts. During this process, I noticed that the English Callie prompts are recorded extremely low (max gain around -16DB). I have the Cepstral Callie voice, and I must set the Cepstral volume to about 50% in order to match the gain of the English prompts. In conferences and other situations where prompts are played over conversations, the level of the prompts are obviously low.
I can, of course, renormalize the gain of the prompts up to -10DB or more with a sound editor. However, I wonder if there is a better way to change the level of the prompts, or if there is a good reason for the prompts to be encoded at such a low level.
I haven't considered all of the implications yet, but I'm fairly sure that encoding the prompts this quietly is not the best approach, even if it is desirable for the prompts to play quietly on a call. For each 6DB reduction in gain, there is a 50% reduction in perceived volume, and one less significant bit is used for storing the audio. In a 16-bit file, a maximum gain of -16 means that only the 14 least significant bits are actually used for encoding the audio. This results in a reduction in dynamic range, but the difference isn't really noticeable as long as the data remains 16-bit. The problem comes when the audio is converted to a different bit depth. For example, most quickie routines for converting 16-bit audio to 8-bit audio will simply chop off the 8 least significant bits. Therefore, when the prompts are converted to 8-bit audio for use by most of the narrow band codecs, the prompts are only using 6 bits of audio. If the volume of the channel is increased, then the 6 bits are promoted, and the dithering errors at the bottom become louder. In the worst case, since these prompts are only encoded with 14 bits of actual data, and converting to an 8-bit channel will only leave 6 bits of actual data, boosting the gain of the prompts on an 8-bit channel to full loudness would result in the noise floor (the level of the dithering crackle) being about -18DB. That's almost as loud as the prompts themselves sound at the moment.
Anyway, regardless of observations, is there a reason why the prompts must be recorded so quietly? If I'd like them louder (without increasing the gain of the entire channel), is there a way other than running them through a tool to renormalize their max levels?
Bryan
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Sidharth Kshatriya www.sidk.info
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc). What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right? The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan. <action application="set_audio_level" data="write 4"/> That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts. I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time. Bryan On Jun 26, 2011, at 5:20 PM, Jan Berger wrote:
Wavepad is free and will do bulk changes to sound files.
Won't AGC solve this?
Jan
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Bryan Smart Sent: 26. juni 2011 22:32 To: freeswitch-users@lists.freeswitch.org Subject: [Freeswitch-users] Proper prompt gain/level
As part of creating prompts for my IVRs, I've tried to match the audio gain of my prompts with the gain of the stock English prompts. During this process, I noticed that the English Callie prompts are recorded extremely low (max gain around -16DB). I have the Cepstral Callie voice, and I must set the Cepstral volume to about 50% in order to match the gain of the English prompts. In conferences and other situations where prompts are played over conversations, the level of the prompts are obviously low.
I can, of course, renormalize the gain of the prompts up to -10DB or more with a sound editor. However, I wonder if there is a better way to change the level of the prompts, or if there is a good reason for the prompts to be encoded at such a low level.
I haven't considered all of the implications yet, but I'm fairly sure that encoding the prompts this quietly is not the best approach, even if it is desirable for the prompts to play quietly on a call. For each 6DB reduction in gain, there is a 50% reduction in perceived volume, and one less significant bit is used for storing the audio. In a 16-bit file, a maximum gain of -16 means that only the 14 least significant bits are actually used for encoding the audio. This results in a reduction in dynamic range, but the difference isn't really noticeable as long as the data remains 16-bit. The problem comes when the audio is converted to a different bit depth. For example, most quickie routines for converting 16-bit audio to 8-bit audio will simply chop off the 8 least significant bits. Therefore, when the prompts are converted to 8-bit audio for use by most of the narrow band codecs, the prompts are only using 6 bits of audio. If the volume of the channel is increased, then the 6 bits are promoted, and the dithering errors at the bottom become louder. In the worst case, since these prompts are only encoded with 14 bits of actual data, and converting to an 8-bit channel will only leave 6 bits of actual data, boosting the gain of the prompts on an 8-bit channel to full loudness would result in the noise floor (the level of the dithering crackle) being about -18DB. That's almost as loud as the prompts themselves sound at the moment.
Anyway, regardless of observations, is there a reason why the prompts must be recorded so quietly? If I'd like them louder (without increasing the gain of the entire channel), is there a way other than running them through a tool to renormalize their max levels?
Bryan
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 06/27/2011 07:11 AM, Bryan Smart wrote:
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc).
What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right?
The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. -16dBM0 or -16dBOv, and average or peak burst power? -16dBOv for the average power is about where you want a voice prompt to be. In some juristictions you could be in breach of a regulation or two if you set the level higher than that on the PSTN. Why would you set a voice prompt to 0dB? It will be clipping like crazy. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan.
<action application="set_audio_level" data="write 4"/>
That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts.
I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time.
Bryan Steve
I don't want to maximize peaks all the way to 0DB. I just wondered why a low level like -16DB was used. When I'd previously created prompts on Asterisk systems, I used -6DB as a peak (50% of max gain for the channel). I wasn't aware of any regulations about prompt level. If there is a standardized level, that is what I'd like to use. Perhaps the louder systems are disregarding standards? Does anyone have links to such info? I've been unable to find anything definitive, only opinions. Listen to TellMe (+1-800-555-8355). It's at least 3X the gain of the default FS prompts. Is TellMe in error? I've called them through both FS and Asterisk, using Vitelity and Callcentric, so I'm fairly sure that I'm not being mislead by a switch or ITSP boosting the gain. I always felt their level was strong and intelligible, without sounding overwhelming. One point that caught my attention, though, is that you said -16DB for both average and peak power. Average and peak power don't come out the same, though. So that we can talk about something concrete, consider conference/32000/conf-enter_conf_pin.wav. Its peak power is -15.7DB. However, its average power (RMS) is -31.3DB! -31DB is profoundly quiet. If its average power is boosted to -16DB, then the peak power is now around -2DB. As long as peak power is less than 0DB, then the audio won't clip, but it might be too loud for comfort. I previously used -6DB for a peak, as I couldn't find any real guidelines regarding levels, and -6 sounded good to me. Maybe FS is lower than it should be. Maybe other services are louder than they should be. If FS should be louder, though, I'd like to help to change the levels up-stream, rather than locally reprocessing the prompts. So, is this a personal judgement case, or are their standards available that can be consulted? Bryan On Jun 27, 2011, at 9:48 AM, Steve Underwood wrote:
On 06/27/2011 07:11 AM, Bryan Smart wrote:
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc).
What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right?
The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. -16dBM0 or -16dBOv, and average or peak burst power? -16dBOv for the average power is about where you want a voice prompt to be. In some juristictions you could be in breach of a regulation or two if you set the level higher than that on the PSTN. Why would you set a voice prompt to 0dB? It will be clipping like crazy. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan.
<action application="set_audio_level" data="write 4"/>
That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts.
I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time.
Bryan Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels. I will say I find the volume of many phone systems overdriven and I think the goal was to keep the sound files in the neighborhood of what a live person sounds like with no clipping. I am quite sure nobody was looking at the specific dB levels when generating them. I am not really overly picky about what level we distribute at and I would defer it to the majority of users to see if there is a perception of the volume being too low in our sound files. If there is an overwhelming agreement that the volume is too low, I would be willing to adjust it if you are interested in taking ownership of the task. On Mon, Jun 27, 2011 at 3:00 PM, Bryan Smart <bryansmart@bryansmart.com> wrote:
I don't want to maximize peaks all the way to 0DB. I just wondered why a low level like -16DB was used. When I'd previously created prompts on Asterisk systems, I used -6DB as a peak (50% of max gain for the channel).
I wasn't aware of any regulations about prompt level. If there is a standardized level, that is what I'd like to use. Perhaps the louder systems are disregarding standards? Does anyone have links to such info? I've been unable to find anything definitive, only opinions.
Listen to TellMe (+1-800-555-8355). It's at least 3X the gain of the default FS prompts. Is TellMe in error? I've called them through both FS and Asterisk, using Vitelity and Callcentric, so I'm fairly sure that I'm not being mislead by a switch or ITSP boosting the gain. I always felt their level was strong and intelligible, without sounding overwhelming.
One point that caught my attention, though, is that you said -16DB for both average and peak power. Average and peak power don't come out the same, though.
So that we can talk about something concrete, consider conference/32000/conf-enter_conf_pin.wav. Its peak power is -15.7DB. However, its average power (RMS) is -31.3DB! -31DB is profoundly quiet. If its average power is boosted to -16DB, then the peak power is now around -2DB. As long as peak power is less than 0DB, then the audio won't clip, but it might be too loud for comfort. I previously used -6DB for a peak, as I couldn't find any real guidelines regarding levels, and -6 sounded good to me.
Maybe FS is lower than it should be. Maybe other services are louder than they should be. If FS should be louder, though, I'd like to help to change the levels up-stream, rather than locally reprocessing the prompts.
So, is this a personal judgement case, or are their standards available that can be consulted?
Bryan
On Jun 27, 2011, at 9:48 AM, Steve Underwood wrote:
On 06/27/2011 07:11 AM, Bryan Smart wrote:
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc).
What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right?
The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. -16dBM0 or -16dBOv, and average or peak burst power? -16dBOv for the average power is about where you want a voice prompt to be. In some juristictions you could be in breach of a regulation or two if you set the level higher than that on the PSTN. Why would you set a voice prompt to 0dB? It will be clipping like crazy. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan.
<action application="set_audio_level" data="write 4"/>
That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts.
I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time.
Bryan Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
On Mon, Jun 27, 2011 at 3:07 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels.
Just for the record, the sox command used to normalize the sounds is: sox -v 0.2 $file_in -r $rate -c 1 $file_out The -v format is the "volume" format and if I read the sox man page correctly it means a "linear amplitude adjustment". What I can't tell from the man page is whether .2 means "reduce by 20%" or "reduce to 20%" or something else. In any case, like Tony says, we are not picky about this as long as it's not pointlessly loud. -MC
-v is a multiplier. So, -v 0.2 reduces gain to 20% of original. It is typical to supply professionally recorded audio with peaks boosted to 0DBFS. That is probably how the prompts were originally supplied. It makes since that -v 0.2 would reduce the max power to 20%, around -15 to -16 DBFS. The FS build process downloads pre-processed versions of these files. Is there somewhere online that I can find the source recordings+script that produces the pre-processed files that are downloaded by the build process? Bryan On Jun 27, 2011, at 7:32 PM, Michael Collins wrote: On Mon, Jun 27, 2011 at 3:07 PM, Anthony Minessale <anthony.minessale@gmail.com<mailto:anthony.minessale@gmail.com>> wrote: Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels. Just for the record, the sox command used to normalize the sounds is: sox -v 0.2 $file_in -r $rate -c 1 $file_out The -v format is the "volume" format and if I read the sox man page correctly it means a "linear amplitude adjustment". What I can't tell from the man page is whether .2 means "reduce by 20%" or "reduce to 20%" or something else. In any case, like Tony says, we are not picky about this as long as it's not pointlessly loud. -MC _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
You can download the 48kHz files from files.freeswitch.org. The script itself is nothing special - all it does is cycle through the target sampling rates and run each file through sox. Here's a copy of the script: base_dir="48000" rates="48000 32000 16000 8000" version="1.0.16" voice="en-us-callie" voice_dir="en/us/callie" tar_path="../../.." tmp_dir="tmp" CWD=`pwd` for rate in $rates; do \ mkdir -p $tmp_dir/$voice_dir for dir in `ls $base_dir`; do \ test -d $tmp_dir/$voice_dir/$dir/$rate || mkdir -p $tmp_dir/$voice_dir/$dir/$rate; \ for filename in `ls $base_dir/$dir`; do \ echo sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ done ; \ done ; \ cd $tmp_dir echo tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ cd - rm -rf $tmp_dir done cd $tar_path for rate in $rates; do \ openssl dgst -sha1 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.sha1 ; \ openssl dgst -md5 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.md5 ; \ done cd $CWD Let me know if you have any suggestions. -MC On Mon, Jun 27, 2011 at 8:25 PM, Bryan Smart <bryansmart@bryansmart.com>wrote:
-v is a multiplier. So, -v 0.2 reduces gain to 20% of original.
It is typical to supply professionally recorded audio with peaks boosted to 0DBFS. That is probably how the prompts were originally supplied. It makes since that -v 0.2 would reduce the max power to 20%, around -15 to -16 DBFS.
The FS build process downloads pre-processed versions of these files. Is there somewhere online that I can find the source recordings+script that produces the pre-processed files that are downloaded by the build process?
Bryan
On Jun 27, 2011, at 7:32 PM, Michael Collins wrote:
On Mon, Jun 27, 2011 at 3:07 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels.
Just for the record, the sox command used to normalize the sounds is: sox -v 0.2 $file_in -r $rate -c 1 $file_out
The -v format is the "volume" format and if I read the sox man page correctly it means a "linear amplitude adjustment". What I can't tell from the man page is whether .2 means "reduce by 20%" or "reduce to 20%" or something else. In any case, like Tony says, we are not picky about this as long as it's not pointlessly loud.
-MC _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi, Michael. Thanks for posting this. Have you considered using the higher quality sample rate conversion features in new versions of sox? A starting place for info is here: http://sox.sourceforge.net/SoX/Resampling Perhaps change: sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename to: sox $base_dir/$dir/$filename -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename rate -v -I $rate dither rate -v -I $rate: Replaces -r $rate. Uses the newer "very high quality" mode (instead of "high quality") with Intermediate Phase response (instead of linear). This setting is superior to the default, but slower to process. dither: Applies basic triangular dithering. There are other dithering strategies, but, based on what I've read and experienced, they aren't as useful when down-sampling to low rates. Might produce slightly higher quality files, the next time it is necessary to regenerate them. Bryan On Jun 28, 2011, at 11:18 AM, Michael Collins wrote: You can download the 48kHz files from files.freeswitch.org<http://files.freeswitch.org/>. The script itself is nothing special - all it does is cycle through the target sampling rates and run each file through sox. Here's a copy of the script: base_dir="48000" rates="48000 32000 16000 8000" version="1.0.16" voice="en-us-callie" voice_dir="en/us/callie" tar_path="../../.." tmp_dir="tmp" CWD=`pwd` for rate in $rates; do \ mkdir -p $tmp_dir/$voice_dir for dir in `ls $base_dir`; do \ test -d $tmp_dir/$voice_dir/$dir/$rate || mkdir -p $tmp_dir/$voice_dir/$dir/$rate; \ for filename in `ls $base_dir/$dir`; do \ echo sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ done ; \ done ; \ cd $tmp_dir echo tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ cd - rm -rf $tmp_dir done cd $tar_path for rate in $rates; do \ openssl dgst -sha1 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.sha1 ; \ openssl dgst -md5 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.md5 ; \ done cd $CWD Let me know if you have any suggestions. -MC On Mon, Jun 27, 2011 at 8:25 PM, Bryan Smart <bryansmart@bryansmart.com<mailto:bryansmart@bryansmart.com>> wrote: -v is a multiplier. So, -v 0.2 reduces gain to 20% of original. It is typical to supply professionally recorded audio with peaks boosted to 0DBFS. That is probably how the prompts were originally supplied. It makes since that -v 0.2 would reduce the max power to 20%, around -15 to -16 DBFS. The FS build process downloads pre-processed versions of these files. Is there somewhere online that I can find the source recordings+script that produces the pre-processed files that are downloaded by the build process? Bryan On Jun 27, 2011, at 7:32 PM, Michael Collins wrote: On Mon, Jun 27, 2011 at 3:07 PM, Anthony Minessale <anthony.minessale@gmail.com<mailto:anthony.minessale@gmail.com>> wrote: Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels. Just for the record, the sox command used to normalize the sounds is: sox -v 0.2 $file_in -r $rate -c 1 $file_out The -v format is the "volume" format and if I read the sox man page correctly it means a "linear amplitude adjustment". What I can't tell from the man page is whether .2 means "reduce by 20%" or "reduce to 20%" or something else. In any case, like Tony says, we are not picky about this as long as it's not pointlessly loud. -MC _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com<http://www.cluecon.com/> 877-7-4ACLUE FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org<http://www.freeswitch.org/> _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com<http://www.cluecon.com/> 877-7-4ACLUE FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org<http://www.freeswitch.org/> _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I will give this a whirl and see what happens. I have no problems trying that out. -MC On Tue, Jun 28, 2011 at 7:12 PM, Bryan Smart <bryansmart@bryansmart.com>wrote:
Hi, Michael.
Thanks for posting this.
Have you considered using the higher quality sample rate conversion features in new versions of sox?
A starting place for info is here: http://sox.sourceforge.net/SoX/Resampling
Perhaps change:
sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename
to:
sox $base_dir/$dir/$filename -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename rate -v -I $rate dither
rate -v -I $rate: Replaces -r $rate. Uses the newer "very high quality" mode (instead of "high quality") with Intermediate Phase response (instead of linear). This setting is superior to the default, but slower to process.
dither: Applies basic triangular dithering. There are other dithering strategies, but, based on what I've read and experienced, they aren't as useful when down-sampling to low rates.
Might produce slightly higher quality files, the next time it is necessary to regenerate them.
Bryan
On Jun 28, 2011, at 11:18 AM, Michael Collins wrote:
You can download the 48kHz files from files.freeswitch.org. The script itself is nothing special - all it does is cycle through the target sampling rates and run each file through sox. Here's a copy of the script:
base_dir="48000" rates="48000 32000 16000 8000" version="1.0.16" voice="en-us-callie" voice_dir="en/us/callie" tar_path="../../.." tmp_dir="tmp" CWD=`pwd`
for rate in $rates; do \ mkdir -p $tmp_dir/$voice_dir for dir in `ls $base_dir`; do \ test -d $tmp_dir/$voice_dir/$dir/$rate || mkdir -p $tmp_dir/$voice_dir/$dir/$rate; \ for filename in `ls $base_dir/$dir`; do \ echo sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ sox -v 0.2 $base_dir/$dir/$filename -r $rate -c 1 $tmp_dir/$voice_dir/$dir/$rate/$filename; \ done ; \ done ; \ cd $tmp_dir echo tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ tar -cvzf $CWD/$tar_path/freeswitch-sounds-$voice-$rate-$version.tar.gz *; \ cd - rm -rf $tmp_dir done
cd $tar_path for rate in $rates; do \ openssl dgst -sha1 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.sha1 ; \ openssl dgst -md5 freeswitch-sounds-$voice-$rate-$version.tar.gz > freeswitch-sounds-$voice-$rate-$version.tar.gz.md5 ; \ done cd $CWD
Let me know if you have any suggestions. -MC
On Mon, Jun 27, 2011 at 8:25 PM, Bryan Smart <bryansmart@bryansmart.com>wrote:
-v is a multiplier. So, -v 0.2 reduces gain to 20% of original.
It is typical to supply professionally recorded audio with peaks boosted to 0DBFS. That is probably how the prompts were originally supplied. It makes since that -v 0.2 would reduce the max power to 20%, around -15 to -16 DBFS.
The FS build process downloads pre-processed versions of these files. Is there somewhere online that I can find the source recordings+script that produces the pre-processed files that are downloaded by the build process?
Bryan
On Jun 27, 2011, at 7:32 PM, Michael Collins wrote:
On Mon, Jun 27, 2011 at 3:07 PM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
Have a look at the 48khz versions of the files, those should be the originals. Someone runs a batch sox command on them to get them to the other levels.
Just for the record, the sox command used to normalize the sounds is: sox -v 0.2 $file_in -r $rate -c 1 $file_out
The -v format is the "volume" format and if I read the sox man page correctly it means a "linear amplitude adjustment". What I can't tell from the man page is whether .2 means "reduce by 20%" or "reduce to 20%" or something else. In any case, like Tony says, we are not picky about this as long as it's not pointlessly loud.
-MC _______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 06/28/2011 04:00 AM, Bryan Smart wrote:
I don't want to maximize peaks all the way to 0DB. I just wondered why a low level like -16DB was used. When I'd previously created prompts on Asterisk systems, I used -6DB as a peak (50% of max gain for the channel). The peaks of voice are general something like 12 to 13dB above the short term RMS value. If the -16dB value you quoted is -16dBOv, its 13dB below clipping. Your peaks should be close to clipping at -16dB. I wasn't aware of any regulations about prompt level. If there is a standardized level, that is what I'd like to use. Perhaps the louder systems are disregarding standards? Does anyone have links to such info? I've been unable to find anything definitive, only opinions. In many places the regulation says the power on a PSTN line should not exceed -13dBm0. That's why -13dBm0 is the target power level for most PSTN modems. Listen to TellMe (+1-800-555-8355). It's at least 3X the gain of the default FS prompts. Is TellMe in error? I've called them through both FS and Asterisk, using Vitelity and Callcentric, so I'm fairly sure that I'm not being mislead by a switch or ITSP boosting the gain. I always felt their level was strong and intelligible, without sounding overwhelming. Not everyone bothers to obey regulations these days, and many people do love to blast sound into an overloaded highly distorted mess, because volume is king. Its not good for clarity, though. What the loudest people do is no measure of good engineering. Sadly, this behaviour might make people set their levels around the excessively loud signals, so a properly adjusted signal sounds too quiet. In the early days of my FAX modem work I received many recordings from people who could not get reliable results, where the audio was perpetually in clipping, and any speech through the channel would have sounded awful. They would generally insist that voice was "perfect" on their system. There is a serious lack of engineering in most VoIP work. One point that caught my attention, though, is that you said -16DB for both average and peak power. Average and peak power don't come out the same, though.
So that we can talk about something concrete, consider conference/32000/conf-enter_conf_pin.wav. Its peak power is -15.7DB. However, its average power (RMS) is -31.3DB! -31DB is profoundly quiet. If its average power is boosted to -16DB, then the peak power is now around -2DB. As long as peak power is less than 0DB, then the audio won't clip, but it might be too loud for comfort. I previously used -6DB for a peak, as I couldn't find any real guidelines regarding levels, and -6 sounded good to me. You still haven't said whether you are talking dBm0 or dBOv. It makes a 6dB difference. Also, what do you mean by peak power? If the peaks of the short term RMS power are hitting 0dB, the peaks of the waveform will be far into clipping. If you are talking about dBOv, then -6dB is only 3dB from the onset of clipping, and voice will clip a lot. If you are talking dBm0, -6dB is 9dB from clipping, and the voice will only clip a bit, and maybe not sound too bad. However, clipped voice tends to pass through low bit rate codecs worse than clean voice, so you might want to keep the clipping down to a really occasional event. Voice codecs have at least 12 bits of dynamic range. They are designed to allow a voice to bubble along at -30dB with good quality, and burst up to a much higher level in the loud bits. Maybe FS is lower than it should be. Maybe other services are louder than they should be. If FS should be louder, though, I'd like to help to change the levels up-stream, rather than locally reprocessing the prompts.
So, is this a personal judgement case, or are their standards available that can be consulted?
Bryan
On Jun 27, 2011, at 9:48 AM, Steve Underwood wrote:
On 06/27/2011 07:11 AM, Bryan Smart wrote:
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc).
What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right?
The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. -16dBM0 or -16dBOv, and average or peak burst power? -16dBOv for the average power is about where you want a voice prompt to be. In some juristictions you could be in breach of a regulation or two if you set the level higher than that on the PSTN. Why would you set a voice prompt to 0dB? It will be clipping like crazy. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan.
<action application="set_audio_level" data="write 4"/>
That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts.
I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time.
Bryan Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi all, i created the following dial plan: <extension name="call_in_play"> <condition field="destination_number" expression="^498925007676"> <action application="sched_hangup" data="+3599"/> <action application="set" data="group_confirm_file=playback $${base_dir}/sound/calls/callparty.wav"/> <action application="set" data="group_confirm_key=exec"/> <action application="transfer" data="0 XML operator1"/> </condition> </extension> Fs play the soundfile 3 times befor the connection Can i change these please? thanks. group_confirm_file --------------- Du kannst mich jederzeit kostenlos per Festnetz erreichen unter: http://www.blindi.net/callback homepage: http://www.blindi.net blinde-misc mailingliste für blinde. anmeldung unter: http://www.blindi.net/mailman/listinfo/blinde-misc
I think that dBm0 only applies if we are measuring the power on an analog circuit, or at the d/a point of a digital circuit. I was performing analysis of a digitally encoded audio file, therefore the measurement is dBFS, and 0DBFS is the point where clipping takes place. Anything below 0DBFS does not clip, even though it might seem loud to someone. I stated that the peak power of the stock prompts are typically -15 to -16 (DBFS), and the short term RMS power is about -32DBFS. I don't know how to properly evaluate how DBFS will convert to DBm0. I gather that the codec and the d/a converter attenuate the level to some extent, but I don't know how much. If I have a digital file with a 1Khz test tone at -10DBFS, and play that over the pstn, what do I get out in DBm0? Speaking just in terms of DBFS, -16DB is only about 15% of the potential power available before the audio reaches 0DB, and clips. Perhaps when -16DBFS is put out over the pstn, it is much closer to clipping than it would be in an entirely digital domain. I don't know enough to make that determination. Do you know? I'm not for clipping and distortion. However, too little power can cause another problem: limited dynamic range and increased dithering artifacts. If audio is quiet on a pstn phone, then the person with the phone might be able to increase the level by turning up the phone's volume, if it has one. However, that raises the noise floor. Companding might make 8-bit channels sound a bit like 14-bit or 15-bit channels in terms of a low noise floor and decreased dithering artifacts, but it is still just an 8-bit channel. Companding hides most of the dithering artifacts in strong signals, but it magnifies them in weak signals. That's why G711 is fairly clear, but will sound scratchy if you put faint signals in to it and try to amplify them back up to normal levels. Over G711 or any pstn call, as you decrease the level of the audio going across, the scratchy dithering static obscures an increasing amount of the audio. This gets worse if you compound it by stacking codecs. Consider if someone calls your IVR from a cell phone, and you play quiet prompts to them. The audio is first passed through G711, where the low gain means that scratchy dithering artifacts are added. Then, it is encoded to GSM for the cell phone,. GSM uses linear predictive coding, and, being tuned for voice, it is not optimized for having smooth waveforms interrupted periodically with random excursions. Thats part of why cell phone calls sound so bad if there is lots of background noise. Anyway, clipping is to be avoided, but simply reducing levels dramatically creates other quality problems on a channel that uses companding. You trade distorted audio for scratchy audio. Same thing happened with cassette tapes that used Dolby noise reduction. Maybe you can help clear up my understanding of how DBFS in a digital file will work out in DBm0 on a pstn line. As things stand, though, I think we have lots of room to increase the level of the prompts before we reach a point where clipping is an issue. Bryan On Jun 27, 2011, at 9:31 PM, Steve Underwood wrote:
On 06/28/2011 04:00 AM, Bryan Smart wrote:
I don't want to maximize peaks all the way to 0DB. I just wondered why a low level like -16DB was used. When I'd previously created prompts on Asterisk systems, I used -6DB as a peak (50% of max gain for the channel). The peaks of voice are general something like 12 to 13dB above the short term RMS value. If the -16dB value you quoted is -16dBOv, its 13dB below clipping. Your peaks should be close to clipping at -16dB. I wasn't aware of any regulations about prompt level. If there is a standardized level, that is what I'd like to use. Perhaps the louder systems are disregarding standards? Does anyone have links to such info? I've been unable to find anything definitive, only opinions. In many places the regulation says the power on a PSTN line should not exceed -13dBm0. That's why -13dBm0 is the target power level for most PSTN modems. Listen to TellMe (+1-800-555-8355). It's at least 3X the gain of the default FS prompts. Is TellMe in error? I've called them through both FS and Asterisk, using Vitelity and Callcentric, so I'm fairly sure that I'm not being mislead by a switch or ITSP boosting the gain. I always felt their level was strong and intelligible, without sounding overwhelming. Not everyone bothers to obey regulations these days, and many people do love to blast sound into an overloaded highly distorted mess, because volume is king. Its not good for clarity, though. What the loudest people do is no measure of good engineering. Sadly, this behaviour might make people set their levels around the excessively loud signals, so a properly adjusted signal sounds too quiet. In the early days of my FAX modem work I received many recordings from people who could not get reliable results, where the audio was perpetually in clipping, and any speech through the channel would have sounded awful. They would generally insist that voice was "perfect" on their system. There is a serious lack of engineering in most VoIP work. One point that caught my attention, though, is that you said -16DB for both average and peak power. Average and peak power don't come out the same, though.
So that we can talk about something concrete, consider conference/32000/conf-enter_conf_pin.wav. Its peak power is -15.7DB. However, its average power (RMS) is -31.3DB! -31DB is profoundly quiet. If its average power is boosted to -16DB, then the peak power is now around -2DB. As long as peak power is less than 0DB, then the audio won't clip, but it might be too loud for comfort. I previously used -6DB for a peak, as I couldn't find any real guidelines regarding levels, and -6 sounded good to me. You still haven't said whether you are talking dBm0 or dBOv. It makes a 6dB difference. Also, what do you mean by peak power? If the peaks of the short term RMS power are hitting 0dB, the peaks of the waveform will be far into clipping. If you are talking about dBOv, then -6dB is only 3dB from the onset of clipping, and voice will clip a lot. If you are talking dBm0, -6dB is 9dB from clipping, and the voice will only clip a bit, and maybe not sound too bad. However, clipped voice tends to pass through low bit rate codecs worse than clean voice, so you might want to keep the clipping down to a really occasional event. Voice codecs have at least 12 bits of dynamic range. They are designed to allow a voice to bubble along at -30dB with good quality, and burst up to a much higher level in the loud bits. Maybe FS is lower than it should be. Maybe other services are louder than they should be. If FS should be louder, though, I'd like to help to change the levels up-stream, rather than locally reprocessing the prompts.
So, is this a personal judgement case, or are their standards available that can be consulted?
Bryan
On Jun 27, 2011, at 9:48 AM, Steve Underwood wrote:
On 06/27/2011 07:11 AM, Bryan Smart wrote:
I have tools to batch-process audio files. I just was not sure that regaining all of the prompt files was the best approach. I figured that the gain must have been reduced so dramatically for some sort of reason (to avoid clipping in some situation, to work better with the internal resampling, etc).
What AGC do you mean? I know that AGC has recently been added to conferencing, but the level of the prompts is a system-wide situation. As far as I know, there isn't AGC that can be applied on every channel, and, even if there was, there would surely be a processing hit, so the goal would be to avoid needing it, right?
The root problem, at least for me, is this. I need to add voice prompts and other audio for an IVR. I can't simply normalize all of my prompts to 0DB, as, even though they don't distort, they're so loud when compared to the stock prompts, they'll blow the phone out of my hand. To match them to the stock prompts, I must normalize them to around -16DB. I can do that, but it seems very wrong. At -16DB, nearly 85% of the potential gain of the channel is lost. -16dBM0 or -16dBOv, and average or peak burst power? -16dBOv for the average power is about where you want a voice prompt to be. In some juristictions you could be in breach of a regulation or two if you set the level higher than that on the PSTN. Why would you set a voice prompt to 0dB? It will be clipping like crazy. Try this... With the demo IVR (5000), add this before the sleep command in the dialplan.
<action application="set_audio_level" data="write 4"/>
That is the max gain boost available for a channel. The prompts should be really clipping with that much amplification, but they don't clip at all. At -16DB, you could literally amplify them to 6 times their native level without distorting. Native level is too low. Once I realized this, it became clear to me why Freeswitch sounded more quiet than Asterisk, at least when working with recorded prompts.
I suppose I could use set_audio_level on every last call, but I'm sure that real-time amplification, like AGC, is another processor drain that builds up with lots of calls. Besides, it seems weird to dramatically reduce the level of audio, and then waste cycles amplifying it back up in real-time.
Bryan Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 06/28/2011 11:04 AM, Bryan Smart wrote:
I think that dBm0 only applies if we are measuring the power on an analog circuit, or at the d/a point of a digital circuit. Nope. I was performing analysis of a digitally encoded audio file, therefore the measurement is dBFS, and 0DBFS is the point where clipping takes place. Anything below 0DBFS does not clip, even though it might seem loud to someone. What is your notion if dBFS? There are two - one where 0dBFS is a sine wave touching the limits of the number range, and the other where 0dBFS is a square wave touching those limits. They are only 3dB apart, but dbOv and dBm0 are better defined scales.
Your notion is 0dBFS not clipping is based on a sine wave. For speech you need something lower because of the statistics of speech.
I stated that the peak power of the stock prompts are typically -15 to -16 (DBFS), and the short term RMS power is about -32DBFS. That statement doesn't seem to make much sense. I don't know how to properly evaluate how DBFS will convert to DBm0. I gather that the codec and the d/a converter attenuate the level to some extent, but I don't know how much. If I have a digital file with a 1Khz test tone at -10DBFS, and play that over the pstn, what do I get out in DBm0? A sine wave touching the limits of the digital range is about +3.14dBm0. Speaking just in terms of DBFS, -16DB is only about 15% of the potential power available before the audio reaches 0DB, and clips. Perhaps when -16DBFS is put out over the pstn, it is much closer to clipping than it would be in an entirely digital domain. I don't know enough to make that determination. Do you know? Yes, and you should know, since I told you last time. I'm not for clipping and distortion. However, too little power can cause another problem: limited dynamic range and increased dithering artifacts. If audio is quiet on a pstn phone, then the person with the phone might be able to increase the level by turning up the phone's volume, if it has one. However, that raises the noise floor. Companding might make 8-bit channels sound a bit like 14-bit or 15-bit channels in terms of a low noise floor and decreased dithering artifacts, but it is still just an 8-bit channel. Companding hides most of the dithering artifacts in strong signals, but it magnifies them in weak signals. That's why G711 is fairly clear, but will sound scratchy if you put faint signals in to it and try to amplify them back up to normal levels. Over G711 or any pstn call, as you decrease the level of the audio going across, the scratchy dithering static obscures an increasing amount of the audio. That paragraph is utter drivel. The companding of G.711 ensures that the audio quality is roughly maintained from clipping down to -45dBm0 or so. Below that the quality falls, just like most other digital coding scheme running out of bits. The FS prompts aren't nearly that quiet. This gets worse if you compound it by stacking codecs. Consider if someone calls your IVR from a cell phone, and you play quiet prompts to them. The audio is first passed through G711, where the low gain means that scratchy dithering artifacts are added. Then, it is encoded to GSM for the cell phone,. GSM uses linear predictive coding, and, being tuned for voice, it is not optimized for having smooth waveforms interrupted periodically with random excursions. Thats part of why cell phone calls sound so bad if there is lots of background noise. Again, this is drivel. Anyway, clipping is to be avoided, but simply reducing levels dramatically creates other quality problems on a channel that uses companding. You trade distorted audio for scratchy audio. Same thing happened with cassette tapes that used Dolby noise reduction. You really are just making this up as you go along, aren't you. Maybe you can help clear up my understanding of how DBFS in a digital file will work out in DBm0 on a pstn line. As things stand, though, I think we have lots of room to increase the level of the prompts before we reach a point where clipping is an issue. I tried playing with a few of the prompts. The peaks of the words are about -20dBm0, or -26dBOv. That's probably -23 or -26 on your scale. Every word peaks to a similar level, as prompts are spoken in a pretty flat voice. They seem to be about 15dB away clipping, which would mean the crest factor is about 11dB for the Callie voice, which seems a little low for speech. You usually need to ride a little more than 13dB above the short term power of most voices to bring the crossing rate close to zero.
So, there is about 15dB of headroom which could be used to increase the speech level without clipping. Whether doing that is a good idea is questionable. The prompts are at about normal speech level. In normal speech the codecs have plenty of headroom to cope with people getting agitated and shouting, producing only modest amounts of clipping. Is cranking all the prompts up to shouting level appropriate? Steve
I must be wrong about DBm0, then. I wasn't familiar with it, so I checked Wikipedia. Wikipedia isn't always right, of course. Wikipedia says... ---------- dBm0 is an abbreviation for the power in dBm measured at a zero transmission level point. dBm0 is a concept used (amongst other areas) in audio/telephony processing since it allows a smooth integration of analog and digital chains. Notably, for A-law and μ-law codecs the standards define a sequence which has a 0 dBm0 output. ...... Note 2: 0 dBm0 is often replaced by or used instead of digital milliwatt or zero transmission level point. ---------- Where is my zero level transmission point? Data from a codec is not power being transmitted, only data for reproducing power at some later time. Isn't it all up to the D/A converter at the far end to determine what the power levels yielded by decoding the data will be represented relative to. If it is a hardware SIP phone, maybe the person has the volume cranked up, or turned down. Since the analog representation of the signal starts in the D/A that feeds the handset, what is considered 0? I have no idea. It sounds like this is a scale used for calibrating a D/A that feeds a pstn circuit. I admit feeling frustrated by this discussion. I've mixed music and mastered CDs for nearly 15 years, and I've always felt that 0DB in an entirely digital domain is a near universally understood concept. If I have a sample of 16-bit signed LPCM audio, then -32768 or 32767 represent the max amplitude that can be stored, and is what everyone that I know in pro audio calls 0DB when speaking strictly about a file, rather than a PA, in/out levels to an analog device like a tape machine, etc. If the gain of the encoded signal is boosted to a point where none of the samples are pushed beyond this range, then none of them clip. I thought that you'd think of DB in the same way, given we were talking about levels in files, but it feels like you're nit-picking or antagonizing me. It sounds like you're telling me that they can clip, even if the gain was never increased to a point where this range would be overflowed, but I have no idea how that is possible. It does not happen when I play such audio through the D/A on a computer's sound card, nor when I store it on a CD and play it back through a stereo. I take your point about headroom. Still, I don't feel that the current level matches caller speech. If I felt that the prompts blended well, I wouldn't have even put myself through this thread. I've connected a mix of hardware SIP phones, desktop SIP clients, and iOS SIP clients to a conference, with no modifications to the audio level of the channel, and the level of people speaking to each other in the conference is significantly louder than any prompts that are played through it. Maybe *all* of the clients are pushing audio too strongly. I first thought it was something to do with the conference, but I soon realized that the prompts were quiet everywhere, not just when played in a conference. I don't expect anything to change due to my personal preference, and I realize that a background in digital audio as applies to music and live recording doesn't mean that I'm not ignorant about many things that involve digital audio as it applies to telephony. I raised the issue here to see if I might be doing something wrong. If not, I wondered if the prompt levels are set based on some sort of standard by people that are wiser regarding the details than me? It seems, though, that there really isn't a standard, and the decision is someone else's personal preference. I'd rather that personal preferences never be a default. Since there isn't an official standard/guideline, I suppose that someone has to make a decision, and that decision will be influenced by their own preferences. I have a few suggestions to help improve Michael's sox script, but that's where I'll leave this issue. It isn't worth a big argument when I can fix it myself. I apologize to the list for any smoke, hints of flames, or other frustration that might have leaked through in to my posts. The sound level thing matters to me, but it is really a small thing. I enjoy Freeswitch immensely, and really appreciate everyones' efforts in producing and updating it. I've always been fascinated with phones and any type of interactive phone app, and so Asterisk, and now Freeswitch, really spark my imagination. I'm 34, and the study of phones in my early teens was my first conceptual exposure to a large network. I phreaked a bit at the time. I was fortunate (at least in one regard) to live in the US deep south, where digital switching equipment wasn't common, and so all of the old 1970's techniques weren't unavailable. That didn't last long, but it peaked my curiosity. I used VXML for a project for an employer in 2002 or so, but didn't really feel any excitement about phones, in the way that I used to, until I ran across Asterisk. Asterisk was great for the time, but I wanted to use it more for apps than a PBX, and so was quite excited to discover the different design of Freeswitch. I rarely become excited about new environments and frameworks anymore, but Freeswitch has put me back in to a fun mood of exploration and experimentation. Bryan On Jun 28, 2011, at 11:58 AM, Steve Underwood wrote:
On 06/28/2011 11:04 AM, Bryan Smart wrote:
I think that dBm0 only applies if we are measuring the power on an analog circuit, or at the d/a point of a digital circuit. Nope. I was performing analysis of a digitally encoded audio file, therefore the measurement is dBFS, and 0DBFS is the point where clipping takes place. Anything below 0DBFS does not clip, even though it might seem loud to someone. What is your notion if dBFS? There are two - one where 0dBFS is a sine wave touching the limits of the number range, and the other where 0dBFS is a square wave touching those limits. They are only 3dB apart, but dbOv and dBm0 are better defined scales.
Your notion is 0dBFS not clipping is based on a sine wave. For speech you need something lower because of the statistics of speech.
I stated that the peak power of the stock prompts are typically -15 to -16 (DBFS), and the short term RMS power is about -32DBFS. That statement doesn't seem to make much sense. I don't know how to properly evaluate how DBFS will convert to DBm0. I gather that the codec and the d/a converter attenuate the level to some extent, but I don't know how much. If I have a digital file with a 1Khz test tone at -10DBFS, and play that over the pstn, what do I get out in DBm0? A sine wave touching the limits of the digital range is about +3.14dBm0. Speaking just in terms of DBFS, -16DB is only about 15% of the potential power available before the audio reaches 0DB, and clips. Perhaps when -16DBFS is put out over the pstn, it is much closer to clipping than it would be in an entirely digital domain. I don't know enough to make that determination. Do you know? Yes, and you should know, since I told you last time. I'm not for clipping and distortion. However, too little power can cause another problem: limited dynamic range and increased dithering artifacts. If audio is quiet on a pstn phone, then the person with the phone might be able to increase the level by turning up the phone's volume, if it has one. However, that raises the noise floor. Companding might make 8-bit channels sound a bit like 14-bit or 15-bit channels in terms of a low noise floor and decreased dithering artifacts, but it is still just an 8-bit channel. Companding hides most of the dithering artifacts in strong signals, but it magnifies them in weak signals. That's why G711 is fairly clear, but will sound scratchy if you put faint signals in to it and try to amplify them back up to normal levels. Over G711 or any pstn call, as you decrease the level of the audio going across, the scratchy dithering static obscures an increasing amount of the audio. That paragraph is utter drivel. The companding of G.711 ensures that the audio quality is roughly maintained from clipping down to -45dBm0 or so. Below that the quality falls, just like most other digital coding scheme running out of bits. The FS prompts aren't nearly that quiet. This gets worse if you compound it by stacking codecs. Consider if someone calls your IVR from a cell phone, and you play quiet prompts to them. The audio is first passed through G711, where the low gain means that scratchy dithering artifacts are added. Then, it is encoded to GSM for the cell phone,. GSM uses linear predictive coding, and, being tuned for voice, it is not optimized for having smooth waveforms interrupted periodically with random excursions. Thats part of why cell phone calls sound so bad if there is lots of background noise. Again, this is drivel. Anyway, clipping is to be avoided, but simply reducing levels dramatically creates other quality problems on a channel that uses companding. You trade distorted audio for scratchy audio. Same thing happened with cassette tapes that used Dolby noise reduction. You really are just making this up as you go along, aren't you. Maybe you can help clear up my understanding of how DBFS in a digital file will work out in DBm0 on a pstn line. As things stand, though, I think we have lots of room to increase the level of the prompts before we reach a point where clipping is an issue. I tried playing with a few of the prompts. The peaks of the words are about -20dBm0, or -26dBOv. That's probably -23 or -26 on your scale. Every word peaks to a similar level, as prompts are spoken in a pretty flat voice. They seem to be about 15dB away clipping, which would mean the crest factor is about 11dB for the Callie voice, which seems a little low for speech. You usually need to ride a little more than 13dB above the short term power of most voices to bring the crossing rate close to zero.
So, there is about 15dB of headroom which could be used to increase the speech level without clipping. Whether doing that is a good idea is questionable. The prompts are at about normal speech level. In normal speech the codecs have plenty of headroom to cope with people getting agitated and shouting, producing only modest amounts of clipping. Is cranking all the prompts up to shouting level appropriate?
Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I don't think anyone is thinking of your post as flames. Like I said, check out the original 48k files and see what the levels are vs what sox does to them. I am not adverse to changing it as long as the majority of people agree. Steve is very pragmatic when it comes to DSP. I often make a fool of myself trying to find the right words to explain myself. I don't believe he in any way is attempting to deter your efforts he just is a stickler for proper terminology and factual info. On Tue, Jun 28, 2011 at 2:26 PM, Bryan Smart <bryansmart@bryansmart.com> wrote:
I must be wrong about DBm0, then. I wasn't familiar with it, so I checked Wikipedia. Wikipedia isn't always right, of course.
Wikipedia says... ---------- dBm0 is an abbreviation for the power in dBm measured at a zero transmission level point.
dBm0 is a concept used (amongst other areas) in audio/telephony processing since it allows a smooth integration of analog and digital chains. Notably, for A-law and μ-law codecs the standards define a sequence which has a 0 dBm0 output.
......
Note 2: 0 dBm0 is often replaced by or used instead of digital milliwatt or zero transmission level point. ----------
Where is my zero level transmission point? Data from a codec is not power being transmitted, only data for reproducing power at some later time. Isn't it all up to the D/A converter at the far end to determine what the power levels yielded by decoding the data will be represented relative to. If it is a hardware SIP phone, maybe the person has the volume cranked up, or turned down. Since the analog representation of the signal starts in the D/A that feeds the handset, what is considered 0? I have no idea. It sounds like this is a scale used for calibrating a D/A that feeds a pstn circuit.
I admit feeling frustrated by this discussion. I've mixed music and mastered CDs for nearly 15 years, and I've always felt that 0DB in an entirely digital domain is a near universally understood concept. If I have a sample of 16-bit signed LPCM audio, then -32768 or 32767 represent the max amplitude that can be stored, and is what everyone that I know in pro audio calls 0DB when speaking strictly about a file, rather than a PA, in/out levels to an analog device like a tape machine, etc. If the gain of the encoded signal is boosted to a point where none of the samples are pushed beyond this range, then none of them clip. I thought that you'd think of DB in the same way, given we were talking about levels in files, but it feels like you're nit-picking or antagonizing me. It sounds like you're telling me that they can clip, even if the gain was never increased to a point where this range would be overflowed, but I have no idea how that is possible. It does not happen when I play such audio through the D/A on a computer's sound card, nor when I store it on a CD and play it back through a stereo.
I take your point about headroom. Still, I don't feel that the current level matches caller speech. If I felt that the prompts blended well, I wouldn't have even put myself through this thread. I've connected a mix of hardware SIP phones, desktop SIP clients, and iOS SIP clients to a conference, with no modifications to the audio level of the channel, and the level of people speaking to each other in the conference is significantly louder than any prompts that are played through it. Maybe *all* of the clients are pushing audio too strongly. I first thought it was something to do with the conference, but I soon realized that the prompts were quiet everywhere, not just when played in a conference.
I don't expect anything to change due to my personal preference, and I realize that a background in digital audio as applies to music and live recording doesn't mean that I'm not ignorant about many things that involve digital audio as it applies to telephony. I raised the issue here to see if I might be doing something wrong. If not, I wondered if the prompt levels are set based on some sort of standard by people that are wiser regarding the details than me? It seems, though, that there really isn't a standard, and the decision is someone else's personal preference. I'd rather that personal preferences never be a default. Since there isn't an official standard/guideline, I suppose that someone has to make a decision, and that decision will be influenced by their own preferences.
I have a few suggestions to help improve Michael's sox script, but that's where I'll leave this issue. It isn't worth a big argument when I can fix it myself.
I apologize to the list for any smoke, hints of flames, or other frustration that might have leaked through in to my posts. The sound level thing matters to me, but it is really a small thing. I enjoy Freeswitch immensely, and really appreciate everyones' efforts in producing and updating it. I've always been fascinated with phones and any type of interactive phone app, and so Asterisk, and now Freeswitch, really spark my imagination. I'm 34, and the study of phones in my early teens was my first conceptual exposure to a large network. I phreaked a bit at the time. I was fortunate (at least in one regard) to live in the US deep south, where digital switching equipment wasn't common, and so all of the old 1970's techniques weren't unavailable. That didn't last long, but it peaked my curiosity. I used VXML for a project for an employer in 2002 or so, but didn't really feel any excitement about phones, in the way that I used to, until I ran across Asterisk. Asterisk was great for the time, but I wanted to use it more for apps than a PBX, and so was quite excited to discover the different design of Freeswitch. I rarely become excited about new environments and frameworks anymore, but Freeswitch has put me back in to a fun mood of exploration and experimentation.
Bryan
On Jun 28, 2011, at 11:58 AM, Steve Underwood wrote:
On 06/28/2011 11:04 AM, Bryan Smart wrote:
I think that dBm0 only applies if we are measuring the power on an analog circuit, or at the d/a point of a digital circuit. Nope. I was performing analysis of a digitally encoded audio file, therefore the measurement is dBFS, and 0DBFS is the point where clipping takes place. Anything below 0DBFS does not clip, even though it might seem loud to someone. What is your notion if dBFS? There are two - one where 0dBFS is a sine wave touching the limits of the number range, and the other where 0dBFS is a square wave touching those limits. They are only 3dB apart, but dbOv and dBm0 are better defined scales.
Your notion is 0dBFS not clipping is based on a sine wave. For speech you need something lower because of the statistics of speech.
I stated that the peak power of the stock prompts are typically -15 to -16 (DBFS), and the short term RMS power is about -32DBFS. That statement doesn't seem to make much sense. I don't know how to properly evaluate how DBFS will convert to DBm0. I gather that the codec and the d/a converter attenuate the level to some extent, but I don't know how much. If I have a digital file with a 1Khz test tone at -10DBFS, and play that over the pstn, what do I get out in DBm0? A sine wave touching the limits of the digital range is about +3.14dBm0. Speaking just in terms of DBFS, -16DB is only about 15% of the potential power available before the audio reaches 0DB, and clips. Perhaps when -16DBFS is put out over the pstn, it is much closer to clipping than it would be in an entirely digital domain. I don't know enough to make that determination. Do you know? Yes, and you should know, since I told you last time. I'm not for clipping and distortion. However, too little power can cause another problem: limited dynamic range and increased dithering artifacts. If audio is quiet on a pstn phone, then the person with the phone might be able to increase the level by turning up the phone's volume, if it has one. However, that raises the noise floor. Companding might make 8-bit channels sound a bit like 14-bit or 15-bit channels in terms of a low noise floor and decreased dithering artifacts, but it is still just an 8-bit channel. Companding hides most of the dithering artifacts in strong signals, but it magnifies them in weak signals. That's why G711 is fairly clear, but will sound scratchy if you put faint signals in to it and try to amplify them back up to normal levels. Over G711 or any pstn call, as you decrease the level of the audio going across, the scratchy dithering static obscures an increasing amount of the audio. That paragraph is utter drivel. The companding of G.711 ensures that the audio quality is roughly maintained from clipping down to -45dBm0 or so. Below that the quality falls, just like most other digital coding scheme running out of bits. The FS prompts aren't nearly that quiet. This gets worse if you compound it by stacking codecs. Consider if someone calls your IVR from a cell phone, and you play quiet prompts to them. The audio is first passed through G711, where the low gain means that scratchy dithering artifacts are added. Then, it is encoded to GSM for the cell phone,. GSM uses linear predictive coding, and, being tuned for voice, it is not optimized for having smooth waveforms interrupted periodically with random excursions. Thats part of why cell phone calls sound so bad if there is lots of background noise. Again, this is drivel. Anyway, clipping is to be avoided, but simply reducing levels dramatically creates other quality problems on a channel that uses companding. You trade distorted audio for scratchy audio. Same thing happened with cassette tapes that used Dolby noise reduction. You really are just making this up as you go along, aren't you. Maybe you can help clear up my understanding of how DBFS in a digital file will work out in DBm0 on a pstn line. As things stand, though, I think we have lots of room to increase the level of the prompts before we reach a point where clipping is an issue. I tried playing with a few of the prompts. The peaks of the words are about -20dBm0, or -26dBOv. That's probably -23 or -26 on your scale. Every word peaks to a similar level, as prompts are spoken in a pretty flat voice. They seem to be about 15dB away clipping, which would mean the crest factor is about 11dB for the Callie voice, which seems a little low for speech. You usually need to ride a little more than 13dB above the short term power of most voices to bring the crossing rate close to zero.
So, there is about 15dB of headroom which could be used to increase the speech level without clipping. Whether doing that is a good idea is questionable. The prompts are at about normal speech level. In normal speech the codecs have plenty of headroom to cope with people getting agitated and shouting, producing only modest amounts of clipping. Is cranking all the prompts up to shouting level appropriate?
Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Thanks, Anthony. I downloaded http://files.freeswitch.org/freeswitch-sounds-en-us-callie-48000-1.0.16.tar.... and http://files.freeswitch.org/freeswitch-sounds-en-us-callie-32000-1.0.16.tar.... I examined them with the statistical analysis tool in Sound Forge. Regardless of what DB scale is involved, both versions register in Sound Forge with identical max sample value and average RMS. This outcome doesn't seem possible if the 48000 set is sent through sox with "-v 0.2" to produce the other sets. Wouldn't the results of that processing be that the sets for other rates would be 20% as loud as the 48000 set? The 48000 set that I discovered must not be the correct set. By the way, the 48000 set that I downloaded also included an 8000 set. Is that expected? Bryan On Jun 28, 2011, at 4:42 PM, Anthony Minessale wrote:
I don't think anyone is thinking of your post as flames. Like I said, check out the original 48k files and see what the levels are vs what sox does to them. I am not adverse to changing it as long as the majority of people agree. Steve is very pragmatic when it comes to DSP. I often make a fool of myself trying to find the right words to explain myself. I don't believe he in any way is attempting to deter your efforts he just is a stickler for proper terminology and factual info.
On Tue, Jun 28, 2011 at 2:26 PM, Bryan Smart <bryansmart@bryansmart.com> wrote:
I must be wrong about DBm0, then. I wasn't familiar with it, so I checked Wikipedia. Wikipedia isn't always right, of course.
Wikipedia says... ---------- dBm0 is an abbreviation for the power in dBm measured at a zero transmission level point.
dBm0 is a concept used (amongst other areas) in audio/telephony processing since it allows a smooth integration of analog and digital chains. Notably, for A-law and μ-law codecs the standards define a sequence which has a 0 dBm0 output.
......
Note 2: 0 dBm0 is often replaced by or used instead of digital milliwatt or zero transmission level point. ----------
Where is my zero level transmission point? Data from a codec is not power being transmitted, only data for reproducing power at some later time. Isn't it all up to the D/A converter at the far end to determine what the power levels yielded by decoding the data will be represented relative to. If it is a hardware SIP phone, maybe the person has the volume cranked up, or turned down. Since the analog representation of the signal starts in the D/A that feeds the handset, what is considered 0? I have no idea. It sounds like this is a scale used for calibrating a D/A that feeds a pstn circuit.
I admit feeling frustrated by this discussion. I've mixed music and mastered CDs for nearly 15 years, and I've always felt that 0DB in an entirely digital domain is a near universally understood concept. If I have a sample of 16-bit signed LPCM audio, then -32768 or 32767 represent the max amplitude that can be stored, and is what everyone that I know in pro audio calls 0DB when speaking strictly about a file, rather than a PA, in/out levels to an analog device like a tape machine, etc. If the gain of the encoded signal is boosted to a point where none of the samples are pushed beyond this range, then none of them clip. I thought that you'd think of DB in the same way, given we were talking about levels in files, but it feels like you're nit-picking or antagonizing me. It sounds like you're telling me that they can clip, even if the gain was never increased to a point where this range would be overflowed, but I have no idea how that is possible. It does not happen when I play such audio through the D/A on a computer's sound card, nor when I store it on a CD and play it back through a stereo.
I take your point about headroom. Still, I don't feel that the current level matches caller speech. If I felt that the prompts blended well, I wouldn't have even put myself through this thread. I've connected a mix of hardware SIP phones, desktop SIP clients, and iOS SIP clients to a conference, with no modifications to the audio level of the channel, and the level of people speaking to each other in the conference is significantly louder than any prompts that are played through it. Maybe *all* of the clients are pushing audio too strongly. I first thought it was something to do with the conference, but I soon realized that the prompts were quiet everywhere, not just when played in a conference.
I don't expect anything to change due to my personal preference, and I realize that a background in digital audio as applies to music and live recording doesn't mean that I'm not ignorant about many things that involve digital audio as it applies to telephony. I raised the issue here to see if I might be doing something wrong. If not, I wondered if the prompt levels are set based on some sort of standard by people that are wiser regarding the details than me? It seems, though, that there really isn't a standard, and the decision is someone else's personal preference. I'd rather that personal preferences never be a default. Since there isn't an official standard/guideline, I suppose that someone has to make a decision, and that decision will be influenced by their own preferences.
I have a few suggestions to help improve Michael's sox script, but that's where I'll leave this issue. It isn't worth a big argument when I can fix it myself.
I apologize to the list for any smoke, hints of flames, or other frustration that might have leaked through in to my posts. The sound level thing matters to me, but it is really a small thing. I enjoy Freeswitch immensely, and really appreciate everyones' efforts in producing and updating it. I've always been fascinated with phones and any type of interactive phone app, and so Asterisk, and now Freeswitch, really spark my imagination. I'm 34, and the study of phones in my early teens was my first conceptual exposure to a large network. I phreaked a bit at the time. I was fortunate (at least in one regard) to live in the US deep south, where digital switching equipment wasn't common, and so all of the old 1970's techniques weren't unavailable. That didn't last long, but it peaked my curiosity. I used VXML for a project for an employer in 2002 or so, but didn't really feel any excitement about phones, in the way that I used to, until I ran across Asterisk. Asterisk was great for the time, but I wanted to use it more for apps than a PBX, and so was quite excited to discover the different design of Freeswitch. I rarely become excited about new environments and frameworks anymore, but Freeswitch has put me back in to a fun mood of exploration and experimentation.
Bryan
On Jun 28, 2011, at 11:58 AM, Steve Underwood wrote:
On 06/28/2011 11:04 AM, Bryan Smart wrote:
I think that dBm0 only applies if we are measuring the power on an analog circuit, or at the d/a point of a digital circuit. Nope. I was performing analysis of a digitally encoded audio file, therefore the measurement is dBFS, and 0DBFS is the point where clipping takes place. Anything below 0DBFS does not clip, even though it might seem loud to someone. What is your notion if dBFS? There are two - one where 0dBFS is a sine wave touching the limits of the number range, and the other where 0dBFS is a square wave touching those limits. They are only 3dB apart, but dbOv and dBm0 are better defined scales.
Your notion is 0dBFS not clipping is based on a sine wave. For speech you need something lower because of the statistics of speech.
I stated that the peak power of the stock prompts are typically -15 to -16 (DBFS), and the short term RMS power is about -32DBFS. That statement doesn't seem to make much sense. I don't know how to properly evaluate how DBFS will convert to DBm0. I gather that the codec and the d/a converter attenuate the level to some extent, but I don't know how much. If I have a digital file with a 1Khz test tone at -10DBFS, and play that over the pstn, what do I get out in DBm0? A sine wave touching the limits of the digital range is about +3.14dBm0. Speaking just in terms of DBFS, -16DB is only about 15% of the potential power available before the audio reaches 0DB, and clips. Perhaps when -16DBFS is put out over the pstn, it is much closer to clipping than it would be in an entirely digital domain. I don't know enough to make that determination. Do you know? Yes, and you should know, since I told you last time. I'm not for clipping and distortion. However, too little power can cause another problem: limited dynamic range and increased dithering artifacts. If audio is quiet on a pstn phone, then the person with the phone might be able to increase the level by turning up the phone's volume, if it has one. However, that raises the noise floor. Companding might make 8-bit channels sound a bit like 14-bit or 15-bit channels in terms of a low noise floor and decreased dithering artifacts, but it is still just an 8-bit channel. Companding hides most of the dithering artifacts in strong signals, but it magnifies them in weak signals. That's why G711 is fairly clear, but will sound scratchy if you put faint signals in to it and try to amplify them back up to normal levels. Over G711 or any pstn call, as you decrease the level of the audio going across, the scratchy dithering static obscures an increasing amount of the audio. That paragraph is utter drivel. The companding of G.711 ensures that the audio quality is roughly maintained from clipping down to -45dBm0 or so. Below that the quality falls, just like most other digital coding scheme running out of bits. The FS prompts aren't nearly that quiet. This gets worse if you compound it by stacking codecs. Consider if someone calls your IVR from a cell phone, and you play quiet prompts to them. The audio is first passed through G711, where the low gain means that scratchy dithering artifacts are added. Then, it is encoded to GSM for the cell phone,. GSM uses linear predictive coding, and, being tuned for voice, it is not optimized for having smooth waveforms interrupted periodically with random excursions. Thats part of why cell phone calls sound so bad if there is lots of background noise. Again, this is drivel. Anyway, clipping is to be avoided, but simply reducing levels dramatically creates other quality problems on a channel that uses companding. You trade distorted audio for scratchy audio. Same thing happened with cassette tapes that used Dolby noise reduction. You really are just making this up as you go along, aren't you. Maybe you can help clear up my understanding of how DBFS in a digital file will work out in DBm0 on a pstn line. As things stand, though, I think we have lots of room to increase the level of the prompts before we reach a point where clipping is an issue. I tried playing with a few of the prompts. The peaks of the words are about -20dBm0, or -26dBOv. That's probably -23 or -26 on your scale. Every word peaks to a similar level, as prompts are spoken in a pretty flat voice. They seem to be about 15dB away clipping, which would mean the crest factor is about 11dB for the Callie voice, which seems a little low for speech. You usually need to ride a little more than 13dB above the short term power of most voices to bring the crossing rate close to zero.
So, there is about 15dB of headroom which could be used to increase the speech level without clipping. Whether doing that is a good idea is questionable. The prompts are at about normal speech level. In normal speech the codecs have plenty of headroom to cope with people getting agitated and shouting, producing only modest amounts of clipping. Is cranking all the prompts up to shouting level appropriate?
Steve
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_______________________________________________ Join us at ClueCon 2011, Aug 9-11, Chicago http://www.cluecon.com 877-7-4ACLUE
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On Tue, Jun 28, 2011 at 5:47 PM, Bryan Smart <bryansmart@bryansmart.com>wrote:
Thanks, Anthony.
I downloaded
http://files.freeswitch.org/freeswitch-sounds-en-us-callie-48000-1.0.16.tar....
and
http://files.freeswitch.org/freeswitch-sounds-en-us-callie-32000-1.0.16.tar....
I examined them with the statistical analysis tool in Sound Forge. Regardless of what DB scale is involved, both versions register in Sound Forge with identical max sample value and average RMS. This outcome doesn't seem possible if the 48000 set is sent through sox with "-v 0.2" to produce the other sets. Wouldn't the results of that processing be that the sets for other rates would be 20% as loud as the 48000 set?
The 48000 set that I discovered must not be the correct set.
I'll email you offlist and see if I can't get you read-only access to our sounds repo so you can see the raw files. -MC
On 06/29/2011 03:26 AM, Bryan Smart wrote:
I must be wrong about DBm0, then. I wasn't familiar with it, so I checked Wikipedia. Wikipedia isn't always right, of course.
Wikipedia says... ---------- dBm0 is an abbreviation for the power in dBm measured at a zero transmission level point.
dBm0 is a concept used (amongst other areas) in audio/telephony processing since it allows a smooth integration of analog and digital chains. Notably, for A-law and μ-law codecs the standards define a sequence which has a 0 dBm0 output.
......
Note 2: 0 dBm0 is often replaced by or used instead of digital milliwatt or zero transmission level point. ----------
Where is my zero level transmission point? Data from a codec is not power being transmitted, only data for reproducing power at some later time. Isn't it all up to the D/A converter at the far end to determine what the power levels yielded by decoding the data will be represented relative to. If it is a hardware SIP phone, maybe the person has the volume cranked up, or turned down. Since the analog representation of the signal starts in the D/A that feeds the handset, what is considered 0? I have no idea. It sounds like this is a scale used for calibrating a D/A that feeds a pstn circuit. Look in the G.711 spec. It defines a specific digital signal that is 0dBm0 for both u-law and A-law. I admit feeling frustrated by this discussion. I've mixed music and mastered CDs for nearly 15 years, and I've always felt that 0DB in an entirely digital domain is a near universally understood concept. If I have a sample of 16-bit signed LPCM audio, then -32768 or 32767 represent the max amplitude that can be stored, and is what everyone that I know in pro audio calls 0DB when speaking strictly about a file, rather than a PA, in/out levels to an analog device like a tape machine, etc. If the gain of the encoded signal is boosted to a point where none of the samples are pushed beyond this range, then none of them clip. I thought that you'd think of DB in the same way, given we were talking about levels in files, but it feels like you're nit-picking or antagonizing me. It sounds like you're telling me that they can clip, even if the gain was never increased to a point where this range would be overflowed, but I have no idea how that is possible. It does not happen when I play such audio through the D/A on a computer's sound card, nor when I store it on a CD and play it back through a stereo. This is highly inaccurate. Power is usually measured as an RMS value, and this does not relate directly to the height of the samples. It related to the integral of the samples over time. As I said before, the crest factor (basically the ratio between peak instantaneous power and RMS power) is about 13dB for speech. Its about the same for a voice singing. Its lower for most musical instruments. Nonetheless every musical signal has some peakiness, and 0dBOv RMS power will certainly clip badly. You might be refering the the measurements on PPM or other forms of metering which try to track the audio peaks. If those are working well, you can run up to 0dB on their scale before clipping. The RMS power will be considerably lower, though. Recording desks use peak power meters specifically because RMS power doesn't give you much idea about how close to clipping you are. I take your point about headroom. Still, I don't feel that the current level matches caller speech. If I felt that the prompts blended well, I wouldn't have even put myself through this thread. I've connected a mix of hardware SIP phones, desktop SIP clients, and iOS SIP clients to a conference, with no modifications to the audio level of the channel, and the level of people speaking to each other in the conference is significantly louder than any prompts that are played through it. Maybe *all* of the clients are pushing audio too strongly. I first thought it was something to do with the conference, but I soon realized that the prompts were quiet everywhere, not just when played in a conference. Gains in the PSTN are largely controlled in a professional manner. On the internet its currently chaos, with many voice signal clipping horribly. Instead of a well balanced set of gains down the signal chain you get people pumping up the gain at one point, the massively attenuating it at another, with no regard for the distortion they are introducing. I don't expect anything to change due to my personal preference, and I realize that a background in digital audio as applies to music and live recording doesn't mean that I'm not ignorant about many things that involve digital audio as it applies to telephony. I raised the issue here to see if I might be doing something wrong. If not, I wondered if the prompt levels are set based on some sort of standard by people that are wiser regarding the details than me? It seems, though, that there really isn't a standard, and the decision is someone else's personal preference. I'd rather that personal preferences never be a default. Since there isn't an official standard/guideline, I suppose that someone has to make a decision, and that decision will be influenced by their own preferences. Preferences shouldn't be a factor. This is supposed to be engineered. I have a few suggestions to help improve Michael's sox script, but that's where I'll leave this issue. It isn't worth a big argument when I can fix it myself.
I apologize to the list for any smoke, hints of flames, or other frustration that might have leaked through in to my posts. The sound level thing matters to me, but it is really a small thing. I enjoy Freeswitch immensely, and really appreciate everyones' efforts in producing and updating it. I've always been fascinated with phones and any type of interactive phone app, and so Asterisk, and now Freeswitch, really spark my imagination. I'm 34, and the study of phones in my early teens was my first conceptual exposure to a large network. I phreaked a bit at the time. I was fortunate (at least in one regard) to live in the US deep south, where digital switching equipment wasn't common, and so all of the old 1970's techniques weren't unavailable. That didn't last long, but it peaked my curiosity. I used VXML for a project for an employer in 2002 or so, but didn't really feel any excitement about phones, in the way that I used to, until I ran across Asterisk. Asterisk was great for the time, but I wanted to use it more for apps than a PBX, and so was quite excited to discover the different design of Freeswitch. I rarely become excited about new environments and frameworks anymore, but Freeswitch has put me back in to a fun mood of exploration and experimentation. There is nothing wrong with what you are doing. Its good to see someone care about gains.
Steve
participants (8)
-
Anthony Minessale
-
Bryan Smart
-
Jan Berger
-
Michael Collins
-
Nandy Dagondon
-
Sidharth Kshatriya
-
Steve Underwood
-
Thomas Hoellriegel