[arm-allstar] arm-allstar Digest, Vol 21, Issue 8

[Ken]

>>>   1. File extensions and audio format (Chris Zenchenko)

GSM works with 13 bits of audio as input.  The 8 bits refers to the encoded
format.
8-bit uLaw produces about 14 bits in the linear domain.
To make 16-bit WAV (pcm) format files compatible with the other two, they
should have a maximum level of -6 dBfs.
This is mentioned in a white paper on making  your own recordings found
here:
http://images.ohnosec.org/app-rpt-audacity.pdf

One trick not mentioned is that you should limit the frequency response to
3300 Hz max before setting the levels - or the level may be based on
frequency components that will never be reproduced when the recoding is
saved as 8kHz uLaw (and the level will be too low).  Filtering out the
frequencies down in the PL-tone range is a good idea too, as the radios you
will be heard on will filter that out themselves (again causing the bit you
do hear, to be too low).  Lastly - if you set the levels with Audacity or
similar program, it will normalize the audio level based on the ONE loudest
sound (or cycle) in the entire recording.  So you probably want to use the
hard limiter function to shave off the few spikes that may be there, before
doing the level setting.

The Asterisk limiter (assuming it is enabled) will prevent the signal from
over deviating on a properly set up system, but you really don't want  your
audio running up against the limiter, or it will sound too loud relative to
everything else.  

If a recording is going to be played in the middle of a QSO you probably
want it at about -9 dBfs when you are working with it as a WAV file.

73
Ken
KE2N

----------------------------------------------------------------------

Message: 1
Date: Thu, 11 Feb 2016 10:54:19 -0600
From: "Chris Zenchenko" <wb9rsq at gmail.com>
To: <arm-allstar at hamvoip.org>
Subject: [arm-allstar] File extensions and audio format
Message-ID: <004201d164ec$da32d940$8e988bc0$@gmail.com>
Content-Type: text/plain; charset="us-ascii"

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/b4b29f7
d/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
arm-allstar mailing list
arm-allstar at hamvoip.org
http://lists.hamvoip.org/cgi-bin/mailman/listinfo/arm-allstar


------------------------------

End of arm-allstar Digest, Vol 21, Issue 8
******************************************