Hi people, could you please somebody explain me this next problem?

I have not been using mp3 encoding about two years (on behalf of ogg). But now I‘ve been asked by a friend to make him something of my archives into mp3 (because of hw decoding). So I downloaded Lame (3.93) and made the thing. Now what happened. I’ve tried to playback created mp3 files and noticed that my cue plug-in became very unreliable (differences over 1/2 of minute). Therefore I’ve tested around and found out that a wav file uncompressed from mp3 does not match (as for the lenght !) to the source wav. I’ve never noticed this before (uncompressed oggs do fit). So I think this state is not a meaning of concept „lossy“. This is a fail. Of what? (mp3? lame? 3.93?)

(Could you please answer to my mail too? I cannot read this forum regularly)

No, it's a failing (and I may be slightly wrong about this, but if I correctly understand the way your plugin works then it should be fairly close) of the way your audio player calculates the length of an MP3. If you are using VBR (variable bitrate) encoding this will be especially evident, since for any given point in the audio the index calculation based on average bitrate will be close enough for most seeking functions, but far enough off to sound wrong in CUE sheet-based plugins. Try a quick test using CBR (constant bitrate) and your CUE sheet plugin should work just fine.

- M.

Original and decompressed wav can differ because of the MP3 offset. Mp3 introduce gaps at the beginning of tracks. But the difference must be inferior to 1 second.
Also don't use Lame 3.93, there is a bug about quality. Use the recommended 3.90.3. The recommended compiles and settings are linked in the FAQ.

To M (thanks for your reply) and to Pio2001 (I know your name for several years from various groups, thanks for your work; btw. thanks to your tests I enjoy my Marian soundcard, it is really bit-to-bit reliable!).

Our topic is solved. But step by step:
- I have yesterday mixed two appearances. First I have found that cue-plugin fails on mp3 files and subsequently noticed (first ever) that decompressed mp3 doesn’t match to the length of original wav - and put them together.

- I knew that it is not the question of multiple tracks (and partial samples at the end and the beginning of tracks) - I have one huge wav, the whole album (that’s why I use cue-plugin). Also, the difference is much bigger than it should be in this matter.
- I knew that it is not the question of not perfectly linear counting of time while VBR. CBR does do the same. And also, the difference is much bigger than it should be in this matter.

- So I searched around more and have discovered that seemed fail of cue-plugin is the bug of MAD mp3 decoder. (Putting mpg123 or in_mp3.dll back into winamp\plugins corrects the thing.) Could you please somebody report this bug to them?? (It is quite much work for my english...) It is really a big difference (up to 1 minute) and it is not necessarily linked to using of cue-plugin. Simply, they count (and show) e.g. 37’ but playback only 36’.

- But when I forget the prime problem above I still do not understand this:
souce wav 547 886 684
encoded 75 922 922 (alt-preset standard)
decoded 547 891 432
(exactly the same size comes after decoding from CBR)
but:
souce wav 547 886 684
encoded (ogg q6) 73 033 209
decoded 547 886 684 exactly
The difference is around 4-5 KB on every trial I have tested. Is it OK ??
I guess not, however using recompressed wavs is practically not recommendable and however now I see this has nothing to do with the topic above.

One more question please. I have done tests with 3.90.3 advised by you (before I catched the solution above) and stated that files (alt-preset standard) are 4-5% bigger than the ones I have made with 3.93. It is not a few. Any recommendations?

Thanks