[FFmpeg-devel] [PATCH] WAV file length (writing to stdout)

[Axel Holzinger]

Rich Felker writes:
> On Tue, Oct 16, 2007 at 05:02:39PM +0200, Cyril B. wrote:
> > Hi,
> > 
> > As reported recently on this mailing list [1], ffmpeg sets 
> 0 as file length
> > in the WAV header if output is streamed (for instance, when 
> outputting to
> > stdout). Nero AAC encoder does not accept such streams 
> ('could not parse
> > WAV file' error).
> > 
> > The WAV file specs [2] say the file length (ChunkSize) must 
> be 36 + data
> > length. The included patch writes 36 instead of 0, which 
> satisfies Nero
> > encoder.
> 
> IMO both are wrong. The most compatible way to make a wav header for
> unknown length is to put 0xffffffff in the header.

0 as the RIFF length and 0 as the data chunk length is a common agreement in serious recording applications while still recording the file. So a playback application can determine that the given file is still being recorded. As soon as the recording application finishes the ongoing recording, it writes the correct values for RIFF lenth and data chunk length to the file.

I think Nero AAC encoder is an application that is not considering that a given file might still be recorded at the moment it is passed to Nero AAC encoder.

Setting theboth length to 0xffffffff (-1) makes the file invalid as 0xffffffff (-1) is an invalid value for the lenth fields. So I consider this to not be a good way.

Setting the RIFF length to 36 is not a good idea either, because now the applications reading the file can't anymore detect that the file is still recorded.

To make a long story short: Fix it in the first play! That means it is not a good idea to fix a Nero AAC encoder problem in ffmpeg.

Just my 0.02?
Axel

> Rich