Mon 07 Sep 2015 11:19:10 AM UTC, comment #4:
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
|
Sun 06 Sep 2015 11:27:41 AM UTC, comment #2:
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`)
- 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
|
Sun 06 Sep 2015 09:46:26 AM UTC, comment #1:
The corrupted dump file could be fixed by passing it through FFmpeg/AVconv:
The fixed file would be read properly by Audacity.
For the issue itself, I suspect that Gnash initially write RIFF WAVE header
with data length 0 before starting to dump audio but "forgot" to come back
and change the corresponding headers to the real audio length
when the dumping ended.
libAV: libav-tools 6:0.8.10-1 (debian)
Audacity: audacity 2.0.1-1 (debian)
System: Debian GNU/Linux 7.0 Wheezy i386
|
Sun 06 Sep 2015 09:37:00 AM UTC, original submission:
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
|