Searching \ for '[OT] WAV files' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=wav+files
Search entire site for: 'WAV files'.

Exact match. Not showing close matches.
PICList Thread
'[OT] WAV files'
1999\10\16@045912 by Duilio Foschi

flavicon
face
I need to know how the sound information is stored in a WAV file and how I
can programmatically raise the volume of the sound in a WAV file.

Any hint welcome

Thank you

Duilio Foschi

1999\10\16@055222 by Brent Brown

picon face
> I need to know how the sound information is stored in a WAV file and how I
> can programmatically raise the volume of the sound in a WAV file.
>
> Any hint welcome
>
> Thank you
>
> Duilio Foschi
>

Not so [OT] because you can do this on a PIC.  Here's some ideas.

Assuming a simple mono 8 bit per sample recording, there is a
about 20 bytes or so of header information at the start of the file
and then the audio samples are stored as 8 bit values.  The data is
"biased" with a 7Fh DC offset so that silence is recorded as 7Fh.
Kind of like a single rail audio amplifier would be biased at half the
supply voltage.  For simple play back from a micro with a PWM
output just send each byte to the PWM register sequentially at the
original sample rate.  Put an RC filter on the output and
capacitively couple it to an audio amp.  A little rough by hey - it
works!  Even play back the header bytes, they go by so fast you
hardly hear a scratch.

Back to the subject, to digitally amplify a .wav file you would need
to do something like this for each 8 bit sample:
- Remove the offset by subtracting 7Fh for data above 7Fh or
subtracting from 7Fh for data below 7Fh
- Multiply by your amplification factor
- Put the offset back in by adding 7Fh or subtracting from 7Fh as
necessary
- Store it or play it

You are limited to what you can do in an 8 bit file before clipping.
Using 16 bit intermediate maths helps by letting you do stuff like
this: for 10% increase in volume, multiply by 11 then divide by 10.

Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
eMail:  spam_OUTbrent.brownTakeThisOuTspamclear.net.nz

1999\10\16@091352 by - KITS EDUCACIONAIS NACIONAIS

flavicon
face
Brent Brown wrote:
{Quote hidden}

tHE LAST CIRCUIT CELLAR HAS INFORMATION ABOUT SOUND REPRODUCED BY PWM...

1999\10\16@212144 by Mark Willis

flavicon
face
Brent Brown wrote:
> <snipped>
> Back to the subject, to digitally amplify a .wav file you would need
> to do something like this for each 8 bit sample:
> - Remove the offset by subtracting 7Fh for data above 7Fh or
> subtracting from 7Fh for data below 7Fh
> - Multiply by your amplification factor
> - Put the offset back in by adding 7Fh or subtracting from 7Fh as
> necessary
> - Store it or play it
>
> You are limited to what you can do in an 8 bit file before clipping.
> Using 16 bit intermediate maths helps by letting you do stuff like
> this: for 10% increase in volume, multiply by 11 then divide by 10.
>
> Brent Brown

Sound isn't linear, as perceived by the human ear, though;  We hear sort
of Logarithmically.  And you need to consider, what happens if you hit
overflow?, and handle that <G>

Really good books on Audio Accoustics are out there;  The average human
ear perceives a doubling in volume when the power has been increased by
10db, i.e. twice the actual power - so basically for a 10% increase in
*perceived* volume, you want to increase a signal's voltage by 10
TIMES.  So for a 10% increase in volume, I'd guess you actually want to
increase voltage by about 3.548 times?  (It's been a while since I did
audio engineering, and all my books are in storage due to the move.  I
like Digital lots more <G>)  So I'm possibly wrong here.

 Mark

1999\10\17@164103 by steve

flavicon
face
> Sound isn't linear, as perceived by the human ear, though;  We hear sort
> of Logarithmically.  And you need to consider, what happens if you hit
> overflow?, and handle that <G>

You're correct but you run into quantization problems long before any
of the audiophile characteristics.
I did exactly this in a promotional thing for a client. I found that
8 bits @ 11kHz was perfectly adequate for a typical busy environment
where there is a bit of background noise like a tradeshow.
I had a bit of a play with adjusting the volume digitally and since
the raw data was about as rough as I could allow, going up or down
produced perceptable distortion. I would suggest adjusting the volume
in the analog domain with either a mechanical or electronic pot. If
you want to do it digitally, make sure you have plenty of bits
available but that takes storage space.

There are quite a few WAV file tools about on the net and you can
play on your PC to get an idea of what you can and can't do.
I found the time spent editting the data, expanding it to fill the
dynamic range and filtering on the PC paid off in the amount of ROM I
was able to save.

Steve.

======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680, New Lynn      http://www.tla.co.nz
Auckland, New Zealand        ph  +64 9 820-2221
email: stevebspamKILLspamtla.co.nz      fax +64 9 820-1929
======================================================

1999\10\18@032024 by Duilio Foschi

flavicon
face
Brent,

my files are sampled at 16 bits.

How do this change things ?

Also, when does the header exactly end and data start ? (I need to take a
regular WAV file for input and output a regular WAV file to be played later).

Thank you

Duilio Foschi

At 22.44 16/10/99 +1300, you wrote:
{Quote hidden}

1999\10\18@034142 by gdaniel

flavicon
face
Duilio, why don't you open a 16 bit *.wav for random binary input and examine th
e
data ? try a silent sample and then a low frequency sine wave, the results shoul
d
be fairly apparent.

regards,
Graham Daniel.

Duilio Foschi wrote:

{Quote hidden}

1999\10\18@053840 by Brent Brown

picon face
Dulio,

Graham's idea is a good one - and that's exactly how I found out all
I needed to know about 8 bit .wav files.  You may need to find a
book on the subject to get all the details, but a little practical
investigation will go a long way.

Dulio wrote:
> Brent,
>
> my files are sampled at 16 bits.
>
> How do this change things ?
>
> Also, when does the header exactly end and data start ? (I need to
> take a regular WAV file for input and output a regular WAV file to be
> played later).

Graham wrote:
> Duilio, why don't you open a 16 bit *.wav for random binary input
> and examine the data ? try a silent sample and then a low frequency
> sine wave, the results should be fairly apparent.


Brent Brown
Electronic Design Solutions
16 English Street
Hamilton, New Zealand
Ph/fax: +64 7 849 0069
Mobile: 025 334 069
eMail:  brent.brownspamspam_OUTclear.net.nz

1999\10\18@083151 by paulb

flavicon
face
Brent Brown wrote:

> Graham's idea is a good one - and that's exactly how I found out all
> I needed to know about 8 bit .wav files.

 Well, that's one approach, but what about http://www.wotsit.org/ ?
Specifically, http://wotsit.org/cgi-bin/download.cgi?wav ,
http://wotsit.org/cgi-bin/download.cgi?wave and
http://wotsit.org/cgi-bin/download.cgi?wavecomp .
--
 Cheers,
       Paul B.

1999\10\18@100623 by Wagner Lipnharski

picon face
Have you considered to use VOC sound files instead WAV? They don't have
headers, nothing else, the very fist byte is purely the first
digitalized audio, one byte per sample in 8 bits, two for 16.  I should
have few shareware programs to convert one to another (email me if you
are interested).  If you intend to play audio files with a
microcontroller, do not discard the possibility to record sounds
directly to VOC files.

>From 8 to 16 bits you have 256 times better resolution.  For regular
human recorded voice to be played at noisy environment as automobile
alerts, phone messages, street, public address and so on, a good
recording in 8 bits is enough, even sampling low as 9kHz, but for high
quality you need to go for 16 bits with sampling > 15kHz.

The use of "compressor" option (available at some audio editors), will
amplify low level and reduce high peaks, turning the voice recorded much
more understandable for 8 bits sampling.

The recomendation fot the 8 bits recording is adjust the maximum
recording level (clipping few peaks), and controlling the audio level in
the analog amplifier section, or the DAC output. The background noise
between words can be "blanked" with any audio editor.

1999\10\18@141029 by Duilio Foschi

flavicon
face
Brent,

I found all the infos I needed at

  http://www.wotsit.org

It seems that when the sound is sampled at 16bits the midpoint value is ... 0 !

So what I have to do is to multiply every integer of the data chunk (both
positive and negative values) by (100+p)/100, where p is the wanted volume
raise (in percentage).

I checked the formula against a WAV file whose volume was increased using
Goldwave and ev seems to work.

Now I need to write a program that will take into account the rather complex
RIFF structure of a WAV file in order to detect where the data chunk exactly
starts and ends.

Also some care must be taken in order to manage possible overflows.

I am on the right track now.

Thanks a lot

Duilio


{Quote hidden}

At 22.44 16/10/99 +1300, you wrote:
{Quote hidden}

1999\10\18@141821 by Duilio Foschi

flavicon
face
Daniel,

I tried that.

I can assure you that the RIFF structure of a WAV file cannot be guessed by
a binary dump.

You'd have a better chance with the state lottery :)

Thank you

Duilio

At 20.23 18/10/99 +1300, you wrote:
>Duilio, why don't you open a 16 bit *.wav for random binary input and
examine the
>data ? try a silent sample and then a low frequency sine wave, the results
should
{Quote hidden}

1999\10\18@142026 by Duilio Foschi

flavicon
face
WAV files are not my choice. I just have to use them.

Thank you

Duilio

At 09.48 18/10/99 -0400, you wrote:
{Quote hidden}

1999\10\18@144316 by Ben Stragnell

flavicon
face
Duilio,

Sure it can. If it's a simple PCM .WAV file, with no compression, then all
you have to do is figure out where the header ends. The rest is raw audio
data, and all you need to do is figure out whether it's hi or lo endian (in
the case of 16-bit data), and what the midpoint is.

Cheers,
Ben

{Original Message removed}

1999\10\18@155438 by Don Hyde

flavicon
face
There's a fantastic file format resource at:
http://www.wotsit.org/index.htm

{Quote hidden}

1999\10\18@201348 by gdaniel

flavicon
face
re: Reverse engineering an audio communications format:    "*.wav", 16 bits
There are no site addresses below, I am just trying to show that it really is
possible to work things out without a "cheat sheet" handy:

Dulio, it is prudent to start "guessing" by considering the easiest methods usab
le
for converting the sound to a storable binary file.   Originally, only the very
simplest methods were used such as a simple representation of speaker/microphone
voltage with an 8 or 16 bit number. The header file that others mention is only
a
distraction as it may contain date/time info as well as format
verification(including sampling frequency)
If you try to analyse a *.wav file of noise then do not expect to see any immedi
atly
obvious patterns, this IS the nature of noise, likewise the AGC circuit so commo
nly
used with microphones will strain to pick out a faint sound in the absense of a
strong well defined sound, this is another source of noise.   That is why I
suggested that you start with samples of silence and low frequency sine wave, th
is
gives you an understanding of what you are looking for.
16 bit numbers may be stored either high or low byte first, unless the numbers a
re
scrambled deliberatly for security purposes (such as in the state lottery) then
you
can simply:
1) use low freq samples.
2) look for almost repeating pairs of bytes. (occuring after header)
3) least changing byte of pair is MSB.
4) average value is the offset.
5) track small changes from the offset to verify method of showing negative valu
es.
note: there may also be a noise glitch occuring briefly after record initiation,
this is the click or switching noise occuring when you start a recording.
Of course this is only the 20'th century and we are all a bunch of primative sav
ages
with brains only recently evolved slightly apart from the other "great" apes. (T
his
is my explanation anyway) for why only recently we have moved from tracking abso
lute
values to tracking changed values which require less storage. Here it is
necessessary to periodically provide a zero reference in this latter "compressio
n"
method.

The optimum compression involves careful analysis of the listener to discover th
e
extent of input capacity, once this is mapped out then the only information requ
ired
to be stored is that which can be percieved by the listener, a descriptive langu
age
may then be utilised.   A current example: *.mid files

Duilio Foschi wrote:

{Quote hidden}

1999\10\19@035056 by Duilio Foschi

flavicon
face
Ben,

I did figure it all, but only after I had the RIFF specs well in front of
me... :)

Thank you

Duilio



At 11.41 18/10/99 -0700, you wrote:
>Duilio,
>
>Sure it can. If it's a simple PCM .WAV file, with no compression, then all
>you have to do is figure out where the header ends. The rest is raw audio
>data, and all you need to do is figure out whether it's hi or lo endian (in
>the case of 16-bit data), and what the midpoint is.
>
>Cheers,
>Ben
>
>{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...