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

Why do you decode mp3s?

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.

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.



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?

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.

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.

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?



Do you recommend mpadec for decoding files?

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.

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.

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

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?

Yes.

Does it also skip a fixed 1105 samples?

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?

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

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.

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




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

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

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

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.

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!

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.

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.

I've downloaded the file and read the README and INSTALL files, but I don't know how to use it. Is it a command line decoder? In the INSTALL file, under prerequisites, it says I need a C compiler plus lots more stuff?

IIRC the version of mpg123 in lame was "bug fixed" in some way. I assume the bug fixes made their way back into mpg123, but I don't know.

foobar2k is an excellent way of decoding mp3s. IIRC the newer versions of MAD are also better than those I tested years ago (haven't tested them properly though).

Cheers,
David.

You can download win32 binaries here if you need it:

http://mpg123.org/download/win32/mpg123-1.3.0-static-x86.zip

You can use it from command line:

mpg123.exe -w output.wav input.mp3