[arm-allstar] File extensions and audio format

Chris Zenchenko wb9rsq at gmail.com
Thu Feb 11 11:54:19 EST 2016


I know there have been threads on both of these topics but I'm not sure I
understand the final advice or the driving policy behind current practice.

First the 1.2.1 image has lots of different script files.
Some are .pl and others are .sh.
There are even a few .py.
I know what they are but there are also lots of files that are BASH scripts
but don't have a .sh extension.
Why in some cases do they have extensions and in others they don't?
Should they all have extensions?

Next the old audio thing again.
The asterisk sounds folder seems to have .gsm at 8khz 8 bit sampling.
Comments in several .sh files indicate that in order to use CAT you need to
have all files formatted the same.
That is obvious but no harm in pointing it out.
However the files for the shutdown and reboot scripts are 8khz 16 bit wave
files.
They play just fine through the radio nodes.
In fact I've heard 11025 16 bit audio play fine as well.
Yes I can hear the difference in audio quality even over the radio between 8
and 16 bit.
More so with higher sampling rates.
So for some questions.

Where is the 8khz 8 bit limit coming from?
Is it really a limit or just best practice?
Forgetting the space issue is there any reason not to use a 16 bit 8khz or
even slightly higher format?
Would ulaw or even wav be a better option for audio under local control?

The saytime script has a line to adjust the volume of the final audio
output.
The comment basically reads that negative numbers are lower and to see the
sox man page for details.
The script had 1.35 as the value.
Changing it to -1.35 resulted in audio distorted and to loud to be useful at
all.
Going above 2.0 seemed to be an upper limit.
Finally 0.0 resulted in silence.
So I came to the conclusion that 0.0 to 2.0 was the effective working range
of options.
Is this some kind of multiplying factor based on original audio level?
I typically normalize audio to peak -1.5DB.
I do that before placing audio in the sound libraries.
Would it be better to just normalize to something lower to keep audio in
line with other sources of TX audio?
For audio outside my control would it be better to use a sox process to
normalize to the rest of my library?
What about just using sox to always normalize anything going out or is the
volume change method in the script the best approach?

Any thoughts on these issues would be appreciated.
73


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hamvoip.org/pipermail/arm-allstar/attachments/20160211/b4b29f7d/attachment.html>


More information about the arm-allstar mailing list