Patches included: see patch #8734.

After applied patch 1-2, output dump file could now be opened properly
by Audacity, SoX, and Sound Recorder.

Gnash: 0.8.11dev (patched against git dc51f53 28-Aug-2015)
Audacity: 2.0.1-1 (debian)
SoX: 14.4.0-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386

Sound Recorder: sndrec32 5.1.2600.5512
System: Microsoft Windows XP SP3

Looking at the `chime_gnash0.8.11dev-dc51f53.wav` under hex editor reveals following RIFF structure:
(@nnn means offset from file's beginning, numbers are in decimal unless prefixed with `0x`)

RIFF "WAVE"    (chunk@0, payload list@12, payload size 40)
 \
  +- fmt       (chunk@12, payload@20, payload size 16)
  |
  +- data      (chunk@36, payload@44, payload size 0)
  |
  +- \0\0\0\0 *(chunk@44, payload@52, payload size 0xFFFFFFFF)
      .
     (Audio data goes here...)

• Last chunk is invalid (invalid name, and chunk size exceeded main RIFF chunk).

This shows two problems:

1. Gnash pre-filled `data` chunk size as `0` and filled
`RIFF` chunk's size accordingly, before writing out the audio data.
But when it is about to terminate, it didn't come back to update
the corresponding size fields of `data` and `RIFF` chunk.

2. Gnash put an invalid chunk in the output file. (Not sure if this is
a placeholder for audio data or something)

So when other programs tried to read the dump file, it either interpret
that this is an empty WAV file (0 byte in `data` chunk), or this is a
corrupted WAVE file (due to an invalid chunk of mystery, or garbage that
followed the RIFF chunk).

Side note: following is minimal RIFF structure of a valid empty WAVE file

RIFF "WAVE"    (chunk@0, payload list@12, payload size 32)
 \
  +- fmt       (chunk@12, payload@20, payload size 16)
  |
  +- data      (chunk@36, payload@44, payload size 0)

This is a spin-off from bug #45722 (screeching PCM sound).

When I was trying to capture audio dumps from bug #45722's test files using
`gnash --audio-dump` option, I found that the audio dumping process
worked reasonably and resulting WAV file is playable with MPlayer
and VLC.

But when I tried to load the WAV file into Audacity to check the waveform,
it shown up as an empty (0 sec) file, same goes with SoX
and Windows Sound Recorder 5.1. Other programs (e.g. Nero WaveEditor 3.5)
also complained that the file is corrupted and refused to open it.


I have created a simple Flash file (using MTASC, SWFmill and LAME) that
tries to play a simple 6-sec 44100 Hz Mono MP3 sound of Westminster chimes.
Then dumped the audio output using `gnash -1 -r 2 --audio-dump` to demonstrate
the issue.

Test Flash file, code, sound and build script are attached as `chime.zip`.
Resulting WAV file is attached as `chime_gnash0.8.11dev-dc51f53.wav.gz`.
Log output (verbosity 2 + action error log) is attached as `chime_gnash0.8.11dev-dc51f53.log`.


Gnash: 0.8.11dev (git dc51f53 28-Aug-2015, FFmpeg/libAV media backend)
SDL: libsdl1.2debian 1.2.15-5 (debian)
libAV: libavcodec53 6:0.8.17-1 (debian), libavformat53 6:0.8.17-1 (debian), libavutil51 6:0.8.17-1 (debian)
CSound: libcsound64-5.2 1:5.17.11~dfsg-3 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386