These last months, some new audio stuff has been released in this great AV converter mainly a new flac encoder, wavpack decoding support and in a few days a vorbis encoder will be included. That's great, isn't ?

The encoder engine has been coded by Oded Shimon and according to his message in the ML :

Quality is comparable to official vorbis encoder (to my ears), at similar
bitrate. bitrate and quality can be manipulated with -aq, 10 to 30 are
sane values, the higher the number, the higher the bitrate/quality.

Only 2 channel is supported, and, in a psy sense, 44100/48000 is best
supported...

This has been comitted now in the Subversion and we can play with it I think, though it's the first review.  I've made a fresh compile for win32 OS.

Ex command Line used for a level quality of 50 :

Code: [Select]

ffmpeg -i input.wav -acodec vorbis -aq 50 output.ogg

I'll post some ABX results later...

This is very nice, as in libavcodec tradition this is a bare minimal encoder. Very usefull to understand bitstream of a format.

Regarding quality, I would be very surprised if it would be similar to the "official" vorbis encoder (and a few people would have a big laugth).
Unless I'm wrong, there is a "little" part usually found in encoders that is missing there: the psychoacoustic model. This encoder seems to be only minimizing differences toward the original (in the same way as the libavcodec mp2 encoder).

As a comparison, we already had a public listening test with an encoder using a psymodel vs one without any psymodel:
http://www.maresweb.de/listening-tests/mf-128-1/results.htm
In this test both Lame and Shine are mp3 encoders, but one doesn't feature any psymodel.

Just tried with one short track, with no extraordinary difficulty (rather an easy track).
-aq 50 sounds pretty good, but bitrate is 293 kbps. The scale is apparently different from the official encoder.

-aq 10 encoding on this track is only 130 kbps, and is completely unlistenable: there's an awful ringing and it's completely metallic. I would comparable the quality with WMA... at 64 kbps.

http://kurtnoise.free.fr/index.php?dir=mis...-vorbis_enc.zip

Incorrect format for file ./languages/ru.txt on line 1.
Format is "variable name[tab]value"

mmh...try this http://kurtnoise.free.fr/misc/ffmpeg_rev6519.zip or here

this is quite interesting. however, does this encoder support interger encoding?

Tried with other samples and my conclusion is that this encoder is not usable. Quality is poor and bitrate distribution weird. Bitrate is more than twice higher with a sample like debussy (known to be very quiet and therefore bitrate friendly with VBR encoder) compared to NewYorkCity (131 kbps vs 57 kbps with -aq 10). In other words, if this encoder is not efficient at all on quiet/dynamic track, it's not even usable for DVD-ripping (at least not preferable to the XIPH's reference encoder or aoTuV).

I just upload some examples. They are surely not the best ones: they correspond to the only files I currently used. Worse cases must exist.
There's a comparison between aoTuV and ffmpeg encoder. The methodology is poor:
- each sample was encoded with -aq 10 [I don't currently know the average bitrate for this setting]
- then I tried to get the same bitrate with aoTuV.

http://rapidshare.de/files/35135474/vorbis_ffmpeg.zip.html

I recommand to check on your side the validity of my encodings (lossless samples are on rarewares), just in case. I personaly found this unlistenable, and aoTuV is like cristal in comparison. What do you think?

Tried with other samples and my conclusion is that this encoder is not usable. Quality is poor and bitrate distribution weird. Bitrate is more than twice higher with a sample like debussy (known to be very quiet and therefore bitrate friendly with VBR encoder) compared to NewYorkCity (131 kbps vs 57 kbps with -aq 10).

Interesting... is there really any need for another fork though?  . Can't we just keep video/audio stuff seperate? Why don't these people do something useful for once like try playing around with 5.1 coupling wouldn't that be of the most interest to them? yes?

Interesting... is there really any need for another fork though?

Would a fork sound so poorly compared to his 'brother'? Isn't this encoder rather built from scratch?

N.B. Such project deserves a total respect for his author ; my criticism is about the encoder - not the developer nor all his effort.

This encoder is in very early stage ( ~1 month or so ) afaik, give it some more time before testing it.

Nobody has tested this encoder yet. What I did was a simple and quick evaluation. There's nothing wrong with it. The developer seems to be happy about the output quality and such enthousiasm should be for anyone insterested by audiocoding in general and vorbis in particular a real call for evaluation. No?

This encoder is in very early stage ( ~1 month or so ) afaik, give it some more time before testing it.

More like 1 week

Please calm down people, the "comparable to vorbis encoder", I should have put an emphasis on "to my ears".. at 90kbps, I can't tell them apart. But, yes, there is no psy model, and overall the encoder is nowhere near as good as the official one, just good enough to enter FFmpeg... I was just bragging at my amazing 1 week accomplishment.  Didn't mean for it to be taken so seriously.

I'll take any volunteers willing to help me with the psychoacoustics though, it is really not my field and I will probably never be able to make a good one for this encoder on my own.

Thank you for your interest, I'm really amazed how fast my encoder got notice! 

- ods15

What's the license on this code?

Oded Shimon, Please set the vendor string.

What's the license on this code?

LGPL...

Please calm down people, the "comparable to vorbis encoder", I should have put an emphasis on "to my ears".. at 90kbps, I can't tell them apart. But, yes, there is no psy model, and overall the encoder is nowhere near as good as the official one, just good enough to enter FFmpeg... I was just bragging at my amazing 1 week accomplishment. smile.gif Didn't mean for it to be taken so seriously.

I am sorry for being very critical, but I don't understand the point of reverse engineering the encoder? is it just for the purpose of using it within the FFMPEG project? What is the point? are you just playing around with the code and experimenting?

I am sorry for being very critical, but I don't understand the point of reverse engineering the encoder? is it just for the purpose of using it within the FFMPEG project? What is the point? are you just playing around with the code and experimenting?

I understand the point of Shimon reimplementing Vorbis - I imagine it's a terrific learning experience for a programmer, specially if he has a taste for DSP.


What I don't understand is FFMPEG featuring this encoder instead of the official one. FFMPEG is a very popular project, and I can only imagine people getting introduced to vorbis through it and saying "ewww, vorbis sucks, I'll go back to WMA". It can't be a licensing issue - official vorbis is under a far more permissive license than LGPL.

All in all, I believe FFMPEG are being very irresponsible adopting it as their Vorbis encoder. They use nothing but the best for MP3 encoding, why not do the same with Vorbis?

I understand the point of Shimon reimplementing Vorbis - I imagine it's a terrific learning experience for a programmer, specially if he has a taste for DSP.


What I don't understand is FFMPEG featuring this encoder instead of the official one. FFMPEG is a very popular project, and I can only imagine people getting introduced to vorbis through it and saying "ewww, vorbis sucks, I'll go back to WMA". It can't be a licensing issue - official vorbis is under a far more permissive license than LGPL.

All in all, I believe FFMPEG are being very irresponsible adopting it as their Vorbis encoder. They use nothing but the best for MP3 encoding, why not do the same with Vorbis?

This encoder is small enough to be converted to fixed point. If going this way, it would be a huge progress for Vorbis, and a quite interesting thing.
Regarding FFMPEG, it's right that a switch to select the Vorbis encoder to use would not hurt.

This is an interesting encoder - very small. Having 3rd party Vorbis implementations always is interesting to test-drive the spec. Quality is clearly much worse than libvorbis, but I hope the author keeps working on it.

For me it seems that the vorbis encoder isn't enabled by default when compiling ffmpeg. This sorta shows the experimental character - although labelling so in a more visible way may be advisable.

Did I mention Theora may be nice to have in ffmpeg, too?

(over at Xiph most people seem to think that the fact that ffmpeg implements plenty of patented methods may question the usability for free codecs, though)

All in all, I believe FFMPEG are being very irresponsible adopting it as their Vorbis encoder. They use nothing but the best for MP3 encoding, why not do the same with Vorbis?

Just take a look two lines below! FFmpeg supports encoding via external libvorbis for a long time.

Just take a look two lines below! FFmpeg supports encoding via external libvorbis for a long time.

Erm... of course I read two lines below. But it doesn't help anything if the default encoder is the crappy one.

It's the "default" one because it's implemented directly in libavcodec. That was the point for writing it in the first place.

The encoder will be selectable, Oded sent a patch for that. Just wait for some time guys

I tried a file encoded with this encoder on my portable (Maxfield Max-Diamond) for testing purposes. It's hanging whenever it sees that file. Unfortunately I put my test file into the root directory of the player - and it seems the player scans that directory on startup.

Now I have a dead player and I'll have to see how to empty it (it doesn't connect as USB mass storage device anymore).

And no, I absolutely don't blame the author of the ffmpeg Vorbis encoder. That's clearly a sign of poor firmware.

I tried a file encoded with this encoder on my portable (Maxfield Max-Diamond) for testing purposes. It's hanging whenever it sees that file. Unfortunately I put my test file into the root directory of the player - and it seems the player scans that directory on startup.

Now I have a dead player and I'll have to see how to empty it (it doesn't connect as USB mass storage device anymore).

And no, I absolutely don't blame the author of the ffmpeg Vorbis encoder. That's clearly a sign of poor firmware.

  Sorry about that, hope you fix it.

That's actually surprising though, my file's bitstream are very similar to the official Vorbis ones, The only big difference I can think of is having one only mode and one blocksize ...