Hi,

i must of missed something, i had a quick search around but didn't find too much. What exactly is the gta build of ogg, from what i can gather its a tuned build of a pre 1.0 version of the codec. what was its purpose/who is it aimed at?

thanks

-J

You're referring to GT2, (Garf Tuned 2). It is an Ogg Vorbis encoder based on RC2 (?) which was designed to eliminate pre-echo artifacting. The downside to this is the output files are around 350kbps, so it was purely experimental.

You can get it from Benjamin's homepage:
http://ogg.benjamin-lebsanft.de/Download.htm

Ruairi

There is a 128 and a 160 kb/s mode too.
At 128 kb/s, I prefer a vorbis encoded with gta2 : less irritating noise than the final version.
The 350 kb/s was tuned in order to reduce the pre-echo problem of vorbis.


Binaries and special oggdropGT2 are hosted on : http://sjeng.sourceforge.net/ftp/vorbis/

I can't exactly remember the samples used, but I remember Vorbis 1.0 being a lot better @128 and @160 than Garf's GT2 build in my tests. (Yeah I know, there is no "wrong" or "right" here... )

Dibrom and other people on HA have the same opinion than yours. Apperently, vorbis 1.0 is really good on critical sample. That's a good thing.

The (small) tests I did recently exclude killer-sample. I just took randomly some tracks of CDs, and encode them with GT2 and with Vorbis I. I opened ABC/HR, loaded the original and the two encoding, took fragments of the whole sample, and compare : systematically, I found vorbis 1.0 to be less transparent, immediatly perceptible with a very high amount of noise.
On some instruments (esp. cymbals and drums), the difference between original and encoded one is awfull AGAINST vorbis 1 (at -q4.4 generally) : cymbals are totally blured, snow-covered by the noise - drums often sound more brighter than the original (on ABX, the difference is chocking). I found the same phenomenon with classical music : harpischord in continuo (background) is reduced to a dchhhh-dchhhhhh. LAME, mpc, aac, sometimes Atrac3 (real9 or ACM codec) did a better job.

The polemic is on this question : should we consider vobis 1.0 WORST than other codecs and formats because he fails to be transparent with all music, or should we consider vorbis to be the BEST codec at 130 kb/s, beyond mp3, ogggt2, mpc, aac... for his performance on critical (but rare) samples ?
The answer depends, I think, of the 'the degree of embarrassment' felt with this the continuous artefact of vorbis 1.0 : bright noise everywhere.
In july, I was amazed by the nice performance of vorbis, and claimed this codec to be the best one at the range of 110-150. Nevertheless, three month after this euphoric period, my ears are now acustom with this particular artefacts, and I find vorbis to be stressing, with to much roughness, especially for quite music. In one word, I find Vorbis performance generally under LAME, psytel or mpc... and ogg gt2 results.

If only a revision of the 1.0 codec could reduce the noise to the amount of GT2 (not perfect too) : vorbis will be a *real* killer, for everyone.

Are you referring to Vorbis 1.0 or GT2 with that statement?


And about this bright noise... yes, at -q 4 and to a certain degree at -q 5 as well, Vorbis 1.0 boosts the treble, I noticed that too. (Some people on Benjamin's forum could ABX it at -q 6, I can't.) But personally, I'd rather have a tune sound slightly brighter, but at a consistant level of quality (i.e. without obvious artifacts in some places), which is what Vorbis 1.0 provides as opposed to GT2 (in the 128-160kbps range, that is).

IIRC, taking.wav was one of the samples where GT2 @ 160 failed badly. I remember another sample from a Bee Gees album that caused trouble, but I don't have a lossless copy anymore.

Hrmm? I haven't really commented a whole lot on Vorbis 1.0 performance, other than that I've found it often to sound worse than Garf's Tuned version with the samples I test and the bitrates I normally use (160kbps and up). At <128kbps, it's clearly superior to the older versions though, which I believe is the area they were really tuning for the most. Other than that, I'm not sure exactly what opinion of mine you're referring to..



This seems a little bit odd to me. How exactly are you defining "critical" samples? Most of the samples I would consider critical, as I already said, Vorbis 1.0 often doesn't sound as good as Garf's version. Critical samples though, to me, usually refers to any samples which have caused problems for multiple codecs in the past, especially the one in question. If these samples you are listening to are causing problems, then almost by definition, I'd consider them to be "critical".

I tried to find the post I remember to read it from you. It's maybe that one.. I It seems that I remember especially these words, and forgot the others one :


That's I big mistake, and I beg your pardon. Sorry, sincerely.





I have the same definition of « critical sample ». As I tried to translate it in the last post, I tried to compare vorbis 1.0 to gt2 and to others codecs at the same bitrate (around 130/140 kb/s) on points randomly chosen. I just take a CD, extract one track, compress it, and select with ABC/HR some points.
At 130 kb/s, of course, it's not too difficult to find a small difference between the original and the encoded one. And we can't seriously consider a sample as killer sample when bitrate is too poor.
The strange thing occurs with vorbis I. When I listen the sample for the first time, by clicking on [A] or on [B], I often can identifie Vorbis, immediatly !. With other encoding (Lame, mpc...), I must listen many time the original and the encoded one, in order to find with succes a difference.

I did recently an experience witn winamp. I encoded a disc with aac -streaming, mp --radio, --alt-preset 138 and vorbis -q 4.4. I loaded all these tracks on winamp, and play them randomly. After few seconds, I must decide if the playing one was a Vorbis one or an other one. I have no exact data, but I perform the test with succes with around 80%. I have not repeat this test with gt2, because this codec doesn't produce a so particuliar sound.
=> Vorbis I, at 130 kb/s, is easiest (for me) to detect than a lame, a Psytel or a mpc encoding. On every music, on every tracks, on every moments I tried. It doesn't mean than Vorbis is lower quality : on critical sample (I tested), vorbis performs better than other codecs (who distord sound more obviouly).


I was really shocked by this conclusion. I often read, and unfortunatly often said, that vorbis was better than mp3 at > 120 kb/s, and that vorbis I was the better codec around 120-150 kb/s. Some people (included me) seems to extrapolate the amazing resuts of vorbis I at low bitrate (60-100) to higher one (120-160). The c't listening concluded by the superiority of vorbis for many people (but I remember Frank Klemm conclusions, who was one of the first discordant note I read about vorbis format)

What happened between RC3 and Final version ? Did developper made (bad) choice, in order to privilege low bitrate encoding, and didn't care about consequences at higher bitrate ?

I refered to Vorbis I. Sorry again for my poor english.

With -q6, the problem disappear. It was difficult for me to find a noise-problem on any sample at this setting. Vorbis -q6 and above gave really good results, except at least for pre-echo.

It doesn't take critical samples to outperform MP3 in that bitrate range. Anything that's got percussion (it doesn't even have to be aggressive, this will do) causes ringing when encoded with MP3 at 128 or 160kbps.

Vorbis doesn't suffer from that.


<nitpick>BTW: "Vorbis I" is not the same as "Vorbis 1.0". "I" is the version of the format itself, not the version of the libVorbis libraries. Garf's GT2 encoder is "Vorbis I" as well.</nitpick>

Monty's first focus with Vorbis was the low bitrates. The first goal for Vorbis is portables and adoption by the laymen who's favorite datarates are somewhere around 64Kbps. And for that Vorbis rocks. As soon as the portables catch up it will be great. Once Vorbis and Xiph's position is stabilised in the markets and minds of the masses high bitrate tuning will come. Or perhaps someone will look at the source and help them in that area. It is not that Vorbis could not be better at higher bitrates. But that untill now there was a need to focus on the low end of things.

It's ok I was just trying to clarify is all...

By the way, have you ever done an own comparison at 64 kbps including Ogg Vorbis or do you rely on other people's comments when you state this? In my opinion you should not give the c't listening test too much credit on that, because it had some flaws that probably lead to this result (and have been described by Frank, me and others).

One of the lessons I've learned during and after this test is that you should never trust anything that you've only read about a sound or a test result, but rather try to prove it for yourself. For example I now use the Vorbis file from this test as a low-quality anchor in the sense of the MUSHRA test method described by the EBU, i.e. readjusting my ears again in a long and difficult test session with "a little help" from a really bad sounding sample. It also helps to relax and chill out a bit in these situations, so I'm really glad I still have it.



I don't know exactly what happened, but it was interesting for me that the developer of Mpxplay also recognized that something must have changed, because he first wondered if something was broken in the encoder or decoder when he implemented Vorbis 1.0 in his DOS encoder AudioCV. And he used very high bitrates at that time, don't know if he is still using them now.

How about FF123's test? Vorbis beat out everyone at that BR except for one very specific and uncommon MP3-PRO encoder. And the gap was small. Perhaps you should not trust C'T but what about him? He seems quite knowledgable to me.

I have also done my own tests. And if I ever encode to that bitrate Vorbis will be the codec used. As for higher bitrates it still performs quite well. It has problem samples. I dare you to show me a codec that does not. For long term backup MP3, MPC, or Vorbis are not really the way to go any way. But for casual listening..........

IIRC, ff123's tests were done with a pre 1.0 version of Vorbis, the version was RC2 in fact. This might have quite a bit of relevance to the discussion at hand, especially since the "problems" being discussed seem to have become more prominent in the 1.0 release.



The issue isn't that Vorbis has problem samples, it's that it doesn't scale well quality wise as you increase the bitrate to high levels. It is not tuned for high bitrates. With Vorbis, I'd probably go so far as to say that beyond 160kbps, there's not much use in going higher and if you need to go higher, you're approaching the problem with the wrong solution; Vorbis isn't the codec to use at these bitrates, at least for now.

As for problem samples -- yes, every codec has them. That does not mean that some codecs do not have an orders of magnitudes less problem samples at the target bitrate. It also doesn't mean that Vorbis couldn't improve upon this number. This is what is important.

I don't think dismissing the problem with the arguments that "Vorbis is good enough, nothing is perfect, it sounds good to me so who cares, etc, etc" is the answer. If we take this kind of approach, the problem will never be solved.

I was thinking about this situation earlier today, and I think maybe a good solution to help get Vorbis tuned better at higher bitrates would be to organize some sort of report. We should get everyone to submit all of the problem samples they have come across, all of the quality issues, etc, and put it together in one document to submit to someone like Monty. If we can get enough information in one spot, it would probably be worth it for him to take some time and try and fix a lot of these issues in one go. Otherwise, taking his attention away from Theora/etc is probably not going to be worth it. One small issue at a time, instead of a bunch of information at once, makes the situation seem much less significant than it actually is.

Was he reffering to 1.0 as in the file format or the codec version? I took it to be the codec version. I mean what difference does file format version make for the codec? Same codec in a different container should still sound the same.




MPC does not scale well below 160Kbps. Point is the right tools for the job. Ultimatly I agree with you.



All codecs "could" improve on their numbers. My point with that last post though was that C't is not alone. Other more respected or perhaps well known came to similar conclusions.



I never said it was "Good enough". I simply was pointing out that C't was not alone in the entirety of it's assessment. Others with better methods have reached similar conclusions. I whole heartedly want Vorbis to continue to progress.



Well said.

I will try to answer with the few english words I have.




Yes : with your sample, ringing is obvious with lame (abr), and vorbis hasn't this problem. I'm not familiar with this kind of music, but I find the level of ringing higher than other encodings I recently made (esp. with Metallica)... Maybe the backgroud signal is needing more bitrate...
On the other side, it doesn't take critical samples to outperform Vorbis in that bitrate range . It's easy for me to find samples that bring audible trouble to vorbis and sound paradoxically nearly transparent with lame. At least with classical music, and at 130 kb/s.



Thanks for the whole answer.



I did some test at 64 kb/s and around. With the music I tested, and for my taste, mp3pro won. Just encode an harpsichord at +/-64 kb/s with ogg vorbis, and compare it with mp3pro (VBR : ff123 test doesn't include variable bitrate) : it's difficult to say that vorbis wins, and it's impossible to say that vorbis rocks... It's really awful.

But I was talking about 130 kb/s, and not 64 kb/s. I took mention of c't test's conclusions in order to illustrate the degree of suprise I had by testing vorbis myself at 130 kb/s. I don't find Vorbis 1.0 to be a mp3 killer and I can't consider vorbis 1.0 to be the best codec around 130 kb/s. Such judgment is going against a common opinion founded on HA, and c't conclude in the same way, approximatly : the supremacy of Vorbis 1.0. In most case, I found Vorbis to be under LAME (yes, under), and the best codec at 130 kb/s was (for my taste, again), mpc --radio and PsyTEL -streaming. I rarely heard vorbis to give the best results, but I often heard vorbis introduce a snowy artifact when other codecs encode the music without any immediate problem.
My own listening test, by being in a such contradiction with the common opinion about vorbis quality, surprise me. But I was really astonished by hearing that older versions removed (or soften) the snowy noise that irritate me so much, and who differenciate so much vorbis 1.0 to other formats.




I'm incline to say « around 130 kb/s and beyond... ». I get the measure of that assertion, I know that's shocking, but I honestly doesn't exagerate anything. It seems that Vorbis obtain marvellous results at 80 kb/s, and doesn't progress significantly (or with proportionality) with higher bitrate.




Or simply begin to look what cause that regression. The snowy artifact affect all music I encode, and is not far to cover the whole tracks. I think that, before tuning vorbis at higher bitrate, it is urgent to remove that nasty bug for a Vorbis 1.1. It's difficult to admit that the new mp3-killer is not able to encode without audible, and most af all, immediate, problem a simply signal like a choral music, a piano music... etc...

In order not to consolidate my judgment, I did some tests this night.
I suspect Vorbis to perform a big jump in quality between -q 5.99 and -q6. This jump was well known with RC3 (4.99->5) ; at least, the bitrate gap was really big.

It's a blitz-test : I just took one track (medieval music, with mainly percussions), tested and noted into abc/hr. I encoded the track four times :


The bitrate jump between -q5.99 & -q6 is not very high (4%).


I suspect the first seconds to be a killer for vorbis 1.0 : it's an old instrument, who sound like a rattlesnake shaking his tail. The snowing sound produced by vorbis 1.0 tend to erase the details.



Ogg5.90 and ogg5.99 are nearly the same : very easy to ABX.
Ogg6 was more difficult, but not impossible to ABX. The first try were catastrophic, the last one are better : that's why I put the test up to 30 attempts.
OggGT2 was really hard. I guess the most of time.

The snowy noise is significantly lowered by the -q6 preset !! Lowered, but not eradicated. OggGT2 was harder to identifiated.


Next, I perform the test on the same sample, but with ogg -q6 against GT2, in order to evaluate more precisely the difference between the two encodings :



No doubt : oggGT2 is transparent on this « snake » sample, and vorbis 1.0 is not transparent nor difficult to ABX. I remind the bitrate : 200 kb/s...


Next, I tried to found other point that may cause problems. Many drums on this track : I focused next on pre-echo :



I was able te ABX the three encoding (I permanently removed -q5.90). I obtained 16/16 for GT2, but it doesn't mean that this encoding was easiest to ABX. On the contrary, I was obliged to put more attention in order to identifie the artifact ; the 1.0 family encodings were really easy to ABX in comparison. I tried to note the encoding :


ogg 5.99 & ogg 6 sound the same. But GT2 was better, with less pre-echo.



Other point, with drums and another tchhhhhh sound in background :


Progressive notation. Pre-echo level is the same for -q5.99 & -q6 (not very good), but -q6 lost the snowy sound, and obtain in consequence a better note. oggGT2, with less pre-echo and no noise, obtain a very good note.



The last sample a tested was a flute, with small guitar's notes in the background. A flute is not difficult to encode, but I wanted to see if I could heard any problem with vorbis.
First, I did an ABC test :
The two files I identifie as different from the original were the 1.0 family encodings. Maybe the gain of vorbis, who make the encoding sound a bit louder. Not sure.
Now, the ABX test :


Confirmation : there is a difference, and I can witout too much difficulties ABX it. Sound is not bad : maybe louder, maybe a bit sandy (or snowy) too.




What should we conclude ? Nothing, really, except about the pre-echo, the more universal artifact : GT2 is a clear winner.
There is an artifact, proper to vorbis 1.0 : the snow, like a radio, easily perceptible up to 5.99, and very low (but not impossible to ABX in some case) above 6.0.


I let anyone judge himself if this artifact is less or more irritating than others.


I apologise for all the damage I cause to the english langage. Sorry, but I slept during my english lessons :'(

I have the same impression of ff123 as you, and in fact I thanked him on several occasions for his test, because it made me consider low bitrates as a possible alternative for the demo tapes of my band. But I did not take part in his test, because it ended before I knew about it, so I can't tell anything about the sound of the samples for myself and if they were "problem samples" that favored the Vorbis sound maybe.

Furthermore he had to choose the codecs that were available to him at that time, and the c't test used more and newer codecs, especially in the case of AAC (FhG evaluation build from Aug 23rd instead of QuickTime 6 Pro) and WMA (WMA9 beta instead of WMA8). I don't know if Dibrom is right on the version of Ogg Vorbis involved in ff123'S test or you, but this should be clarified, perhaps by him, if anyone wants to draw direct conclusions only by reading both tests.

Another thing that should be considered when doing this is that Vorbis was the only codec in ff123's test that used VBR (in one of the two "incarnations"). This wasn't possible for WMA8 or AAC, it could have been used for mp3PRO (but wasn't, as far as I know). The c't test probably did not use VBR for any codec, at least not at 64 kbps, but I never got any confirmation from them for this assumption.

And that "very specific and uncommon MP3-Pro encoder" isn't that specific and uncommon at all, maybe for hardcore Linux users, but not for the rest of the world. By the way, ff123 never claimed that "Vorbis beat out everyone except..." in his test, this is your interpretation from reading the results (and Monty's comments, probably...).



That's your choice, and that's fine with me. I don't claim to know the absolute solution for everyone at 64 kbps, but I know a lot more about the possible sound quality at that bitrate now than I knew before. And for my purpose I can safely say that I won't consider Vorbis as an option anymore. But this is what "psychoacoustic" audio compression is all about: can you stand or tolerate the amount of "cheating" and the resulting artifacts that the format generates or not? I've found my answer, and I'm as happy as you seem to be...

OK, so you also have the same impression from Vorbis at 64 kbps like me, I only wanted to be certain about that.



Err.... no.



I was wondering to which "amazing results" you referred to in this quote. But now it's clear that you probably did not mean your own results.



That's why it's important you decided to give us your own impressions, thank you.



That's right, I only think that "snowy" sounds too peaceful for me (you probably know Vivaldi's Largo from "L'Inverno", op. 8 No. 4... ), it's more like an artic snow storm in my opinion, at least at 64 kbps. And I can also say that this tendency is still obvious for me at higher bitrates, but I did no thorough tests there, because I don't need them anyhow.

@guruboolez

I must say that after listening again and again for several hours (since july release date), vorbis tends to give me too a sensation similar to that "bright noise" it's talking about recently.

Strangely , "what I feel a little bad in this noise" appears me more tangible when sometimes I return to hear my "old" good MP3s (made with LAME 3.9x --alt-preset standard), in few words I feel lame aps more warm (or sweet) and clean whereas vorbis appears overall very good but less colured and a bit icy.
(all my music encodings are made with vorbis 1.0 at -q6)
Of course, judging lossy encoder by comparing with another lossy is not a real comparison point, but nevertheless I'm pretty sure that original content of that lossy files sounds quite warm, clean and sure not stressing at all (because I own the respective original CDs ).

Can't believe! Nearly the same thing is happening to me!
What I strongly feel in common with your impressions is that the noise and the less warm sound starts stressing me at the same way.

Honestly I haven't made any technical comparison test, but since last month this feeling has been strengthen every time I have switched repeatedly wav > vorbis > mp3 > vorbis > wav > mp3 > vorbis ....... (during normal music listening)

hans-jürgen:


... Or what you seek to accomplish objectively and how much of an impact that has on subjective degregation might be a more detailed way of putting it.

Dibrom:


Now I think we are on the right track. I think that we would be the more appropriate way of approaching the situation.

Dibrom:


Maybe we could be a little more specific in detail rather than using such a ubiquitous word as "tuned" generally that's what most people say, but everytime I think of tuning I think of tuning the car radio. ;-). What exactly is it that you think needs to be "tuned"? If it's a masking curve issue on a set of particular samples, etc than those can be adjusted day in and day out as Monty mentions quite frequently. I would think that would be one the techniques Garf is fiddling around with during the "tuning" process as well. I haven't looked at the source-code in a while, I will have to look at it again when I have the chance.

"tuned" from the dictionary:


Vorbis doesn't appear to be adjusted for maximum performance at high bitrates like it is at low bitrates.

The problem itself seems to be non-specific. Vorbis (or perhaps I should say the Xiph reference encoder) doesn't scale well at the higher end it seems. At 300kbps or more (really even at 200kbps ore more), it should have almost no pre-echo, it shouldn't have problems with noise (shown in one of the test samples awhile back), etc.

I don't think there is 1 specific thing causing all of the quality related issues people have come across. It's usually a multitude of small problems which combine together to create a generally unoptimal level of quality. As for what some of the possible causes for this which could be discussed at the code level are, I'm not sure because I've never really studied or experimented with the Vorbis code in great enough detail to know. Because of this, I think the only way to solve the problem is for there to be a big push from the developers to get users to help do listening tests and provide samples. There are already some people doing this, but the problem is that it doesn't seem to be much of a development priority and so a lot of the issues seem to either be ignored or set aside for later. I'm not blaming Monty or anyone for this, because I know there's a lot of other stuff Xiph is working on.

What would really be good is to have like some sort of a "Bug Day" but for quality issues.. and it needs to happen on a routine basis. Perhaps Xiph could even setup a development area where users could go to a webpage, submit some text on a problem sample and upload the sample, and then track the issue (similar to bugzilla or something... kind of like what olcios suggested for LAME). I think these sorts of things would really encourage people to continue to help find flaws which can be fixed. Right now there's little motivation to do that because there's already outstanding issues which haven't been addressed sufficiently yet (pre-echo, noise, etc).

It seems their priority now is to push Ogg Vorbis to the hardware platform, also something we really want to see. So it's a give or take, but I think Xiph is doing it right. They really need to get the hardware support out first then fix the higher bitrates later.

It's still somewhat good to have working knowledge sometimes even if you are not into hardcore development. It helps you to grasp some internal knowledge about the low level libraries and how they work. Fascinating stuff if you ask me, unfortunatly a lot of people don't see it that way at times. Even if your not sure about about how everything works in great detail it helps you when you are going to make conjectures about what the problem might be.



Based upon my searching through the source-code and investigation of low level libraries in Conjunction with what Neo Neko said I don't think that was the intention of Monty in the first place. I think streaming and low bitstream capabilities where more of priority for Vorbis in the first place. This of course isn't going to fit well with those who have golden ears or are easily bothered by slightestest [minute] degregation of subjectivity.



If we are speaking in terms of pre-echo that could very well be directly related to to masking curves within short block's on a set of particular samples. More than likely that can be adjusted emperically or so I figure. I mentioned this before, but I also think that in my own mind and from listening on a set of particular samples, without any major statistical anaylsis that the "snowy white noise" people tend to hear in the middle stereo image which has been addressed by Monty, has to do with the diffuse qualities of the stereo image in the coupling mechanism. The diffuse noise from the left and right channels is rotated into the middle leading to what appears to sound like for most people in this case "white noise" which in fact is just an objective of the encoder, but doesn't fit well with most listeners from a subjective standpoint. I would "think" I could also be wrong that should dissappear where there is no channel coupling at all, if it's still an issue than it could be masking or quantization issue something of that nature.



... Or maybe something that works in conjunction with xiph.org bugzilla engine quite possibly extending it's capabilities a little a bit. Not a bad suggestion. Have you tried making that suggestion quite possibly on the xiph.org mailing list yet?

Of course.. but as you can see, I wasn't speculating as to what the problem actually was, only what the symptoms of the problem are



I've acknowledged this from the start. The problem is not with the way I view this situation, it is with the fact that everytime I point this out (that Vorbis is not tuned for high bitrates), some Vorbis user objects. Then, once we get further along in the discussion, they make this admission.

So... tell me again what exactly it is that we're disagreeing about?

I say that Vorbis isn't tuned for high bitrates. Apparently you agree with this by pointing out the above. I've never said that Xiph or Monty were irresponsible for not tuning for high bitrates, I've only repeatedly said that there are better tools for this particular job than Vorbis which, once more, I assume you agree with given the above..

Again.. what's the point of this debate, exactly?



Conjecture and speculation is nice and all, but it serves no purpose unless the problem is going to be fixed. Are you going to go fix the code? If not, I don't see a whole lot of use in continuing to "guess" about what might be the cause -- it could be anything.

Whether or not this "noise" (or any other problem) is an apparent objective of the encoder or not is largely irrelevant, at least in terms of a discussion about quality. From that standpoint, whether or not it is functioning as it should according to theory, it is still wrong.

And at least in one case (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=12&t=3823&s=) where there was a problem (JohnV described this somewhere, but I don't remember where) with some sort of "noise", the setting used was -q6. If I'm not mistaken, lossless coupling should be in use at this setting. That kind of throws the idea that the problems are just related to the lossy channel coupling out the window if you ask me. Point in case is that I don't think there's any one or two relatively quick and small changes that could be made which would "fix" all of these issues to the degree I believe you think they might.



No. I really haven't had time to do much of anything outside of HA for the last few weeks. I might try to do this over break though.

[quote][quote=Dibrom,Nov 11 2002 - 04:14 PM][quote]How about FF123's test? Vorbis beat out everyone at that BR except for one very specific and uncommon MP3-PRO encoder. And the gap was small. Perhaps you should not trust C'T but what about him? He seems quite knowledgable to me.[/quote]

IIRC, ff123's tests were done with a pre 1.0 version of Vorbis, the version was RC2 in fact. This might have quite a bit of relevance to the discussion at hand, especially since the "problems" being discussed seem to have become more prominent in the 1.0 release.[/quote]

Was he reffering to 1.0 as in the file format or the codec version? I took it to be the codec version. I mean what difference does file format version make for the codec? Same codec in a different container should still sound the same.[/quote]

I was referring to the 128kbps tests, not the 64kbps tests. Guruboolez had said that the problem became more severe with 1.0 than with earlier versions. Since I believed we were talking about moderate bitrates (128kbps or so), I apparently misinterpreted what you meant by ff123's tests, and thought you meant the one at 128kbps.

[quote][quote=Dibrom,Nov 11 2002 - 04:14 PM]
[quote]I have also done my own tests. And if I ever encode to that bitrate Vorbis will be the codec used. As for higher bitrates it still performs quite well. It has problem samples. I dare you to show me a codec that does not. For long term backup MP3, MPC, or Vorbis are not really the way to go any way. But for casual listening..........[/quote]

The issue isn't that Vorbis has problem samples, it's that it doesn't scale well quality wise as you increase the bitrate to high levels. It is not tuned for high bitrates. With Vorbis, I'd probably go so far as to say that beyond 160kbps, there's not much use in going higher and if you need to go higher, you're approaching the problem with the wrong solution; Vorbis isn't the codec to use at these bitrates, at least for now.[/quote]

MPC does not scale well below 160Kbps.[/quote]

First of all, what does any of this have to do with MPC? This seems like a bit of a tu quoque if you ask me. This isn't about MPC vs Vorbis. Secondly, nobody ever claimed that MPC was designed to sound good at low bitrates.. on the other hand, people often say that Vorbis is great for use at high bitrates (sometimes thinking, falsely, that it is the best in this arena).

[quote]Point is the right tools for the job. Ultimatly I agree with you.[/quote]

Right, so why is this discussion dragging out so much? I say that Vorbis isn't tuned for high bitrates, it seems that after reasonable discussion, most of the people on the opposite side of me in this debate agree.. so unless we're just here to defend Vorbis from some sort of mistaken defamation, I don't understand the point in continuing to rehash this.

[quote][quote=Dibrom,Nov 11 2002 - 04:14 PM]
As for problem samples -- yes, every codec has them.  That does not mean that some codecs do not have an orders of magnitudes less problem samples at the target bitrate.  It also doesn't mean that Vorbis couldn't improve upon this number.  This is what is important.[/quote]

All codecs "could" improve on their numbers. My point with that last post though was that C't is not alone. Other more respected or perhaps well known came to similar conclusions.

[quote=Dibrom,Nov 11 2002 - 04:14 PM]
I don't think dismissing the problem with the arguments that "Vorbis is good enough, nothing is perfect, it sounds good to me so who cares, etc, etc" is the answer.  If we take this kind of approach, the problem will never be solved.[/quote]

I never said it was "Good enough". I simply was pointing out that C't was not alone in the entirety of it's assessment. Others with better methods have reached similar conclusions. I whole heartedly want Vorbis to continue to progress.[/quote]

Hrmm, this is not the way I interpreted what you said:

[quote]I have also done my own tests. And if I ever encode to that bitrate Vorbis will be the codec used. As for higher bitrates it still performs quite well. It has problem samples. I dare you to show me a codec that does not. wink.gif For long term backup MP3, MPC, or Vorbis are not really the way to go any way. But for casual listening..........[/quote]

When you say "as for higher bitrates it still performs quite well", that can only serve to either:

1. Lessen the significance of how much better another codec may sound at that particular bitrate.
2. Imply that performing much beyond what it does now is not very relevant.
3. Imply that it performs favorably ("well") in comparison with the others in the discussion

All of these lean towards the "good enough" sentiment.

Then when you say "It has problem samples. I dare you to show me a codec that does not", the only purpose I can see for that statement is to do the same thing again. The only conclusion we can make from this statement is that no codec is perfect and therefore: Why are we complaining about Vorbis? It's "good enough", or at least as good as any other.

Then, you say "For long term backup MP3, MPC, or Vorbis are not really the way to go any way". This implies that they are all flawed, and since you do not also accept (in this statement) that some codecs are more flawed than others in some areas, that can only go to show that yet again, Vorbis is "good enough", or, again, at least just as good as any other.

Finally, you throw the word "casual" into the mix. This kind of opposes the critical nature of these discussions. Who cares about criticality, because we're just listening "casually" anyway... so once again Vorbis is "good enough".

Sorry for beating this to death, but I just really want to point out what I think are some of the problems with this argument, and to discover what exactly it is that we're really trying to say in this thread.

I understand that people like Vorbis a lot -- I do myself -- but that doesn't mean that we shouldn't talk critically about it. Discoveries which stem from critical examination are, in my beliefs, the only way that problems can be found, fixed, and ultimately true improvements can be had from. We shouldn't be trying to dillute the argument or the problems just to make people feel better about their favorite codec (I loath this type of mentality in all things), we shouldn't be trying to cover our eyes and pretend that issues don't exist. This is the wrong way to approach the situation.

Of course, we can discuss positive things such as the ways to possibly improve things, but this comes after the fact.. after we've already acknowledged that there is actually something less than ideal, something to improve upon.

Yep, -q6 uses only lossless channel coupling.

Here's one sample which has noise problems with -q6
http://static.hydrogenaudio.org/extra/Vorbis/Beck.wav
http://static.hydrogenaudio.org/extra/Vorb...s/beckOggQ6.ogg

There's quite a lot of background noise during 2.5-4.5 sec.

The funny thing was (I was talking with Monty about this), that if I cut just the problem section 2.5-4.5sec and encode it with -q6, there's not that kind of background noise.. But with the full clip the noise exists. So I was asking Monty, why this happens.. Clearly Vorbis has the potential to encode this without the excess background noise, but it just doesn't do it.

For comparison here are the clips from just the 2.5-4.5sec section, which show actually no problem now when isolated..
http://static.hydrogenaudio.org/extra/Vorb...BeckNoNoise.wav
http://static.hydrogenaudio.org/extra/Vorb...ckNoNoiseQ6.ogg

Of course it doesn't help that the isolated section sounds fine, when the actual long clip sounds bad.

Anyway, here in this case the noise problem can't be related to lossy channel coupling, as Dibrom correctly suspected.

Notice also, that the full clip is noisy more or less all the time with Vorbis -q6, but during 2.5-4.5 sec it's most noticeably noisy imo.
I rated Vorbis -q6 as clearly the worst here:
(Beck1.wav is vorbis -q6 272.8 kbps)
http://www.hydrogenaudio.org/forums/index....3823#entry39678

Ok, granted this is pretty hard to encode clip and the noise is probably more related to poor transient handling someway, although it's funny that the problem is not present in the isolated clip.. This was the latest example. I gotta search a little bit for other examples.

Neither. I was trying to make a point there. Unfortunatly, I don't have golden ear's so it doesn't bother me like it does a lot of the folks.



How can they not? you use wise speech and debating techniques to dig them into a hole. My point for this debate is I am try to bring some technical aspects into play here in order to help understand what the problem could very well be and to question those in a sense as well, rather than using basic adjectives and statistical anaylsis to show that a problem does exist and demanding that it be brought forth. It might be possible to make some suggestions to Monty in a technical sense to see if he agrees or disagrees in a way.



Might I ask if you have had any bad past experience with xiph.org in the past and that is why you seem hesitant to doing so? I know you are busy maintaining the website and such and I am not questioning you on that I am just curious.



Did he make any suggestions of what the problem could very well be? Or does he want you to collect more samples where the problem appears to be evident? To me if appears that maybe the masking curves might just need to be readjusted over set a set of short blocks (needed to isolate those transients). After, listening to the sample it does not appear it's a coupling issue. The reason I suggested that was that I could hear evidence of the rotation in the sample appluad.wav when I encoded it around -q 2 ~ 128 kbps or something of that nature and I was just suggesting it might be directly related. I can send you the sample if you want I think you'll see what I mean. As for -q 6 issue might also be a quantization issue as well. I saw a suggestion about it somewhere on the archives, but I can't specifically remember what the problem was.

Hrmm.. well, you can't have your cake and eat it



I am not intending to trick anyone in any of my debates. I'm simply stating my thoughts and pointing out flaws in other peoples arguments where I see them. I'm more than willing to accept the flaws in my own arguments also. The point of debate, in my mind, is to find (or at least attempt to) the truth of the matter, not to simply win an argument -- a philosophical goal as opposed to a sophistical one. I hope people recognize this and don't simply feel that I'm out to get them. As I've tried to point out before, nobody should ever take debates on here personally.



As we've touched on before, abstract theoretical discussion is nice, but if it's not grounded in reason then it's merely arbitrary. We can speculate all day about what the cause of any of these problems are, but that doesn't get us any closer to actually proving that. It also doesn't really get us any closer to solving the problem unless we are also actively testing the theories. Right now, I'd say there's more evidence to support the fact that most of these problems are releated to a more general lack of tuning than to one specific problem. If you can show otherwise, that'd be great, but only so far as it's useful in actually then going and addressing the matter.



Not pathologically, no. For the most part I get along fine (well even) with the people I've talked to from the team (Emmett, Monty, Jack, Vakor, etc.).

My hesitance in jumping right to the matter is that I find mailing lists inconvenient and out of the scope of my normal routine for contacting people in the community. I prefer IRC, webforums, or instant messagers of some sort. Email feels "clunky" to me. I've talked to Monty on numerous occasions though, and JohnV seems to be in regular contact, so most of what is discussed here I would imagine gets back to him anyway.

Sounds like a take off of a Marie [Antoinette] quote.



Yeah, I would say that's the difficult task at hand to acomplish. hmm...

Today I did an ABX test involving GT2's 128kbps mode, which (according to Dibrom) is NOT tuned at all, and Vorbis 1.0 (latest oggenc compile by John33) @ -q 4 and -q 5. I encoded a random song (Emo/Punkrock) of my collection and tried to ABX it in ff123's ABC/HR.



I focused on a passage, which was pretty easy to ABX for me (clear pre-echo).
Download FLAC sample (lossless)



I was really suprised/confused by the results, especially after Dibrom told me that the 128kbps mode wasn't tuned at all. What happened to all bitrates over 128kbps after RC2/GT2? Isn't Vorbis 1.0 supposed to be better at least at the tested bitrates?

dev0

Well, I only think this is the case, I'm not actually 100% certain. IIRC, only the 160kbps and higher bitrate mode were actually tuned.

Found here and here.

So the -b 128 mode was kinda tuned, though 1.0 still should be better, considering that more than a year of development has happened since GT2.

IIRC, the 128kbps mode had lossless stereo and a slighly more aggressive noise masking.

I think that if you'll look closer, it should give slightly higher bitrates than normal 128kbps modes. Unless I turned down the rest of the tuning. I don't really remember any more.

It gives higher bitrates than Vorbis 1.0 -q 4, but significantly lower ones than -q5, which (opposed to gt2) was still easily ABXble.
dev0