[MPlayer-users] How to create a wav file with silence with MPlayer

Rich Felker dalias at aerifal.cx
Tue Oct 4 18:30:46 CEST 2005


On Tue, Oct 04, 2005 at 11:12:33AM -0400, Giacomo Comes wrote:
> On Mon, Oct 03, 2005 at 11:01:29PM -0400, Rich Felker wrote:
> > On Mon, Oct 03, 2005 at 05:54:51PM -0400, Giacomo Comes wrote:
> > > On Mon, Oct 03, 2005 at 05:32:02PM -0400, Rich Felker wrote:
> > > > On Mon, Oct 03, 2005 at 10:54:53AM -0400, Giacomo Comes wrote:
> > > > > Hi,
> > > > > Up to MPlayer 1.0pre7 I was able to create a wav file with silence with the
> > > > > following command line:
> > > > > 
> > > > > mplayer -rawaudio on:format=0x1:rate=48000 /dev/zero -nocache -frames 4 -ao pcm:waveheader:file=silence.wav
> > > > > 
> > > > > The advantage of this method is that I can easily select the frame rate and
> > > > > the duration (-frames) of the wav file.
> > > > > 
> > > > > With CVS the syntax has changed. The corresponding command line is:
> > > > > 
> > > > > mplayer -demuxer 20 -rawaudio format=0x1:rate=48000 /dev/zero -nocache -frames 4 -ao pcm:waveheader:file=silence.wav
> > > > > 
> > > > > The problem now is that MPlayer never stops. It ignores completly the option -frames. Is there a way to restore the old beahviour?
> > > > 
> > > > What in the world do you mean by 4 frames of pcm audio??
> > > 
> > > That's a feature of mplayer! 
> > > With the previous command line I would create a silent wav file
> > > with duration of n+1 * k seconds where n is the argument of -frames 
> > > and k=341.3ms
> > 
> > This k is very arbitrary and depends on the implementation of the
> 
> I don't see a problem here. I know that k has this value with the 
> rawaudio demuxer. Why I cannot use it?

Because it has absolutely no meaning and there's no reason it should
remain the same if the demuxer implementation changes. It's chosen at
random, arbitrarily by the person who wrote the code...

> > demuxer. Making a script rely on it not changing from one version to
> > another is IMO a very very bad idea.
> 
> You are suggesting then to NOT write scripts that uses mplayer.

No.

> Because with EVERY new relase of mplayer there are some changes
> that will ALWAYS break a (non trivial) script.
> For example -ao pcm, and -vo png syntax has changed in the last
> two relases (just to tell the first two that I remember).
> The fact that the changes were documented didn't prevent the
> breakage, it simply made easier the implementation of the fix.

These sorts of changes are documented and we try to keep them to a
minimum. On the other hand, changes of _undefined_ behavior (like
random frame size of pcm audio) will not be documented and were never
meant to be used. It's the difference between relying on a feature and
relying on a bug...

Rich




More information about the MPlayer-users mailing list