Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Decoding MP3 to WAV (Read 11330 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Decoding MP3 to WAV

Hi

I have using RazorLame (with LAME 3.97) to decode MP3 files to WAV. I see it gives a message on "skipping initial 1105 samples" So I did a quick search around and found that different encoders actually gave different paddings.

But when I use RazorLame, it always says skipping 1105 samples no matter what the encoder was (Gogo, Xing, etc).

So is this alright? Would slight bits of the MP3 be chopped when I decode to WAV?

I did a search on the forums as well, and found this thread, which recommends not to use LAME when decoding
http://www.hydrogenaudio.org/forums/index....ic=1678&hl=
However, the thread dates back to 2002!

So what's the best method to decode today, without chopping of initial bits of the MP3? Is the modern LAME 3.97 alright for decoding?

Thanks
BB

Decoding MP3 to WAV

Reply #1
Why do you decode mp3s?

Decoding MP3 to WAV

Reply #2
Lame now tags its encoded files with information that allows them to be decoded to the exact same start and end points of the original wav file. This is what allows gapless playback on players that recognize this information.

I can't say the same about other encoders.

Decoding MP3 to WAV

Reply #3
Why do you decode mp3s?


To burn to an Audio CD, I tried using my default program but it can't convert mp3 to wavs properly, giving large stutters. But it works if I burn directly from a wav file.

Lame now tags its encoded files with information that allows them to be decoded to the exact same start and end points of the original wav file. This is what allows gapless playback on players that recognize this information.

I can't say the same about other encoders.


Yeah, I think that's the problem when I use LAME to decode. It always skips 1105 samples no matter what the encoder is.

BTW, since which version does LAME tag the file?

Decoding MP3 to WAV

Reply #4
My recommendation: encode two wav files that play back gaplessly into mp3 (using lame), then decode them again (taking note of any warnings). If the playback is gapless on the decoded files, eg. same start and end points as the original wavs, then all is well. Otherwise, further research is probably needed.

Decoding MP3 to WAV

Reply #5
Problem is that lame correctly skips the initial decoder delay, but does not leave out the encoder delay at the end (except if that would have been implemented in the mean time in the latest versions). The one decoder I know of that does that correctly is mpadec.

Decoding MP3 to WAV

Reply #6
Problem is that lame correctly skips the initial decoder delay, but does not leave out the encoder delay at the end (except if that would have been implemented in the mean time in the latest versions). The one decoder I know of that does that correctly is mpadec.

John's decoding fix found its way into CVS  in LAME version 3.98 alpha 3, Tue Nov 22 22:15:39 2005 UTC.

Decoding MP3 to WAV

Reply #7
My recommendation: encode two wav files that play back gaplessly into mp3 (using lame), then decode them again (taking note of any warnings). If the playback is gapless on the decoded files, eg. same start and end points as the original wavs, then all is well. Otherwise, further research is probably needed.


Good idea, I'll try that soon. But this only solves the problem of mp3s encoded by LAME. If they are encoded by other encoders, would the skipping 1105 samples when decoding be wrong?

Problem is that lame correctly skips the initial decoder delay, but does not leave out the encoder delay at the end (except if that would have been implemented in the mean time in the latest versions). The one decoder I know of that does that correctly is mpadec.


Do you recommend mpadec for decoding files?

Decoding MP3 to WAV

Reply #8
How about trying the wonderful Burrrn for burning cd's from MP3s?  If your program can't handle decoding mp3 correctly, who know what else it isn't doing correctly.
"You can fight without ever winning, but never win without a fight."  Neil Peart  'Resist'

Decoding MP3 to WAV

Reply #9
Burrrn will handle lame encoded mp3s correctly, indeed. However, it is only available for ms Windows. Again, here, I would not know of any other audio burning program that correctly decodes lame mp3s.

Decoding MP3 to WAV

Reply #10
For people who already use foobar2000 as their audio player, it is also a very effective decoder to write .wav files from compressed audio. You can set dither or no dither, and the decoder can also take replaygain data into account.
Concerning encoder padding, foobar2000 reads the LAME enc_delay and enc_padding information and so does not play (or decode) those parts at the beginning or end of an mp3 file.

Other encoders have specific initial padding values but do not write this information to the mp3 file.
LAME: 576 samples
iTunes mp3: 528 samples
FGH (used by Windows Media Player and others): 671 samples

I have also run across one set of mp3's (from a live concert) with an initial padding value of 1679 samples. I have no idea of the encoder, and after I used foobar2000 to write the enc_delay value (so they would play near-gaplessly; I don't have proper enc_padding values) the mp3 header is altered so programs like Mr Question Man are less able to recognize the encoder used.

edit: Mr Question Man says the 1679-delay mp3's are Xing, but given the header-altering I've done as noted just above, that may not be trustworthy.

edit2: Here is a rather technical article about encoder delays and padding, written in 2000 by LAME people. Worth looking over if you're interested in background reasons.
http://lame.sourceforge.net/tech-FAQ.txt
God kills a kitten every time you encode with CBR 320

Decoding MP3 to WAV

Reply #11
My recommendation: encode two wav files that play back gaplessly into mp3 (using lame), then decode them again (taking note of any warnings). If the playback is gapless on the decoded files, eg. same start and end points as the original wavs, then all is well. Otherwise, further research is probably needed.


Yes, just tried it, the starting position is the same when I encode with Lame and decode with Lame.

But I don't think it might be the same if a file was encoded not with Lame but decoded with Lame?

BTW, is MAD a good decoder?




Decoding MP3 to WAV

Reply #15
You know lame doesn't have to skip those samples? Try the --decode-mp3delay -529 option.

http://mp3decoders.mp3-tech.org/decoders_lame.html#lame387

Cheers,
David.


Thanks for that link, very useful! From the table, I only need to avoid skipping 1105 samples only if the file is encoded by Blade as only in Blade encoded files will samples be cut off when decoded.

BTW, does anyone know what the delays are for Gogo encoder?

Decoding MP3 to WAV

Reply #16
BTW, does anyone know what the delays are for Gogo encoder?

The answer is not surprising: encoder delay is 576. Just as for LAME. (At least for GOGO-no-coda 3.13  )

Decoding MP3 to WAV

Reply #17
You can check the delay of any encoder by creating a file with a single click (impulse) at the start, encoding it, decoding it with a known decoder, and finding the position of the peak of the (now mangled!) impulse in the decoded file. You need an audio editor that shows individual samples (e.g. Cool Edit).

Don't use too low a bitrate for this test or the peak will be scrambled!

Cheers,
David.

Decoding MP3 to WAV

Reply #18
Thanks to all for your help!  I've heard Gogo is a reworked version of LAME?



....
BTW, is MAD a good decoder?

Yes.


So do you think MAD or LAME is a better decoder? From the review on the website above, I see an older Lame 3.87 getting an "excellent" review but MAD only gets a "very good".
http://mp3decoders.mp3-tech.org/decoders_lame.html#lame387
http://mp3decoders.mp3-tech.org/decoders_mad.html

Decoding MP3 to WAV

Reply #19
Thanks to all for your help!  I've heard Gogo is a reworked version of LAME?

Yes, it's a heavily speed optimised version based on 3.88.
So do you think MAD or LAME is a better decoder? From the review on the website above, I see an older Lame 3.87 getting an "excellent" review but MAD only gets a "very good".
http://mp3decoders.mp3-tech.org/decoders_lame.html#lame387
http://mp3decoders.mp3-tech.org/decoders_mad.html

TBH, I think there's little to choose between them and that review is considerably out of date regarding both decoding libraries.

Decoding MP3 to WAV

Reply #20
So do you think MAD or LAME is a better decoder? From the review on the website above, I see an older Lame 3.87 getting an "excellent" review but MAD only gets a "very good".

Honestly, I don't think it matters much with a decoder. Decoding is a relatively simple process and my impression is that most decoders will get the same or very similar results. Encoding is a much more intensive and variable process, and is where you get major differences in algorithms and results.
God kills a kitten every time you encode with CBR 320

Decoding MP3 to WAV

Reply #21

Thanks to all for your help!  I've heard Gogo is a reworked version of LAME?

Yes, it's a heavily speed optimised version based on 3.88.

From EncSpot, there's a Gogo (before 3.0) and Gogo (after 3.0). Are they both based on Lame 3.88?


Regarding the decoder, I've made up my mind, I'll just use Lame 3.97 to decode since it saves the hassle of installing and configuring more software on my computer. Thanks for everyone's help in this thread!

Decoding MP3 to WAV

Reply #22
The current gogo is 3.13 which has been around for nearly 4 years and that's based on 2.88. Before that, I really don't recall.


Decoding MP3 to WAV

Reply #24
LAME is using old mpg321 library, if Im not mistaken, and best method will be latest mpg123 :

http://mpg123.org/

http://www.hydrogenaudio.org/forums/index....showtopic=61760

You're probably right, but I think it's the error recovery that's been improved rather than any real improvements in the decoding, per se.