Slashdot Mirror
Vorbis And Musepack Win 128kbps Multiformat Test
technology is sexy writes "After 11 days of collecting results Roberto Amorim today announced the results of his 2nd Multi-Format listening test: Vorbis fork AoTuV scored the highest and ranks as the winner together with open source contender Musepack closely followed by Apple's AAC implementation and LAME MP3, which improved markably since last year thanks to further tunings of its VBR model done by Gabriel Bouvigne. Sony's ATRAC3 format ranks last after WMA on the third place. The suprising success of AoTuV (compared to last year's performance of Xiph.org's reference implementation) shows the potential of Vorbis and possible room for further tuning and improvments. Take a look at the detailed results and their discussion at Hydrogenaudio.org."
LRC, the best-read libertarian site on the web
Because this was designed to test various codecs at 128Kbps. You can't make flac do 128Kbps. Besides, flac, being lossless, sounds exactly the same as the source media, so what's the point of testing how it sounds?
You have a point. There are devices however such as from iRiver which can play Ogg Vorbis and the winning encoder/codec in the Slashdot story AoTuV seems to be just an encoder fork which is bitstream compatible with Ogg Vorbis.
Banu
It was a double blind test (ABC/HR) adhering to ITU-R BS.1116-1. Read more about the methodology in the initial announcement.
In addition to being double blind results were also encrypted so manipulation is very unlikely.
its important to point out two things especially:
WMA brought clearly worse quality than (good old) MP3 at 128kbps
itunes AAC brought clearly better quality than WMA at 128kbps
so why should anyone even a minute consider buying crap quality wma encodes at napster, coca-cola, walmart or however the wma-based music stores are called?
on the legal way -> itunes is better
on the illegal way -> even old mp3 (next to vorbis or aac) is better
1) Is it really a codec? Seems to me it is a compression method for media, like .zip .tar etc., not an encoder... technically.
.zip/.gzip are very poor at compressing audio recordings. FLAC and similar lossless audio compression look for things like (I would imagine) relatively small deltas from each sample point to the next, since this is a common characteristic of audio data.
Compressers are encoders of a particular variety. They just choose a different data representation as an encoder does, but make an effort to take advantage of specific known characteristics of the data they are compressing to get a smaller, reasonable representation..
ZIP and gzip (tar does not do compression, just file joining) do very poorly at compressing audio. They do things like look for patterns of repeating (or at least commonly seen) sequences of data, and simply say something like "every time you see "z1", I really mean ";lt&a href="". This approach often works very well in computer-generated files.
However, it's very unlikely that you will get exactly the same sequence of bits in an audio recording, so
FLAC is indeed lossless.
May we never see th
Well, I can only comment from a technical point of view, but firstly it is very good news that we are progressing in the right direction in terms of quality. Secondly, compared with the other codecs (esp. the proprietary ones), Vorbis is quite simple and minimalistic and lacks a lot of advanced tools and profiles, yet we've been able to extract quite competitive performance from some adjustments here and there. There is more to do in Vorbis and Monty has some new ideas that he wants to implement in the next major version like a better stereo model, noise normalization (which in its current form is mostly experimental), and support for 5.1 stereo. Given the success of aoTuV and the fact that Monty is fully aware of these third-party tunings, I think Vorbis development is looking ever-more exciting. :)
(Note I don't work for Xiph.Org but just one of those third party Vorbis tuners)
No, because having an audio spectrum which is actually close to the original is much less important than having one which sounds the same to a human being. We don't understand exactly how all that masking of sounds etc. works yet, and so just because codec A replicates the frequency spread of an original piece more accurately than codec B doesn't necessarily mean that it'll sound better to you or me. This is still, to some degree, a black art. The only device which can properly measure the relative performance of the various codecs is the good old human ear. It can't be automated effectively.
The DAC in the iPod is fairly high quality. It is not unreasonable for someone to simply encode their CDs using Apple's lossless codec and put them on the iPod. With a 40G model around 60 albums (assuming an average size of 650M) could be stored losslessy in WAV; a few more using Apple's lossless encoder. It would be like turning your 40G iPod into a 5G iPod and swapping music around but such is life.
It becomes more realistic when you have 80G and 100G drives in your player; in a few months the Neuros is supposed to have 80G backpacks available (right now up to 40G are available and a few online stores are advertising the availability of the 80G model early) and you can order an 80G backpack right now from Cool4u2View. The Neuros doesn't support any lossless codecs except for WAV right now (although there is support for WMA I have never used it and do not know if it supports WMA lossless or even if WMA lossless is anything more than tagged WAV). 80G is still around 110 albums. The Neuros IIRC uses the same DAC as the iPod so the quality of the sound would be excellent.
For me -b 160kbps Vorbis files are good enough; I plan to re-encode my collection to FLAC when I get a larger HD for music (right now it is a poor little 20G that only has 4G free) as well as Vorbis (abcde makes it easy to encode to more than one format and put them in different directories) -q5 (for my Neuros).
So your last comment still applies to most people. Not everyone though.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
The way it works is, you listen to a given music clip. You have three streams to choose from. One is the uncompressed .wav, and is labeled as such. The other two are not identified, and consist of the compressed source and the original source. You then rate the two unidentified sources based on how closely they approximate the original. Then you repeat the process five times for each of the codecs. When you're performing the experiment, you don't even know which codec you're testing at any given time.
There are devices however such as from iRiver which can play Ogg Vorbis
I was one of those nincompoops who rushed out and bought one the moment I read the words "iRiver" and "Ogg" in the same sentence, but when I updated its firmware the latest version with Ogg Vorbis support, I found that many of my files wouldn't play.
It turns out that most of the iRiver players with Ogg support added have a half-baked implementation and support only a limited range of bit-rates and frequencies. The iFP-300 series, to which my player belongs, only supports 96Kbps - 360Kbps (if it's a VBR file and the bitrate drops above or below that, distortion occurs), and also has trouble with files encoded in less commonly used frequences (i.e. lower than 44.1KHz).
In case anyone like me thought iRiver was committed to improving their Ogg support, their latest iFP series players are even more limited, supporting only 96Kbps - 225Kbps at 44.1KHz. Their new iDP series doesn't support Ogg at all. And owners of the iMP have been waiting months for Ogg support which still has not materialised.
Only the H series supports a decent range of Ogg Vorbis bitrates, but even it only officially supports one frequency (44.1KHz).
It's odd to keep hearing this code referred to as a 'fork'. Yes, it's based on our reference code while doing further tuning just like all the free MP3 encoders are based off of the original dist8 or dist10.
Fork seems to imply that they're trying to make something incompatible or doing it without our blessing. Neither is true! We never wanted to have *the* only encoder. Nor did we want to be the only people trying to improve Vorbis's encoding.
AoTuV is a 100% real Vorbis encoder and the results of the test speak for themselves. Aoyumi and crew deserve kudos, and I'm glad to see them working on improving Vorbis encoding.
Monty
The speed of CDparanoia is not limited by the cdparanoia code. Regardless of future improvements, speed gain would never be one of them. If anything, additional error correction would only ever make it slower. Your limit is Linux forcing programmed I/O because the IDE subsystem doesn't know how to use DMA on non-multiple-of-512-byte sector sizes. CDDA is 2532 bytes per sector. Linux 2.6 partially fixes this.
;-)
Also, cdparanoia (III) was finished long ago. It has not bitrotted. As new kernels came out, we+others kept it up to date. The distribution maintainers have added whatever fixes have been necessary for their distros. Nothing that worked in 1999 is broken today.
In summary... paranoia does 100% of what *I* need it to. I write software that I need. I don't have to keep releasing 'improved' versions of software that already works as an ego-trip or to placate a marketing department desperate to sell you the same thing in a new box every six months.
Others have expressed interest in doing new things with paranoia, but no one has followed through... at least not yet. Paranoia isn't all that complicated to use or hack. That speaks to a pretty damned low demand for new versions.
The website: yah, OK, I'm lousy at writing HTML updates. My diary hasn't been updated in three years. There is certainly a website attention span problem
Theora: I'm not one of the primary coders today, I only did the initial code import. Also, the Helix project has required relatively little time; Real has done nearly all the heavy lifting on integration there.But, if 'Theora is dead', why does CIA show 500 commits in the past two months?
DirectShow issues can be summed up as 'ugh, what an awful system'. But we'll make it work. The discussion about mux was proposed changes to spec. Voluminous discussion reveals what we have now is still the best option, as designed five years ago.
Monty