Vorbis 1.1

Topic: Vorbis 1.1 (Read 24383 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #25 – 2003-12-22 00:19:32

So, I'm guessing anything that is not MP3 is a modern codec

Vorbis 1.1

Reply #26 – 2003-12-22 03:33:15

I would hope for simultaneous improvement of Vorbis 1 & development of Vorbis 2. That way some momentum *is* kept up in the transition.

But then, we're all speculating over a few snippets of conversation... hopefully some more conclusive announcements will come forth from Xiph.

Vorbis 1.1

Reply #27 – 2003-12-22 14:03:17

Quote

Quote

Don't know much about music, but for movie audio current AAC-HE implementation (nero) is really bad.
For this content Vorbis 1.0.1 at -q1 is clearly better and give same bitrate.

Kinda weird.

Question: how do you process the audio when encoding to Vorbis? (I assume Recode 2 for HE-AAC)

Most tools do dynamics compression during the Vorbis conversion, which makes the audio sound a lot better when listening on a PC.

IMHO Recode2 should also offer this, but I think you can get the same effect by doing a manual encode/mux. I'm still playing with tweaking the video encoding right now

I use same transcoding utility for both AAC-HE and Vorbis encoding, BeSweet 1.5b23.

for 2ch Vorbis:

Code: [Select]

BeSweet.exe -core( -input "input.ac3" -output "output.ogg" ) -azid( -s stereo -c light -L -3db --maximize ) -ogg ( -q 0.1 )

(with BeSweet, -q 0.1 corresponds to standard ogg -q 1)

2ch AAC-HE (using recent Nero AAC DLLs and 70Kb/s VBR profile):

Code: [Select]

BeSweet.exe -core( -input "input.ac3" -output "output.ogg" ) -azid( -s stereo -c light -L -3db --maximize ) -ssrc( --rate 44100 ) -bsn( -2ch -config )

6ch Vorbis:

Code: [Select]

BeSweet.exe -core( -input "input.ac3" -output "output.ogg" ) -azid( -c light --maximize ) -ogg ( -q 0 -6ch )

6ch AAC-HE (using recent Nero AAC DLLs and 70Kb/s VBR profile):

Code: [Select]

BeSweet.exe -core( -input "input.ac3" -output "output.ogg" ) -azid( -c light --maximize ) -ssrc( --rate 44100 ) -bsn ( -6chnew -config )

Vorbis seems more "fuzzy" keeping background and low volume sounds sweetly audible (or at least clamping them sweetly), while in my ears AAC-HE pays some threshold based filtering approach and thus failing to give a global image of the original sound (foreground and background). Also in AAC-HE file, the actors voice is _clearly_ different from the AC3 one (pre-echo problem I think).

(and I want say that I have always haten every _threshold_ based approach both in video and audio filtering)

Vorbis 1.1

Reply #28 – 2004-01-03 01:11:34

Quote

*Lossless encoding incorporated into vorbis (WMA style, one codec all options). Maybe FLAC can be merged with vorbis for this.

I must say these are the sort of things which I consider a complete waste of time. Vorbis is lossy and it is supposed to be lossy. If you want lossless choose FLAC. But it is pointless to squeeze it into Vorbis because that is why we have the ogg container format. Ogg can contain Vorbis (-> lossy) and FLAC (-> lossless). There is no need for this mishmash. I want real features (such as integrating Garf tuning and Vorbis II stuff you talk about there) not these sort of pointless exercises.

Besides there is a bigger problem. When I want to go lossless I do not want to use Vorbis because it is more likely that somebody wishing to encode lossless and by screwing up the command line parameters or tickboxes on the UI will create lossy. Not to mention the uninitated masses who will get confused and screw things up out of ignorance or lack of knowledge. To avoid these sort of accidents lossy and lossless should be kept as separate as possible. If you want integration put it into ogg container. As far as I am concerned I stick with FLAC as .flac files and let Josh concentrate on FLAC and Monty on Vorbis.

Another thing is that SW projects are complex enough. One has to keep it simple stupid to reduce bugs so break it down to small self contained SW (lossy and lossless) instead of integrating. There is a saying in engineering which says that you reach perfection no when there is nothing to add, but when there is nothing to remover.

I chose FLAC for numerous reasons, but I must admit the following statement on FLAC site appealed to be a great deal:

What FLAC is not:

* Lossy. FLAC is intended for lossless compression only, as there are many good lossy formats already, such as Vorbis, MPC, and MP3 (see LAME for an excellent open-source implementation).

Sorry for getting carried away, but in my line of work I constantly battle against these sort of attemps and also I love FLAC as it is.

Vorbis 1.1

Reply #29 – 2004-01-03 02:19:14

I must say that I am just embark to transcode my FLAC archive into either Vorbis or Lame - MP3. OK it will be easy to transcode in the future by scripts, but I still want some stability.
So far MP3 was a little ahead because I know that MP3 will never go away (by being the 1st). Still I love freeness and the ease of tagging and gaplessness of Ogg. However Ogg slow to take on board quality improvements (such as Garf's work, which is tested by a lot of individuals on this forum). Not that I have good ears, but it sends out the wrong message. And they already seemingly moving on by talking of Vorbis II. This I think will kill any incentive to support ogg by HW manufacturers. What we need is some stability and absolute crossplatform (PC Linux MAC) support, which I think ogg posseses. I think FLAC-s emergence in the lossless world is due to these simple concepts. Personally I do not want to count the bit rate because the storage and transmission bandwidth is getting better and 90-128 kbit/s will cut it in the future, so Ogg should compete on stability with more simple tuning. What we need is stability. I do not see this coming so as it stands I'll probably go for Lame - MP3. I am never gonna go in the AAC way, so I think evetually I will sign up to Xing movement, but probably not now apart from using FLAC, which was also chosen by Xing, and which was a very very good choice.

Vorbis 1.1

Reply #30 – 2004-01-03 07:23:52

Quote

There is a saying in engineering which says that you reach perfection no when there is nothing to add, but when there is nothing to remover.

Well, what about convenience? I personally think it would be great if there was one encoder for all of xiph’s audio formats. Just like the oggdropXPdS can choose between vorbis 1.0.1 and GT3b1 dynamically, there could be a drop down menu in a similar program which would encode speech, lossy and lossless.

Quote

When I want to go lossless I do not want to use Vorbis

I guess I wasn’t clear enough on this (totally my fault). I was referring to (as mentioned above) having one encoder with all options. The vorbis and flac libraries do not have to be merged for this purpose, as I wrote in the earlier post. That is not what I had in mind. What I wanted to say was that the encoding front-end be modified and not the encoder libraries. The end product will be .flac or .ogg depending on which format you chose to encode but the encoder does not change with format. Thanks for bringing this up.

Quote

somebody wishing to encode lossless and by screwing up the command line parameters or tickboxes on the UI will create lossy.

Someone dumb enough to this should not be using command line parameters in the first place. And for people like them, an integrated encoder would be the way out.

Quote

Another thing is that SW projects are complex enough. One has to keep it simple stupid to reduce bugs so break it down to small self contained SW (lossy and lossless) instead of integrating

Well, what is the point of having software which is not convenient to use? I have to completely disagree with you on this point. Whether the SW is complex or not does not matter to the end user. The only thing which matters is convenience. And the way I see it, integration is convenience.

Quote

Not to mention the uninitated masses who will get confused and screw things up out of ignorance or lack of knowledge.

A great majority of the people out there do not even know about lossy/lossless formats. Having an integrated encoder will at least spread this knowledge amongst the uninitiated masses. Yes, there will be some confusion initially, but then what are FAQs and forums like this meant for? They won’t use it if they don’t have it. They won’t have it if we don’t give it to them. And what better place to do that, than the encoder itself.

Quote

let Josh concentrate on FLAC and Monty on Vorbis.

Couldn’t agree with you more.

Quote

Sorry for getting carried away, but in my line of work I constantly battle against these sort of attemps and also I love FLAC as it is.

No problem buddy. We are all entitled to an opinion and they may differ. And we all love FLAC as well.

Vorbis 1.1

Reply #31 – 2004-01-06 23:54:17

Quote

so I think evetually I will sign up to Xing movement, but probably not now apart from using FLAC, which was also chosen by Xing, and which was a very very good choice.

Just a minor point....I think you mean Xiph rather than Xing which is the company that produced the lightning fast mp3 encoder.

Vorbis 1.1

Reply #32 – 2004-01-07 16:06:05

Quote

I personally think it would be great if there was one encoder for all of xiph’s audio formats.

IIRC Monty is working on OggFile: A library which gives a single interface to all Ogg codecs (AFAIK). Should be "simple" to write a single "encoder to rule them all" with OggFile....

Vorbis 1.1

Reply #33 – 2004-01-07 17:38:23

Quote

From the same meeting at http://www.xiph.org/minutes/2003/december/raw/

Quote
19:31 < xiphmont> Anyway, my blocking scheme is too simple to scale below our current low-bitrate. The frame size at the lowest rates is dominated by housekeeping and overcoming the transfer function of the window.

I guess that's what Monty means by 'baggage'.

Quote
19:32 < xiphmont> Anyway, that's just technical. I've become convinced we need to rev incompatably in the next few years and really, sooner is better than later. Right now, Vorbis is the oldest of the modern audio codecs.

If only he realised 2 years ago it was the 'oldest of the modern audio codecs'. :(

My thinking is very much in flux, and that's mostly some thinking aloud. Don't take any of it as gospel.

But to clarify, 'baggage' means floor 0 and tessellated codebooks. I am now convinced neither will ever really be useful again in the future. They should be dropped from the spec... eventually. This is the primary way in which Vorbis II would be a simplification over Vorbis I. Probably also drop mapping 0's submappings which haven't gotten used yet and replace them with something simpler/more general.

...and two years ago, Vorbis I was not the oldest of the modern audio codecs. All of Real, AAC and WMA have revved to new (and incompatable) versions in that time. Vorbis was the newest format when it started, but now it's the only audio codec to not make incompatable bitstream changes (where new files do not play in old decoders) in the past three years.

We will not drop Vorbis I, even when we go to Vorbis II. However, the rest of the industry has made it very clear: they will opt for performance over bitstream compatability at any point.... heck, AAC is allegedly revving incompatably again within the next year. The only thing the same about the competition in 1999 and the competition today is that they've kept the same name on their codecs.

We're committed to keeping up (I've said for a while, this race will see alot of leapfrogging back and forth. We were clearly superior to AAC for several years, now AAC is ahead, and we'll be back on top again in the next year or two, ad infinitum) and as such, will release new codec versions to do so. And, FWIW, Vorbis II is not two months from now... it's longer than that. There will be at very least a 1.1, and it will include the various new tunings we've talked about as these would be useful to both Vorbis I and Vorbis II. No reason to make everyone wait for Vorbis II to see them.

Monty

Vorbis 1.1

Reply #34 – 2004-01-07 19:00:57

Quote

heck, AAC is allegedly revving incompatably again within the next year.

Uhhuh, I haven't heard this anywhere, and I have pretty steep contacts. Who exactly has alleged this? Sounds pretty baseless claim to me.

Lets not start this "something is allegedly gonna happen" totally baseless allegations. Anybody can claim pretty much anything, but I'm pretty surprised that you lower to this "undefined allegations" -level..

Vorbis 1.1

Reply #35 – 2004-01-07 19:18:47

Quote

...and two years ago, Vorbis I was not the oldest of the modern audio codecs. All of Real, AAC and WMA have revved to new (and incompatable) versions in that time. Vorbis was the newest format when it started, but now it's the only audio codec to not make incompatable bitstream changes (where new files do not play in old decoders) in the past three years.

We will not drop Vorbis I, even when we go to Vorbis II. However, the rest of the industry has made it very clear: they will opt for performance over bitstream compatability at any point.... heck, AAC is allegedly revving incompatably again within the next year. The only thing the same about the competition in 1999 and the competition today is that they've kept the same name on their codecs.

Except for 1 small mistake in the standard document the AAC bitstream has never changed in a backwards incompatible way. And it will not do so in the next year(s). And even this one mistake wasn't harmful and can be "fixed" easily.

EDIT: this mistake wasn't even part of the AAC bitstream, only part of the ADTS header.

Menno

Vorbis 1.1

Reply #36 – 2004-01-07 19:43:43

Quote

Except for 1 small mistake in the standard document the AAC bitstream has never changed in a backwards incompatible way

I'd guess he is referring to HE-AAC. Which isn't backwards incompatible, but to get full quality, you need a new player.

Vorbis 1.1

Reply #37 – 2004-01-07 19:53:34

Quote

It's interesting to see, will Coding Technologies implement other upcoming MPEG4 AAC additions, like Parametric Stereo-coding.

this could also need new AAC decoders...

Vorbis 1.1

Reply #38 – 2004-01-07 20:14:28

Quote

Quote
It's interesting to see, will Coding Technologies implement other upcoming MPEG4 AAC additions, like Parametric Stereo-coding.

this could also need new AAC decoders...

Parametric coding is backwards compatible addition. Just like AAC-HE plays without the SBR part in non-SBR capable decoder, parametric stereo coded AAC file plays as mono (instead of stereo) in a decoder which doesn't support it.

Vorbis 1.1

Reply #39 – 2004-01-07 20:27:19

Quote

Parametric coding is backwards compatible addition. Just like AAC-HE plays without the SBR part in non-SBR capable decoder, parametric stereo coded AAC file plays as mono (instead of stereo) in a decoder which doesn't support it.

Backwards compatibility is cool, no question. However, I think this backwards compatibilty is only of limited use - which customer will be satisfied with the result of playing an AAC-HE + parametric stereo (how is this called?) with an "ordinary" AAC decoder?

Vorbis 1.1

Reply #40 – 2004-01-07 20:31:17

It's still not "breaking" the standard, but just adding to it. You can still play those files with an old decoder, which makes it - per definition - (partly) backwards compatible.
If that's any better than the Vorbis solution is debatable though.

dev0

Vorbis 1.1

Reply #41 – 2004-01-07 21:29:34

Quote

Parametric coding is backwards compatible addition. Just like AAC-HE plays without the SBR part in non-SBR capable decoder, parametric stereo coded AAC file plays as mono (instead of stereo) in a decoder which doesn't support it.

Hm. For me this is enough to call it an incompatibility.

That is, if the quality is (significantly) worse for an older decoder (e.g. mono) than it would be, when an old encoder had been used. Of course, such a "compatibility" is still better than nothing.

Vorbis 1.1

Reply #42 – 2004-01-07 21:49:32

Quote

Hm. For me this is enough to call it an incompatibility.

I'd call it "lack of a feature". It plays but not with full potential, it's compatible MPEG4 bitstream. If some decoder doesn't support it, it doesn't make the stream or decoder incompatible, especially when with an reasonable straightforward addition a decoder can be made to support the new features in principle.

Anyway, FAAD2 has aac-he support and it should get Parametric Stereo coding support pretty soon.

Vorbis 1.1

Reply #43 – 2004-01-07 22:16:41

I don't suppose Vorbis II could equal something like Vorbis I + MPC psymodel as suggested here?

Vorbis 1.1

Reply #44 – 2004-01-08 00:36:49

Wow, the one and only Monty replied to my post *faints*

Quote

We will not drop Vorbis I, even when we go to Vorbis II. However, the rest of the industry has made it very clear: they will opt for performance over bitstream compatability at any point.... heck, AAC is allegedly revving incompatably again within the next year. The only thing the same about the competition in 1999 and the competition today is that they've kept the same name on their codecs.

So does that mean when Vorbis II comes out, there we will be a need for two different and incompatabile decoders, unlike LC-AAC and HE-AAC where you can play the latter with the former? eg. in Winamp, we will need a Vorbis I input plugin for our old Vorbis I files and a Vorbis II input plugin for the new Vorbis II files?

Quote

And, FWIW, Vorbis II is not two months from now... it's longer than that. There will be at very least a 1.1, and it will include the various new tunings we've talked about as these would be useful to both Vorbis I and Vorbis II. No reason to make everyone wait for Vorbis II to see them.

Monty

It's good to know that Vorbis 1.1 is still in the works. So are you going to spend time on 1.1 in the next few months and work on Vorbis II after 1.1 is released...or is Vorbis II being built right now and 1.1 is just going to be a patched 1.0.1 + GT3b1 + .....

Also, can you give us a hint on what these new tunings are? It's always exciting to see how much more we can get from tuning the little beast

Vorbis 1.1

Reply #45 – 2004-01-08 08:45:20

Quote

So does that mean when Vorbis II comes out, there we will be a need for two different and incompatabile decoders, unlike LC-AAC and HE-AAC where you can play the latter with the former? eg. in Winamp, we will need a Vorbis I input plugin for our old Vorbis I files and a Vorbis II input plugin for the new Vorbis II files?

According to what have been said during january monthly meeting monty is considering adding support for Vorbis II to Tremor: One decoder for Vorbis I and Vorbis II.

Of course Nullsoft would have to build a new version of their Vorbis-plugin...

Vorbis 1.1

Reply #46 – 2004-09-28 17:34:06

Quote

Ogg Vorbis traffic (at www.vorbis.com) indicated that monty has started working on vorbis 1.1

1.1 will incorporate Garf's high bitrate tunings and will try to beat the crap out of AAC-HE at lower bitrates (will it?)

Now my question is can vorbis compete with SBR without implementing it (SBR) as well? If it does implement SBR, won't it break the current bitstream standards and render the current portable players (supporting vorbis) incompliant?

Also, when 1.1 is released would you rip you cds again? Would that be really necessary, ie, would there be significant gain at higher bitrates.

My ideal vorbis:-

*At lower bitrates (<80), better than AAC-HE.
*At 96-128kbps, (i think) vorbis sounds the best already.
*At higher bitrates(>160) better thn mpc.
*Lossless encoding incorporated into vorbis (WMA style, one codec all options). Maybe FLAC can be merged with vorbis for this.

Would 1.1 achieve this? It would be a dream come true to have something like this.
[a href="index.php?act=findpost&pid=165728"][{POST_SNAPBACK}][/a]

Since Vorbis 1.1 is available we finally can answer this question with an unfortunate "No" (as predicted)

Although I'm pretty pleased with Vorbis' performance (1.1) it can be improved by breaking the decoder compatibility / getting rid of design-flaws / adding new features like GOOD interchannel redundancy removal (not just residue-wise but floor-wise as well). temporal prediction of the floor curves / codebook classification codes across packets, a new quantizer (for example an UTCQ with build-in dithering) and stuff...

But... does anyone know what's currently happening in the Vorbis 2 area ? The only thing that kind of pisses me a bit is: Xiph is making all the rules (specifications) and Vorbis II will probably be a one-man-project - again. What I really would like to see is some kind of "call for Vorbis II proposals" so everyone can contribute.

(oh, I'm just realizing this could have been a new thread since it's not fully on-topic anymore)

bye,
Sebastian

Vorbis 1.1

Reply #47 – 2004-09-28 18:09:33

Quote

But... does anyone know what's currently happening in the Vorbis 2 area ? The only thing that kind of pisses me a bit is: Xiph is making all the rules (specifications) and Vorbis II will probably be a one-man-project - again. What I really would like to see is some kind of "call for Vorbis II proposals" so everyone can contribute.

I second this.

Still I think we need some leadership to avoid caos, and Monty can fill that gap. He should be the main architect not some sort of a day-to-day manager. But he should actively incourage a team effort made out of volunteers. There are already quite a few who actively work on Vorbis and create forks.

As I said I am a Vorbis convert and 95% of my lossy music is gonna be in Vorbis, so the survival of the project is very important to me.

Triza

Vorbis 1.1

Reply #48 – 2004-09-29 00:54:28

Quote

But... does anyone know what's currently happening in the Vorbis 2 area ? The only thing that kind of pisses me a bit is: Xiph is making all the rules (specifications) and Vorbis II will probably be a one-man-project - again.

The question is 'which man'? Xiph.Org currently has little to no technical staff working on Vorbis. Monty, the one-man-Vorbis-developement-team has moved onto a management position, so he was plenty on his plate and will not put coding as his priority.

So it seems there is no-one working on a Vorbis 1.2 at Xiph.Org, let alone a Vorbis 2.

Things really need to change and Xiph.Org needs to set up an open-source developer group of some sort and maybe a Vorbis technical knowledgebase to help outside developers understand the encoder internals and contribute to it. Maybe you could draft up something describing the exact operation and psychoacoustics of the Vorbis encoder?

Quote

What I really would like to see is some kind of "call for Vorbis II proposals" so everyone can contribute.

I agree, though we need to establish clearly just how we are going to move everything along in that direction, when at Xiph.Org, there is virtual no-one (maybe we do have half or a quarter of Monty working on bugfixes) who is working on or is fully qualified to work on Vorbis.

I think we should start getting things in motion rather than standing still.

Quote

(oh, I'm just realizing this could have been a new thread since it's not fully on-topic anymore)

Great idea.

Vorbis 1.1

Reply #49 – 2004-09-29 07:39:41

Quote

I don't suppose Vorbis II could equal something like Vorbis I + MPC psymodel as suggested here?
[a href="index.php?act=findpost&pid=170745"][{POST_SNAPBACK}][/a]

Both the Vorbis camp and the AAC camp want the golden psymodel.

Notice