The version of GT3b1 merged with V1.0.1 is now known as GT3b2. This is, as it says above, the result of merging GT3b1, minus floggy, with V1.0.1. This should not be confused with the GT3b2 that Garf produced some time ago which was unsuccessful and short-lived.

The version string read: "Xiph.Org/Sjeng.Org libVorbis I 20030909 (GTune 3, beta 2)"

All new suitably amended compiles are now available at Rarewares.

nice
thanks alot john

minor bug at rarewares: GT3b1 (312Kb) - GT3b1 P4-only (293Kb)
should be b2 then
(it's at the oggdrop section)

same at Oggenc2.3 using GT3b2 based on LibVorbis v1.0.1

Helo

I might just be too stupid - but I can't find those files to download.

Could anybody please post an URL, please?

Thanks

http://rarewares.hydrogenaudio.org/

In order to use Garf's low bitrate modes, shouldn't it be possible to enter a q value <-1 ?
Today's compile (oggdropXPd V.1.7.5 using GT3b2 based on LibVorbis v1.0.1 2003-12-08') only accepts q>=-1 in quality management mode and bitrates >=45 kbps in CBR/ABR mode.

Ooops!! Thanks, I'll correct that.

Edit: Now corrected.

The 'floggy', ultra low bitrate stuff, is removed as Garf indicated would be done when the merging was first mooted.

Thanks a lot, john33.

It's very convenient to be able to use a single encoder for all quality levels.

Ok it's clear now. I should have my Software Release Versions Arithmetics updated

Minor nitpick:

IIRC there was a GT3beta2 by Garf, but quality was inferior to beta1. So maybe it should be named GT3.1b1 or somthing like that.

the original beta2 was RC3+patches

Wasn't that GT2 ?

Yes, that was GT2

Still, I think that going GT3.1b1 ia really nitpicking. I highly doubt people will confuse things since the older GT3b2 didn't even spread much, by now it's probably gone already.

You see, the problem with this compile is that there is a huge bitrate jump between -q4.99 and -q5. I think that v1.01 should be mapped to values between q -1 to q5.99 , and GT3b1 should have its -q5 mapped to the previous -q6, and so on in the upwards direction. This will cure the bitrate jump and give a more accurate representation of the quality that can be expected.

It might cure the bitrate jump, but it would throw away some of the improvements Garf introduced, and right at the point where they're most needed (i.e. what many people would consider a good trde-off between size and quality).

Cheers, Paul

Ain't nobody gonna cure MY bitrate jump!

But seriously, how do I compile this source? There's no makefile in there. Some instructions would be appreciated.

Pardon my ignorance, but what's the difference between 1.7.5 and 1.7.4, if you are not including the GT3b2 updates...i.e., what's the reason for the vanilla 1.7.5?

Both use 1.0.1 vorbis, right? What are the updates/advantages to using the new version if we're not planning on using the higher-bitrate optimizations/tunings...?

Thanx in advance.

I compile using the VC IDE, but if you have a makefile for compiling 1.0.1 libvorbis, etc., it will work just the same if you drop the GT3b2 libs in in place of the 1.0.1 libs.

I assume you're referring to oggdropXPd? 1.7.5 was a bugfix over 1.7.4.

Some people may wish to use the 'plain vanilla' 1.0.1 version just for the comfort of using the 'official' libs and the lower bitrates at the higher quality settings. Others may wish to take advantage of the quality improvements in the lower quality settings from using 1.0.1 libs, but with the quality improvements, at the expense of higher bitrates, of the higher quality settings from using the GT3b2/1.0.1 libs.

The choice is yours. At the lower settings level, you'll see no difference at all. So, if that's all that you use, it doesn't matter which one you use.

Just to let you know the vorbis dll for HeadAC3he does not work. It can't get the vorbis interface. The only compile that works is the GT3b1 dll. Would it be possible to fix this?

Wow, we're getting some good progress in Ogg Vorbis. Thank you so much for the effort, john33.

Files produced with the GT3b1 compile at -q5 are comparable in size to v1.0.1 at -q6. Why not re-map the quality settings to reflect this in the new GT3b2 compiles? It's not a valid point to say "wow, GT3b1 -q5 kills v1.0.1 -q5 in quality" because GT3b1 uses so many more bits to achieve this quality increase.

If you don't remap them, you should at least fix the nominal bitrate information displayed for q4.99 and down. q4.99 displays 179.5 kbps currently. This is wrong. It should instead display 159.7 kbps (which is what is shown for the standard 1.0.1 compile.)

Also, remapping the values would NOT throw away any of the improvements that Garf introduced, if done correctly. Right now though with this compile, we are missing nominal bitrates from 159.7 to 180. What must be done is expand the distance between q4 and q5 and insert the nominal bitrates from 1.0.1 that span from 160 to 179.8, which are q5 to q5.62. It is already understood by people that Garf's tunings start at q5, so this should not be an issue when speaking of user confusion. There should be no reason to blatantly leave out this gap of nominal bitrates from 159.7 to 179.5. I think you should, like i said, just expand the distance between q4 to q5 and insert 1.0.1's q5 through q5.62 between the current compile's q4.99 and q5. I undertstand that this is harder than I am making it sound, but it should be possible.

umm, the merged version is this one right?

http://rarewares.hydrogenaudio.org/files/o...GT3b2-1.0.1.zip

btw, in general, does ogg provide better sound per file size than lame mp3?

I just coded a file with the one linked above, its larger than the ogg 1.01 file.

I tried using the rareware's gt3b2 build. I playback using media player classic + corecodec directshow plugin.
It sounded very good but unfortunately there's clipping introduce. I'm not sure about other plugin.
It used to play perfectly before; using libvorbis 1.0.1.

I don't think that correcting the gap is the right solution.
I would rather see a "Do not restrict bitrate" check box (or command line switch), that would turn on GT3b1 optimisations.
So it would be possible to do a "-q 6" encoding and a "-q 6 -gt3" one
First one would produce nominal 180kbps, second nominal 212kbps.

Sorry about that!! I've recompiled, checked and uploaded all new compiles of the vorbis.dll for HeadAC3he. They work on 0.23a and 0.24a2, at least.

Is there a linux compile? If not, any tips on how to compile it? There's no 'configure' or 'Makefile' and for some reason, automake and his evil companions foil my every attempt to understand them.

I should explain my remark...I agree that this is what should happen, and if you're volunteering to do it that's great. but Garf has already said he doesn't have time, Monty has it in his queue for 1.1, but that could be a while, and it's not really within John's realm of expertise (though I don't doubt for a moment that he could do it if he put his mind to it).

So the only option that's available at close to 'free' is to throw out Garf's q5 tuning, which would be a mistake IMHO.

btw, GT3b2 at -q5 should be better than 1.0.1. at -q6, so while the bitrate jumps, the quality jumps even more.

Cheers, Paul

I don't think I could have expressed it better myself!!

I am getting different filesizes when using GT3b1+1.0.1 and GT3b2 at q5.
What the matter?

As I remeber when Vobis 1.0 was released q6 was spoken to be better than LAME APS in more than 50% of cases. Am I right?
If so than GT3b2 q5 (and GT3b1) should be generaly better than LAME APS?

In no way do I have the expertise to do this either, so you are right, we are going to have to wait a while.

Also, yes, I agree that it would be a mistake to throw out Garf's q5 tuning, and that isn't even taking into account that q5 is THE primary setting that I use for my own encodings currently.

Actually, for the time being, I like megar's idea:




This would be much easier to implement and would be a great interim fix.

If that doesn't happen, may I request from John33 to adjust the nominal bitrate labeling in oggdropXPd for q4.99 and lower to display the correct 1.0.1 nominal bitrates? Thanks

if you are using that gt3b1 + 1.0.1 compile that John33 released initially, that still had some floggy code in it, and that could be throwing your filesizes. John33 soon after released an updated version which is the "official" release which is now called gt3b2.

If you are not using that intial release, then you are probably using gt3b1 compiled with 1.0, and you are mistakenly calling it gt3b1 + 1.0.1.

And if you are comparing the original gt3b1 (gt3b1 + 1.0) to the new gt3b2, then, quoting John33 from that other thread, here is your answer:



Hope that helps.

One option I have been looking at is to create a dynamic oggdropXPd that used a libvorbis dll, but to provide a menu option to select whether you want to use 1.0.1, or GT3b2.

Anyone have any views on this?

It helped. Thanks.

Strange...

At -q6 (nominal 212) I'm getting files that average closer to 192. This is with music such as Pink Floyd, Rush, etc...

I would have thought the bitrates would have been higher.

Edit:

Actually, it seems I'm getting excactly the same filesizes as I did with GT3B1, so I guess all is as it should be.

bitrate = 205
channels = 2
samplerate = 44100
bitrate_nominal = 212
codec = Vorbis
vorbis_vendor = Xiph.Org/Sjeng.Org libVorbis I 20020717 (GTune 3, beta 1)
vorbis_version = 1.0 GT3b1
replaygain_track_peak = 0.99996948
replaygain_track_gain = -7.00 dB
replaygain_album_peak = 0.99996948
replaygain_album_gain = -6.83 dB
----------
13113576 samples @ 44100Hz


bitrate = 205
channels = 2
samplerate = 44100
bitrate_nominal = 212
codec = Vorbis
vorbis_vendor = Xiph.Org/Sjeng.Org libVorbis I 20030909 (GTune 3, beta 2)
replaygain_track_peak = 0.99996948
replaygain_track_gain = -7.00 dB
replaygain_album_peak = 0.99996948
replaygain_album_gain = -6.83 dB
----------
13113576 samples @ 44100Hz

You have to run autogen.sh which will create all the necessary files for making.

Just a note that I've updated my uploaded oggenc, compiled using the Intel Compiler for Linux, with the gt3b2 libraries.

http://www.hydrogenaudio.org/forums/index....howtopic=15219&

1) The bitrate you get is _always_ dependant on the input material, for all encoders.

2) None of the encoders 'restrict bitrate', so the checkbox you speak of is nonsense.

3) The nominal bitrates are correct and should not be fixed (maybe tuned to be a bit more accurate, but not set back to 1.0 values!). Don't forget that GT3 -q4.99 DOES give you higher bitrates than 1.0 -q4.99 does, because you already get the tuning.

4) The most consistent thing to do would be to have -q0 to -q5 standard 1.0, remap GT3 -q5 to -q6, GT3 -q6 to -q7, and so on. But I'm not confident enough that GT3 really always gives at least equal quality at a lower quality setting which is required to do this. Currently, if you use GT3 -q6, you always know you have better quality than 1.0 -q6, even if at sometimes increased filesizes.

You're gonna have to give me a couple more nudges in the right direction. There's no autogen.sh included in the source zip on rarewares. I grabbed vorbis-tools from cvs and tried several things to get the autogen.sh with that to work without success.

Yes, there is. It's in the root dir. And that's as far as I can go as I wouldn't know where to begin to compile in Linux!!

Umm... Not seeing it... Do I have the wrong zip file? I'm using oggenc2.3srcs.zip from rarewares linked under the heading "Oggenc2.3 using GT3b2 based on LibVorbis v1.0.1".

Ah. If you're trying to use the oggenc2.3 sources, you'll have problems because it needs FLAC libs and headers and the only libs included are the Windows compiles. I'm afraid you'll need someone with a lot more Linux knowledge to sort out compiling that under Linux.

Is there any particular reason that the ultra low bitrate stuff was dropped from this patch?

Just saw an e-mail today on the icecast mailing list from someone looking for it.

Message on icecast Mailing list

- Agent 86

vorbis libraries updated to libvorbis-1.0.1+gt3b2-1 in the RareWares Debian Repository.

...to compile on gnu/linux:

1. download src
2. unpack & repack with zip -ll (to change to linux line changes)
3.1 edit ./autogen.sh to include configure options (at bottom)
3.2 or edit ./autogen.sh to remove configure call and configure in 2 steps (what i do for debian libs)
4. copy over the images and files in /doc of the libvorbis-1.0.1 official source release (or edit ./doc/Makefile.am in that directory to exclude calls to static_docs because they are missing in the sources john33 provides)
5. chmod a+x ./autogen.sh
6. ./autogen.sh (to build configure)
7. ./configure --whatever
8.1 build with make && make install
8.2. (on debian this is - $dpkg-buildpackage -rfakeroot)


later

(edit: silly typo, thanx roberto)

(a) IIRC, Garf said that was his proposal when first talking about integrating GT3b1 into 1.0.1; and

(b) It was only ever experimental and far from finished.

If someone else recalls differently, I'm quite ready to be corrected!!

You mean 1.0.1, right?

3) Yeah, you are right in that they are not equal to the 1.0.1 values, but for instance 4.99 is NO WHERE near 179.5 kbps, though. It is much closer to the q4.99 of 1.0.1, so they do need to be corrected some. One thing I am not understanding is that people are saying that between q4 and q5, the encoding is an "interpolation" of 1.0.1's q4 and GT3's q5. From what I thought, NO GT3 tunings start until q5.

4) I agree. Currently using GT3 q6 produces better than 1.0.1 q6, but you are not sure if GT3 q5 is better than 1.0.1 q6. Why does it have to be a whole number jump though? Can you say positively that at equal bitrates, GT3 is better quality than 1.0.1? If so, that I guess that would be the starting point to test lower, but it's a really tough call from there.

Ah, no wonder I was confused. I had entirely the wrong batch of sources. Thank you for your patience.

...Now to write an ebuild...

Why not throw in gt3b1 for people who want to play with floggy?

oggdropXPd never provided access to the floggy code anyway!!