>
> Hi,
> I was wondering if there is anyone who can help me
> with streaming a wave file into Lame. I have been
> experimenting with the distmp3 Perl scripts, which
> allow encoding on a remote machine. They recommend
> using 8hz-mp3 as it is the only one that can identify
> the wav header, why is this?
>
A couple of changes since 3.13 have been made to handle
more complicated .wav headers. But this is probably not
your problem because the code in 3.13 will just
pretend these .wav informational 'chunks' are pcm data.
I think your problem is probably the backward fseek()'s. On my
machine (RH 5.2) I have no problem with a few short fseek()'s on
stdin, but some people do report problems with this, especially when
the input is a named pipe? LAME will also fseek() forward to
skip wav header chunks which are not needed.
The way the code works is (left over from the ISO days):
read in a few bytes, check for aiff header
If not found:
fseek() back to beginning of file
check for .wav header
if not found:
fseek() back to beggining
assume raw pcm input.
Errors on fseek() are ignored, so if you get an error on the first
fseek(), it wont back up and be able to find the .wav header.
Since wav is much more popular than aiff, I just reversed the order
(check for wav first, then aiff). So you might want to try
getting the latest version, and going into get_audio.c and
changing around line 420 to:
if (!ispcm) {
iswav = parse_wavheader(); /* check for WAVE and parse headers */
if (!iswav) {
isaiff = parse_aiff(inPath,info); /* check for AIFF and parse AIFF headers
*/
}
if (!(isaiff || iswav)) ispcm=1;
}
Of course the obvious solution is what you suggest: buffer the header
so as to avoid any backwards fseek()'s. If you want to send me a patch,
I'll be glad to add it :-)
Also, libsndfile will soon support reading from stdin, and it has much
better wav parsing.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
