I have read on this forum (and also on some others) many bad thinks about Ogg Vorbis... just take a look at some thread like "is Vorbis dead?" or "Vorbis vs AAC" and you will see what I mean.

I have made some time ago a preliminary listening test of Vorbis. My goal was to put all my CDs collection on a harddrive and manage it with a database. So I could listen all my music from my PC (connected to my stereo) without using (and risking to damage) my CDs. Because this database is the replacement of my CDs, I'll need a "true CD quality". I first tried to encode some of my disk with Lame MP3, but I've never been convinced by the MP3 quality. It's almost never really "transparent" for me. I also tried Ogg Vorbis wich I had never used before. I was really impressed, the quality was good and espcialy not so bad at low bitrate (-q0). I so I deed some ABX testing of original Wav vs MP3 (Lame 3.90.3 with presets) vs Ogg Vorbis (GT3b2). Unfortunatly I lost the ABX results so I could only give my observations in an other post :-( Basically, I found Ogg Vorbis better at low bitrate and transparent at -q7. I hope to have soon the time to redo a serious listening test includinc this time the new Vorbis tunings or some other codecs like AAC. I have access to a professional recording studio, so I will make the test there.

Anyway, all that to say that Ogg Vorbis is not so bad that I could read... Ogg Vorbis has many advantages :

1- it's really free and opensource
2- it's a true standard (many radios support it for streaming and you can now find some hardware player)
3- it sounds good at low bitrate (some aac encoders may be better is some case, but Vorbis is never very far)
4- it's transparent (for me and with GT3b2) at -q7 (Could anybody tell me the difference beetwin Vorbis -q7 and MPC at the same bitrate)
5- it's gapless

Of course everything is not perfect: Ogg Vorbis developpement is now very slow whereas Vorbis need some serious work to maintain its "credibility" towards its competitors (especialy AAC) :
1- improved sound quality (especially at medium bitrate (100-200kbps)
2- true mutichannel support (with multi channel coupling)
3- working bitrate peeling

So I would say that Xiph.org (and also tuners like Garf) gave us a nice present and some usefull tools :
- You need to encode some music for a portable player --> use Ogg Vorbis @ -q2 (or even -q0)
- You need to encode some music for your HiFi stereo --> use Ogg Vorbis (GT3b2) @ -q7
- You need to encode some music for lossless archiving --> use FLAC

All that is already fully functional and the chance we have it's that, even if not everything is perfect, it's GPL so we can improve it ourself if we need
So when I see disinterest of some for Vorbis and when I read that Vorbis has no future and that it's better to work on AAC, I can't understand
The only real issue with Ogg Vorbis is that the official Xiph version isn't improved for high bitrates, evolve very slowly and is doesn't seem very open to external propostions (like Garf tuning) ... So why not to create a fork of the Xiph's Vorbis project to improve it ? This way we could make Vorbis better:
-> Actual tuners and maybe MPC or Lame developper's could improve the sound quality
-> Some could work on mutichannel coupling and 5.1 support
-> It would be great if some could also help on better integration with Matroska
-> And what about bitrate peeling ? Does it need to huge work to be working ?
This way Vorbis could be a real competitor to AAC (same features like mutichannel but fully free) and a replacement for MPC (same quality at middle and high bitrates but fully free and with hardware players).

Just some ideas ... your comments are welcome.

Hmm... Monthly "The future of Vorbis" thread...

-Eugene

vorbis does a splendid job considering it's achieved it all without using any patented technologies.

i think a lot of issues have been discussed before, but you make a good point about channel coupling. i'm sure once Xiph (or anybody else developing vorbis) cracks this problem, there will be much faster development in Vorbis. unfortunately, it looks like it's current channel correlation for stereo causes some problems that need to be sorted (i refer to "HF boost").

i remember some talk about implementing ambisonics into Vorbis. this would be a breakthrough - a b-format (3 "axes" and 1 sum channel) vorbis could be decoded into 5.1, quad, 7.1, 9.1, 31.1, etc etc etc without much bother at all, and as a consequence, adding channels into the mix wont affect bitrate if all works well. ambisonics also includes height information. this would be super cool for action movies (though i've never heard of this channel being used ever)

i just hope these things are actually being developed, if a little quietly and slowly.

another thing vorbis needs is to become more marketable. maybe a few of the friendlier online stores could offer a vorbis option (isn't there a russian one that will encode on demand from lossless to the client's choice of encoder?). but if that happens, no doubt pressure would be put on Xiph.org to implement DRM into their codec. that would be a tragedy, and would completely kill vorbis as a codec - right now it subsists on a diet of geeks, and if we leave because of DRM, there'd be nothing left.

after i opened the "is vorbis dead" thread i tried out some other codecs and i have to say, that vorbis is maybe not the best codec in encoding quality but it is the most complete encoder. other codecs are maybe better in quality but tagging is a pain or they don't support replaygain, gapless playback or there are no binaries available, because they are not open source / etc.

there is nothing about vorbis that is completely bad (okay, that development has stopped so far is really bad) which can be said about any other codec out there (imho)

It's a recurring theme. Soon someone will also start a thread mourning the loss of r3mix.

Just my 0.02EUR:

Vorbis and Xiph.org are far from dead.

• Xiph.org is developing it (Monty is working on proper 5.1 support right now among other things and a 1.0.2 release with the recent ABR/CBR improvments should be immanent)
  
• Independent developers like Quantum Knot and ayumi are working very actively on improving the current Vorbis encoder and solving its problems.
• Hardware support is slowly coming
• Pretty wide software support is already there and the core tools/libraries are mature and usable.
• IceShare will make Vorbis even more interesting for independent broadcasters like IndyMedia
• The other Xiph.org projects are doing well too with Icecast having just had its long awaited 1.0 release and libogg2/Theora constantly improving.

It might not be as flashing and exciting as it was two years ago or as MP4/AAC is now, but progress is being made and there are some very interesting technologies being developed.

One of the things that is definetly lacking is proper release management: The Vorbis 1.0.2 code has been ready since 2004-01 and end users are still waiting for an official release.

À propos... Where is the r3mix preset?

I also don´t think Vorbis is dead (although it certainly won´t conquer the world). It simply gets the job done and happens to suit my needs very well.

(I think it´s important for xiph.org to get that OggFile library out of the door. (OggFile is a library to work with all xiph-codecs in a unified way). At the time being every single codec has to be supported on its own by application developers.)

yes... but in a more optimistic way I think


That's indeed a very important aspect of Vorbis: It's now the only (lossy) codec wich can be use for free without to infringe any patent. Codec like Lame or Faac should be used for educationnal purpose only ;-)


Vorbis as a replacement for MP3 should be used by anybody. Why so many people are still using mp3 or wma for low bitrate encoding? I hope time, more hardware support and better tuning will help in changing this :-)
And about DRM, I don't see in what an open DRM system is a problem : If an open DRM means a standard commonly used by all softwares or hardwares and if it can help professionals to adopt open tools as Vorbis or Matroska, I can't in what it is bad. As an artist and a producer, I may find usefull to "protect" the files I could distribute.
DRM is not an obligation... you could have DRM "protected" files for commercial or copyrighted stuffs and files without DRM for free stuffs... In any case you won't be imposed a specific hardware or OS to read the DRM "protected" files. In that way, DRM can be a good think (IMHO).
Another question one can ask is the real utility of DRM: If I download an AAC DRM encrypted file on Apple's itunes, I already can find a software to remove the DRM protection and so to distribute the file without my "signature"... So I guess DRM is only usefull to dissuade novice users to distribute their files and to reassure the majors ;-) In any case, good citizenship and respect of the authors/artists is the best protection against piracy (IMHO)


Very good news!!! Is Monty working alone? why could QK or ayumi not be part of the official developpement? I'm halas not a programmer, but I guess there are some programmers who could and may want to help Vorbis developpement... Why is the Vorbis developpement seemed to have a very "closed" or "confidential" aspect compared to other open source softwares ?
Hardware support is slowly coming... It's even already there and I guess the patents free aspect of Vorbis will help in more and more hardware or software to support it :-)

For me, Vorbis is good enough for my mortal ears, plus it's open source so it serves as an interesting project to learn and tinker with. The only major things-to-do are:

1. Fixing the HF boost/noise problem - The recent 3rd party tunings are addressing this problem and Monty is also on the way to fixing this.
2. 5.1 channel coupling - This is something high on Monty's Vorbis priorities list as Vorbis is being considered for inclusion in the EVD standard.
3. Improving noise normalisation for low bit-rates - Again, Monty has signalled that this will be his objective for the next major release.
4. Dealing with pre-echo without bit-rate inflation - While pre-echo can be readily dealt with (as seen in GT3b1/2), it comes at the cost of inflated bit-rates. If iTunes AAC @ 128 kbps CBR can handle castanets better than Vorbis 1.0.1 @ q 4 VBR, then there needs to be a more imaginative (non-patented) way
5. Not quality related, but Vorbis' patent situation must be clarified in order to get the big companies to support it. Recently I heard someone say that one of the people at Apple who deals with the iTunes/iPod said that they haven't been considering support for Vorbis because of the uncertainty of patent infringements. Saying Vorbis is patent-free doesn't really say much, unless something concrete can be provided. If Xiph.Org can come up with some concrete evidence that Vorbis is not infringing on any patents, then I'm sure the hardware support will start coming.

I agree with the above, and would add the ability to do cross-platform compiling (OSX is the sore point right now). It hasnt compiled successfully since 1.0. I check it about once a month on the CVS, and I'm stuck with that (1.0) at the moment since I dont use windows.

I know the HF issue exists, but instead of having people go back, and re-encode everything, why not just do the 2db reduction in the player (have it detect streams made with old versions, and voila). Blasphemy I know, but hey, its a thought. The player is (to my knowledge) only frozen in that backward compatability is required, someone correct me if I'm wrong.

-- Page

hmm. i think my point about DRM may have been misunderstood.

in the current climate, a new format will not be commercially adopted unless it has DRM. it's a necessity.

vorbis and xiph can never have DRM in their current ideological makeup - think about it. they release a patent-free, open source DRM scheme. how useful will that be? no use at all. it's like the germans handing the english an "enigma" pamphlet before the start of WWII explaining clearly how their machine worked and how to decrypt their secret messages.

but of course, commercial adoption isn't nearly what it's cracked up to be, and vorbis's selling point with the punters is precisely the opposite concept of DRM - that is complete freedom.

they should do well, but with an agenda like that, they'll have some very very hostile and powerful competition in Microsoft/Thompson/RIAA/US gov/etc.

it'll be a hell of a ride though i know which side i'm taking...

MugFunky,

The encryption should be protected by the key rather than the obscurity of the algorithm. Encryption by obscurity is no encryption at all. It just gives you a false sense of security, which is worse than no security at all. Every encryption expert can tell you that the only way to create strong encryptions is putting into public domain so it can get a lot of peer reviews. Again the key is the "key". Just look at acrobat pdf and M$ Word encryptions in the past. They were all broken and all turned out to be cryptographically laughably primitive, so all those punters who trusted these companies were screwed. At the same time gnupg which was always open has not been compromised yet. (There was recently a bug found thanks to a peer review, but that configuration was not widely used.)

All I am saying is that if the music industry would be a tiny bit astute, they would develop an open source DRM because the key is the encryption key and the not algorithm.

Triza

I doubt that any DRM system will ever be near secure. These obscure algorithms are an integral part of protection until they are reverse engineered. IMHO "DRM" ist just something to calm down the music industry (to make online shops like iTMS possible). The main purpose of cryptography is to hide something from an eavesdropper and to make something authentic. Sending encrypted songs to a customer is pretty much nonsense because he (technically) kowns the key and is able to decrypt it and share it with other ppl... => problem not solved.

I guess it's very hard (if not impossible) to design a secure DRM system. This would explain these inferior systems already known.

bye,
SebastianG

Exactly !

You're correct, it is totally impossible to make a secure DRM scheme using pure software running on general-purpose (ie: untrusted) hardware.

For a DRM scheme to be secure, the keys must stay in a tamper-proof place. Usually that means on-die memory in a cryptoprocessor. This implies that any player which wants to decode these "secure-DRM" files must include such a chip.

For obvious reasons, the D/A conversion must be done inside the crypto chip too. Which can bring audio quality concerns (power supply etc).

Everything (except the decryption key) can be known to everyone. Of course, if the chip design is publicly known, the real problem is to make any "careful opening" of the chip impossible.

The other possibility is a "safe place" for the sensitive software to run, and this is called "NGSCB" (ex-Palladium) in microsoft's words. With CPU support and very careful software design, "breaking it" could mean "breaking into the CPU".

Time will tell..

I'd say very hard, but not impossible.

I'd say impossible. Every software can be reverse-engineered. If it can be played it can be broken.
btw: Even programs implemented in hardware can be reverse-engineered. It might be harder, though.

Isn't DRM for Ogg already available or being worked on?? I read something about this a long time ago on Slashdot.

Well, so far no one has cracked the encryption on DVD-audio, but since you need hardware (audigy2) to decode it, i guess this is an example of hardware implemented encryption.

Too bad, i would love to rip some multichannel lossy files off DVD-audio discs

I guess DRM is only usefull for streaming (Pay Per View TV or radio)... It may do not have a sens for files distribution: Any user who can read/play a file can de facto copy it. The only powerfull protection would be some kind of files compressed (encoded) is a way it could not be reencoded without many degradation. But I don't think any codec would be able to encode any data (audio or video) with a good quality this way


Yes indeed... it's like the encryption feature of the DVD audio... Today anybody can easily find the tools to decrypt a DVD and so copy or reencode it ; but DVD publishers still encrypt the DVD (and pay the licence to do it !!!).
Anyway, if a DRM feature could help the music industry to adopt Vorbis, so it's a must IMHO. And the same applies to Matroska IMHO!

But I repeat :
In any case, good citizenship and RESPECT of the authors/artists is the best protection against piracy (IMHO)
would you pirate the work of an artist you really like? I guess not...

I can agree, but the correct argument would depend on the definition of "secure".

Breaking software is, for all practical purposes, just a matter of time. You can do any modification to it, see the results immediately, etc. You can even train a neural network to try things. Plus you never need to break the crypto.. only the logic around it..

"If allowed to play then decrypt with key.."

You only need to break the "If".

On the other hand, breaking even off-the-shelf hardware requires very expensive equipment.

Further on, breaking tamper-proof hardware is almost impossible. It is designed to break when you open it (assuming that you can).

Even a badly designed chip, will require techniques such as this.

The challenge is to build hardware that cannot be opened, and whose activity cannot be examined or measured from outside..

Xiph.org doesn´t work on DRM AFAIK. However, it should be possible (although not currently supported) to use Vorbis inside the Helix-DRM container from Real.

http://www.realnetworks.com/products/drm/

You should try to think in a different way.
The security part of DRM (DRM is more than security) is not necessary based on encryption...

Vorbis sure is alive and kicking. Anyone played Unreal Tournament 2004 recently?

Oh that sucks. I have heard of some things in 1.0.1 that won't compile properly under win32 either though the most important ones (libogg, libvorbis, and oggenc) still work. Xiph.Org are aware of the problem though so it will get fixed eventually.

What errors are you getting in compiling 1.0.1 on OS X?

There is already a generic encryption system built in to Matroska. You can find more information about it here.

Essentially, you can define whatever encryption scheme you want to use on your files without adding/changing the Matroska specs. An interesting thing about it is that since the encryption occurs at the stream's packet level, and not the container level, you could copy, edit, cut, etc. the stream without ever decrypting it. But if you want to play it back, you must decrpyt it.

Another interesting feature is that it allows multiple levels of encryption. So, you could have the data encrypted 20 times, each with a different type of encryption. This could possibly useful if you wanted to use more than one system of DRM at the same time.

However, having this incredibly flexible encryption system built into Matroska is not the same as having a DRM system. It simply means that theoretically any DRM system could plug into the current Matroska system with little effort. The Matroska project itself has little do with this directly in that it is really outside the scope of a single container. (Linus has said the same of DRM within Linux.)

But, the work of the Matroska team often extends far beyond the container project itself as it is often necessary to fix other things to take advantage of what has been designed. So, some members of the Matroska team have already expressed an interest in an OpenDRM system. The biggest issue right now is time to develop a structure as complex as a DRM system.

As has been stated previously, open encryption systems are perfectly safe. In fact, having the code open for peer review can make it even safer. DRM for multimedia simply extends the same principle into two problematic areas.

1. Key transmission.
2. Decrypted and De-compressed content output

Storing the key for a significant amount of time is not safe because the method used to store the key may be compromised if the storage system is reverse engineered. So, your only option is to obtain the key from something (ex: internet) when you want to play. (Caching the key for a short time hours, days would likely be acceptable.) The transmission system would be encrypted and would have the same chance of compromise that the storage system would have. This is because the keys necessary to decrypt the transmitted key have to be stored within the program itself. The difference is that as soon as a compromise was discovered for the transmission system, the internet server could be shut down for a short time while an update was released that fixed the compromise and change the transmission key.

The problematic issue is the protection of decrypted or decompressed content. If decompression and decryption occur in the same space, then it shouldn't be hard to protect the decrytped content. But at some point you are going to have to output the decompressed content to another system that isn't necessarily secure. In Windows this is impossible as you can always capture video from overlay and audio from digital audio outs. Of course, you are recompressing content, and so losing quality, but it is usually within an acceptable margin.

So, the biggest issue with having any DRM multimedia system is the output of the decompressed content. This means that have a completely secure DRM (closed or open), you would need all secure hardware that prevented copying. Good luck. The most that anyone can hope for is 'mostly secure', which is perfectly doable in an open fashion.

absolutely... and that's the precise reason why software-based DRM is so easy to break.
The system is only as secure as its weakest component.

In software DRM, the weak components are:
- DRM logic (may I play the song?)
- key storage

The strong components are:
- encryption.

In hardware DRM the weak components are suddenly made much, much stronger. Then (assuming that the encryption is adequate -- which is easy to do nowadays) the system can withstand attacks.

You contradict yourself a little here - first you say "by anybody" and then you talk about low-bitrate streaming tasks.

I did give vorbis a try about 2 years ago - i waited for quite a long time(about a year i think) for the HF-issues to be fixed by xiph... but nothing happened. Maybe you think i'm a bit picky... but i asure you i'm not: the HF-noise most of the time causes listening fatique to me and sometimes i even get slight headaches from it. I'm not exaggerating - maybe i'm just very sensitive to this bug. However, what this means is that remained true to a codec which sometimes even causes headaches to me in mid-bitrates, patiently waiting for xiph to fix it - and after a year went back to lame --preset standard because contrary to vorbis, this one did not suffer from that problem.

I agree however, that vorbis may be worth a revisit in some months or so when the HF-problems are (finally) solved. And, i still often use vorbis for streaming and low-bitrate tasks - just not for causal listening tasks.

- Lyx

Interestingly, Microsoft has apparently shelved Palladium/NGSCB development for the time being in favor of some implementation using the 'NX bit' in AMD64.
The installed base of AMD64 machines is of course still quite small and the current implementation of AMD64 by Intel (IA-32E) has not yet implemented the no execute function contrary to the implication of the first article.

Yes! Gaming audio certainly doesn't require lossless

But it surely requires more than what is found in most games today...

...NFSU at 22kHz for instance.

A little update on "Palladium" can be found here.

I think the most salient point is this:




Require is a pretty strong word but I totally agree, 22KHz sampling is at least 11KHz too little for my taste I've noticed the sound quality can vary a bit depending on which 3D sound API you select in the game. EAX seems to be consistently "okay" but fuzzy and "reverbery". I usually notice the clearest audio with RAD or Miles, which are software. Still doesn't do anything for low sampling rates.

going a bit off topic...
EAX is really crappy, if you've ever played with the DSP. What was amazing was A3D... I remember an A3D demo where sound generators were all in different rooms with different room properties. And there were all these great effects like, if there is a wall or door between you and the sound, the sound becomes dampened. Step out or open the door, the sound becomes brighter.

Too bad Creative Labs killed A3D. Thanks to them advancements in game audio haven't moved an inch since 1999.

1 -> Is this a cooperative work? I mean are you working alone or in collaboration with Monty? (I any case, thanks for your very usefull work )

2 -> Great! I hope that will this work soon. By the way, do you know if the actual multichannel feature of Ogg Vorbis permits to choose different quality for each channel (-q5 for channel Front L, Front R, Front Center, -q3 for surround L / R and -q0 for subwoofer) ? I also wonder if it's possible to share or "distribute" the bandwidth through all channels; I mean If one channel need at one time a lower bitrate, it will give other channels more bandwidth... such a thing could be called "bitrate banlancing"

3 -> Ok, lets wait for the next major release... 1.1 or 2.0 ?

4 -> I'm sure we are very close to find the solution

5 -> How can the sitution be clarified? Who could help in this? About Apple, I think they did not choose Vorbis for commercial reasons: AAC is an industry standard and has DRM, wich it's more comforting for Apple. Vorbis is so "open" that it could appear as less "controllable".
About Vorbis' paten situation, I wonder something : Could somebody, in the future, patent some technologies used in Vorbis? Isn't that a risk?

And from one of my previous posts ---> What about bitrate peeling? is somebody working on this or is this feature dropped?

3rd-party developers here at HA.org do have some sort collaboration if I´m not mistaken (it seems future QuantumKnot tunings will base on aoTuV).

About collaboration with xiph.org: I simply don´t know



A feature like "bitrate balancing" is only useful in CBR. Vorbis already uses as much bits as needed/useful.

As for the first feature you mention... a quote from Vorbis I spec:






Next major release: Vorbis 1.1 AFAIK




No. Prior art.



There are a lot of projects with higher priorities over at xiph.org