#4 Change .wav STDOUT to work with sox

closed
nobody
None
5
2001-11-01
2001-09-26
Anonymous
No

(This is a cross between a bug and a feature request)

Great product, its the only command line mp3 decode I could find with good error-tolerating of mp3
files (mpg123 bombs 20% of the time).

One of the things I use it for (OK the only thing) is to convert mp3's and pipe them to cdrecord.
However, I pipe them through sox where I add a pre-figured out Volume adjustment and force
Stereo 16-Bit 44,100 raw output to cdrecord.

I have to use sox because I need to force output to CD size raw output, so the only way I can do
that programmaticaly is to output it to sox as a .wav file, then force the output in sox to the
correct raw format.

The problem is that madplay, for .wav files, starts with a "LENGTH" in the header of 0, then later
corrects it. This causes sox to read 0 bytes of data and quit. Other programs write a "LENGTH" of
FFFFFFFF , then correct it. This works better for piping to STDOUT (I just ignore the premature
EOF warning).

So, Can I request:
1) Change all occurences of \0\0\0\0 in lib_wav.c to \255\255\255\255
or
2) Add options to force 44,100 Stereo 16-bit raw output

I did option #1 myself with no problem.

BTW, the intended use I'm talking about is something like:
madplay -o "WAV:-" \ | sox -t wav - -v $VOLADJ -c 2 -r 44100 -s -t raw - \ | cdrecord -audio -pad -nofix

Thanx

Eric

Discussion

  • Rob Leslie
    Rob Leslie
    2001-11-01

    Logged In: YES
    user_id=42487

    The next release (0.14.2b) will do both options: the
    audio_wave module will initially write all-ones instead of
    all-zeros for the length, and there will be a new audio_cdr
    module specifically for writing CD-R audio format output.

    Thanks,
    -v

     
  • Rob Leslie
    Rob Leslie
    2001-11-01

    • status: open --> closed