hey guys,

i used sox for joining several .wav files to 1 big (4.36GB) .raw file. later i tried to encode this .raw to .mp3 using lame on commandline window. my commandline is

lame -r -s 48000 -V0 -m s -p old.raw new.mp3

after submitting it starts but its estimatet total encoding time of ~3Min is far too less. i checked the encoded mp3. it shows the right sampling rate and bit rate BUT it gets hardcore distorted and i cannot figure out my mistake.

chance you could help me out please?

and what does this technically mean?
i dont understand the words stdin and stdout. and cannot find infos in lame commandline documentation. what's that mean? where to use it? and how should its commandline look like? probably like this? lame -.wav -.raw ?

regards, tinobee

Hi, there is an article in Wikipedia:
Standard streams
Streams and piping are used to "stream" output directly to the encoder, avoiding large temporal wav file. Command line would look like "lame - -", but you will have to stream data to and from the encoder. In Windows you can do it in such a way:
>type audio.wav | lame -V0 - - > audio.mp3
More info on pipe and stream redirection is available in Windows Help system. You shouldn't use piping to encode on a regular basis from command line.


Your command line for raw is correct, but there is probably a bug in lame. Lame required RAW to be signed and big-endian on my Intel machine, and with little-endian RAW it produced noise.

Edit: also, filesize over 4 GB may be an issue.

Edit2: try the -x switch Gabriel pointed out.

Why is this?

'Cause it's ridiculous (you have a filename to specify, but go another, harder way). And because lame doesn't write vbr header when it encodes to stdout.

It seemed to me that you were speaking about piping in general (IOW, not just about Lame). Needless to say, I was thinking that there might be profound consequences.

Is your raw content really 48kHz?




-x

Thanks, I completely missed the "force byte-swapping of input" euphemism . BTW, shouldn't little-endian be the default one?

jup! is this a problem?

Nope, try adding the -x switch to your command line. Gabriel just asked to confirm (btw, if your audio was 44k, but you accidently specified 48k, that will cause only pitch change and not white noise.)

worked perfect now!

the missin -x added made all running perfectly! got the wished result out now!

thanks for support!

tinobee