Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Here's whay I need to do: Convert a 30.0 sec WAV to a 30.0 MP3.

I've tried doing this using LAME however no matter what I try LAME always adds a short moment of silence to the output mp3. Using LAME my 30.0 sec WAV becomes a 30.1 sec MP3. That's lame.

Does anyone know of a way to convert WAV to MP3 using the Windows command line?

For example by running "program.exe in.wav out.mp3" from CMD?

It is critical that NO silence is added to the resulting MP3 file. I can't stress that enough.

share|improve this question

2 Answers 2

I want to add this FAQ and a superuser thread to the discussion:

share|improve this answer
    
Thanks for the reply but that doesn't help. LAME confirms in that text file that they do in fact add silence to the audio. But there has to be a way to get around the silence in MP3, Adobe has found a way somehow for example. When adding a WAV in Flash and setting it to loop it does not add any silent gap in the resulting MP3 upon export. What magic have Adobe found? Macromedia (Flash's creator) were the ones that made this magic work in Flash. Anyone know how they do it? –  Niklas Mar 14 '12 at 22:14
    
Have you tried sox.sourceforge.net? –  JohannesM Mar 14 '12 at 22:30
    
I tried to try it but it doesn't come with MP3 support from the available precompiled binaries and I'm not skilled enough to compile it myself. I noticed sox have support for the libraries "libmad" and "libtwolame" for making MP3 (in addition to lame) so I would love to try it. Do you know where I can download a sox version with MP3 support precompiled? –  Niklas Mar 14 '12 at 22:54
    
I'm sorry, unfortunately no. –  JohannesM Mar 14 '12 at 23:19

An MP3 stream contains info for generating a set of samples where each sample corresponds to a sample in the original LPCM data (like from the WAV file), but a side-effect of encoding is that there is some extra "junk" added to each end, and a side-effect of decoding is that there is even more junk added to the beginning. The decoder will know how much it adds and will skip those samples, but the encoder-added junk isn't entirely predictable (different encoders add different amounts), so the decoder can't skip those samples unless it is somehow informed of what to skip. Some encoders, like LAME, will add such "gapless playback" or "delay and padding" info (in an encoder-specific format, because there's no standard for it) into the file's VBR Info (VBRI) or Xing header, which is sort-of standard even on CBR files, and which contains other info that is sometimes helpful to the player. This header is actually a frame of silence (usually 1152 samples) with some specially formatted info embedded in between the frame's header and the start of its null audio data. Most decoders/players recognize the frame as special and skip those samples, but some don't, so there's another potential point of failure. so I would look toward making sure you use a compatible encoder/decoder combo to get correct-length, junk-trimmed files as output.

Your second question...did you notice the LAME command-line app's "--decode" option? :) This should solve your problem if you're using LAME as the encoder. The output length should match the input.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.