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: Do Not Use the Vorbis FFMPEG enecoder if you building WebM! (Read 21621 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

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
budding I.T professional

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #1
TOS #8!!!



Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #2
I don't get the point of this post, ffmpeg-people always suggested using libvorbis over their internal encoder, nothing new here. It's the same for ffmpeg's AAC encoder, for example. Noone should use software blindly without doing some (re)search on its functionality first. The easiest way is to drop by in #ffmepg on freenode and just ask. You'd be surprised as to how many "guides" on the net are bad or plain wrong.

If you use libvorbis you have to make sure it's the newest version to have correct multichannel coupling, as this was just introduced recently. AoTuV does not have the new coupling, yet.
It's only audiophile if it's inconvenient.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #3
TOS #8!!!

How is it TOS8 if the user is just passing on word that ffmpeg is acknowledging a known bug in their encoder? Do we need to ABX for programming errors now?

Sarcasm aside, Kohlrabi does make a good point.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #4
TOS #8!!!

How is it TOS8 if the user is just passing on word that ffmpeg is acknowledging a known bug in their encoder? Do we need to ABX for programming errors now?
Sarcasm aside, Kohlrabi does make a good point.


It's not buggy in that sense.  It's not like it crashes.  The claim is that it produces significantly poor quality.  Squarely within the sights of TOS8.

There are some people who do not believe these claims, or at least think they are exaggerated.  The largest and most visible user of WEBM is using ffvorbis.
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.





Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #5
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.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #6
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... ???

Quote from: xiphmont link=msg=0 date=
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

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #7
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... ???

Quote
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.

Quote from:  link=msg=709923 date=0
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.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #8
Canar reporting in with an ABX. A blind monkey could do it. I see deaf people.

Vorbis via libvorbis v1.3.1 -q1 at ~84kbps vs. FFMPEG v0.5.2 -aq20 at 104kbps. Pink Floyd's Fearless off of Meddle.

FFMPEG sounds like shit, even at the higher bitrate. Pre-echo, warbling... all over the place. Libvorbis sounds significantly more transparent.

Sorry I couldn't bitrate match better, too lazy. FFMPEG still fails it.

Edit: For some perspective, I've played around with more bitrates. Libvorbis at -q0 (65kbps on this sample) has about the same amount of warbling as FFMPEG at -aq30 (136kbps on this sample) and has significantly less pre-echo. Seriously. Monty's not joking around here. FFMPEG is an immature, novel implementation of a Vorbis encoder and it clearly shows. This is not meant to disrespect FFMPEG; such a task is not trivial. However, if transparency matters at all, -q0 beats FFMPEG at half the bitrate and that's no exaggeration. "Unusably bad" is not rhetoric, I think that's an accurate portrayal of the state of FFMPEG's current Vorbis encoder state. It's like old-school Xing vs. LAME.

Edit 2: WHOOPS! I wasn't using libvorbis 1.3.1, I was using aoTuV b5.7. Switching doesn't change the results all that much. -q0 is now a bit less transparent, but FFMPEG still loses out, for the same reasons.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #9
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... ???

Quote
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.

Quote from:  link=msg=709923 date=0
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.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #10
What is worse: FFMPEG Vorbis, FFMPEG WMA or FFMPEG AAC?

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #11
What is worse: FFMPEG Vorbis, FFMPEG WMA or FFMPEG AAC?
-.- I'll leave this for someone else.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #12
Quote
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.


Thank you this is merely what I was pointing out! This is what I was getting at I should have been a little clearer. It seems like in my opinion though nobody is really listening though like NullC!? You know "naysayers" are only going to use this as a jump off point to spear WebM and bitch about how bad the audio quality is due to the fact that the FFMPEG Vorbis encoder has no Psychoacoustics model thus spawning an endless nerd  flame fest on Slashdot that will last for two centuries    . Many of you may or may not know, but YouTube and other independent video sites for example uses commercial software for mass transcoding, etc. There have been complaints of "ringing artifacts" already on Debian boards.

Quote
Canar reporting in with an ABX. A blind monkey could do it. I see deaf people.


Thank for you performing an ABX test to validate the claims. Empirical evidence helps! I didn't doubt him I was just passing the world along I noticed nobody picked up on it here.
budding I.T professional

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #13
It's not buggy in that sense.  It's not like it crashes.


As a programmer, my definition of "bug" is any incorrect coding that causes the program to act in a way that was not intended by the developers. It doesn't always have to crash.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #14
This problem has already been raised here when the encoder was first added to FFmpeg : http://www.hydrogenaudio.org/forums/index....showtopic=48898

IMHO the only problem is that the name of the encoder is vorbis in FFmpeg and the official vorbis encoder is called libvorbis. People who don't know there are more than one vorbis encoder will stick to the low quality one.

It should be vorbis for the libvorbis encoder and something like experimental-ffmpeg-vorbis for the FFmpeg-made one.
Opus 96 kb/s (Android) / Vorbis -q5 (PC) / WavPack -hhx6m (Archive)

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #15
It's not buggy in that sense.  It's not like it crashes.

As a programmer, my definition of "bug" is any incorrect coding that causes the program to act in a way that was not intended by the developers. It doesn't always have to crash.


Did you also sleep at a holiday inn express? 

It's not _buggy_ it doesn't perform in unexpected ways, my crashing comment was an example— it wasn't intended to imply that I thought that all bugs cause crashes (and I clearly don't). The ffvorbis encoder is just lacking the kind of serious psychoacoustic analysis and tuning that libvorbis has, it probably has bugs too ... most non-trivial software does, but that probably isn't the reason that it performs the way it does.

IMHO the only problem is that the name of the encoder is vorbis in FFmpeg and the official vorbis encoder is called libvorbis. People who don't know there are more than one vorbis encoder will stick to the low quality one.


Well— that and libvorbis isn't compiled by default in ffmpeg and requires an extra dependency.  So there are many people that have ffmpeg binaries where acodec vorbis was the only way to get vorbis output. Even if it had been called crappy-vorbis it still would be used by people who didn't know or didn't care to get a better binary.

FWIW,  The ffmpeg folks agreed to temporarily disable acodec vorbis' encoder in the 0.6.0 release. Though, at least historically, almost everyone runs some build or another from ffmpeg svn... so it's not a closed issue yet.

Quote

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. 


Many times... but you can't find a citation for me?  I'm not insisting because I don't believe you, I'm insisting because I can't find one and it would be very useful to have one.

People have very much refused to believe us at Xiph that this is actually a serious issue.  I wouldn't be asking for people to do testing here if we weren't currently having some problems convincing some big and important organizations that they really shouldn't use the ffvorbis encoder.

Quote from:  link=msg=709936 date=0
Canar reporting in with an ABX. A blind monkey could do it. I see deaf people.


Thank you. As funny as it is, this simply test _will_ help convince people that there is something they need to worry about.


Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #16
Many times... but you can't find a citation for me?


I probably could find a citation, but am not motivated to do so.  Try google.  I doubt its that hard to get. 


Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #18
You can generate your own citation:

Go to #ffmpeg on freenode, and ask about the quality of "vorbis" compared to "libvorbis", and wait for a dev to answer.
It's only audiophile if it's inconvenient.

Do Not Use the Vorbis FFMPEG enecoder if you building WebM!

Reply #19
A bit late here, for what it's worth, here is my citation as the creator of ffmpeg vorbis encoder:

ffmpeg's vorbis encoder sucks. It has no psychoacoustics model, and no attempt whatsoever at preserving the audio quality. As Monty said, it only attempts to "create a valid bitstream".
I have lost touch with ffmpeg development, but I see now that the default has been changed back to libvorbis instead of ffvorbis for encoding.

Oded