Do Not Use the Vorbis FFMPEG enecoder if you building WebM!, Monty mentions this in his blog post, but nobody is listening! Options

[HotshotGG]

A lot of open-source enthusiasts and advocates are very excited about Google latest announcement of VP8 / Vorbis combo in a new container called WebM. The entire HTML 5 enthusiasts are so excited that they went a ahead a little to prematurely are building suboptimal builds! Michael Niedermeyer of FFMPEG projects acknowledges that the FFMPEG Vorbis encoder is buggy! Monty has a work around on his blog if you plan on building the WebM encoder under Linux. I am also providing an explanation in the wiki as to why it's generally a good idea to use the mainline libvorbis with libavcodec instead due to the fact that is has 5.1 channel coupling implemented correctly! Please spread the word as this will turn into a disaster sooner or later before it's patched. If you thought the HTML 5 wars are not bad enough now!

Monty's Blog:
http://xiphmont.livejournal.com/51160.html

This post has been edited by HotshotGG: Jun 12 2010, 18:43

[LordWarlock]

It would be useful to have an independent (from the developers of libvorbis) validation of the perceptual performance... since the "well known suggestion to use libvorbis" is not that well known.

And Monty is... ???

The FFmpeg internal encoder is just a very simple encoder that makes no attempt at high quality. It includes no psychoacoustic code and its only goal is to spit out a valid bitstream, not make it sound good.

Source: http://xiphmont.livejournal.com/51160.html...=145112#t145112

[NullC]

It would be useful to have an independent (from the developers of libvorbis) validation of the perceptual performance... since the "well known suggestion to use libvorbis" is not that well known.

And Monty is... ???

The FFmpeg internal encoder is just a very simple encoder that makes no attempt at high quality. It includes no psychoacoustic code and its only goal is to spit out a valid bitstream, not make it sound good.

Source: http://xiphmont.livejournal.com/51160.html...=145112#t145112

Yes, Monty is the primary developer of libvorbis. As such, this is not independent from the developers of libvorbis. For all some third party knows Monty's complaints could just be sour grapes and preference for his own code.

I know this isn't the case... but I think it's not so obvious to everyone. Some actually independent validation would really provide good ammunition for convincing people not to use ffvorbis. I've been trying and largely failing for a long time now— I even got ffmpeg to completely disable it, but they re-enabled it a week later. In a world full of people who call 64kbit/sec MP3 "CD quality" getting people motivated enough to take an effort to choose a better vorbis encoder than the default is non-trivial.

I don't think you have to validate something the developers of which claim is unusably bad, unless you're think they're out to fool you or something.

A web-accessible citation that the developers of ffvorbis consider it to be unusably bad would be very helpful.

This post has been edited by NullC: Jun 14 2010, 19:37

[saratoga]

It would be useful to have an independent (from the developers of libvorbis) validation of the perceptual performance... since the "well known suggestion to use libvorbis" is not that well known.

And Monty is... ???

The FFmpeg internal encoder is just a very simple encoder that makes no attempt at high quality. It includes no psychoacoustic code and its only goal is to spit out a valid bitstream, not make it sound good.

Source: http://xiphmont.livejournal.com/51160.html...=145112#t145112

Yes, Monty is the primary developer of libvorbis. As such, this is not independent from the developers of libvorbis. For all some third party knows Monty's complaints could just be sour grapes and preference for his own code.

I know this isn't the case... but I think it's not so obvious to everyone. Some actually independent validation would really provide good ammunition for convincing people not to use ffvorbis. I've been trying and largely failing for a long time now— I even got ffmpeg to completely disable it, but they re-enabled it a week later. In a world full of people who call 64kbit/sec MP3 "CD quality" getting people motivated enough to take an effort to choose a better vorbis encoder than the default is non-trivial.

I don't think you have to validate something the developers of which claim is unusably bad, unless you're think they're out to fool you or something.

A web-accessible citation that the developers of ffvorbis consider it to be unusably bad would be very helpful.

The ffmpeg people have said many times not to use their vorbis encoder. This is why they have support for the Xiph one. The problem has nothing to do with people refusing to believe ffmpeg and Xiph about how to encode vorbis files, as such providing more evidence will not help at all.

The problem is that people do not realize their are two vorbis encoders available in ffmpeg and are merely going with the first one they see, which is often the bad one. Again do google a search. This has been widely discussed many times by all parties involved. Hopefully ffmpeg will just disable the bad encoder or at least provide a warning so that people stop using it.