[MPlayer-users] VBR sync problem

[Michael Collard]

I am discovering more about this every day. I am now close to a
resolution though don't understand why. Even with different compilers &
libmp3lame (have tried 2 known stable versions of each). For example,
creating a AVI with VBR audio using a lameopts tag of 'VBR=4' results in
MUCH better sync. The reason I chose 4 over 2 (default in mplayer
manpage) is because Lame uses 4 by default.

There are a number of things I don't yet understand, such as why not all
sources cause this even with same encoding options. I can capture TV
will little difficulty, and it works like a treat. No sync loss!

Avidemux also seems to think that any MP3 stream I have written with
mplayer is also errorous, or broken or even missing. Trying to
interleave variable audio data I can understand may be quite difficult
but this problem I have witnessed on many systems and OSs. Where there
an option to manually align the streams I don't worry about it.

As I try more, I will find out the cause of this. I have done enough
playing around with libraries etc.

Thanks for your reply.

On Mon, 2003-03-31 at 22:55, D Richard Felker III wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> On Mon, Mar 31, 2003 at 05:46:08PM +0800, Michael Collard wrote:
> > [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> > Sorry again to reply to myself.
> > 
> > I have now ruled out many things trying to fix this problem of sync out
> > by 200ms - 300ms
> > 
> > 1) It is not related to the version of libmp3lame.
> > 2) Occurs with most all versions of MPlayer tried (RC2,RC3,RC4,RC5)
> > 3) Occurs in 2 pass, 3 pass and single pass mode.
> > 4) Does not happen when using CBR MP3.
> > 5) Occurs on MDK9 (despite what I said), Gentoo & MDK9.1
> > 6) Allowing normal users access to /dev/rtc does not fix ALL encodings.
> > 7) Occurs under any user, or superuser.
> > 8) Occurs with different -vo or -ao options when playing.
> > 
> > This is very frustrating FFS. I would simply like a confirmation if this
> > is a known problem or just something sporadic. I will most certainly
> > give anyone a clip of these encoding if they wish to test.
> 
> It's known in the sense that you and other people have repeatedly
> reported it, but not known in the sense that the developers have never
> observed it. Are you POSITIVE it's not related to your version of
> mp3lame or perhaps to a broken version of gcc? If you haven't tried
> downloading lame tarball and compiling it yourself manually, DO THAT.
> And make sure you don't have an old/broken copy lying around that's
> getting used instead of the new one.
> 
> > Michael Collard, Microsoft Certified Professional
> 
> Probably not a good idea to advertise that on this list... :))
> 
> Rich
> 
> _______________________________________________
> RTFM!!!  http://www.MPlayerHQ.hu/DOCS
> Search:  http://www.MPlayerHQ.hu/cgi-bin/htsearch
> http://mplayerhq.hu/mailman/listinfo/mplayer-users
-- 
Michael Collard, Microsoft Certified Professional
http://members.iinet.net.au/~quadfour