Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Vorbis 1.1 RC1 in SVN (Read 66321 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Vorbis 1.1 RC1 in SVN

Reply #50
This version still has probems with the badvilbel sample. Is there anyway this can be fixed? It's pretty much the only reason I won't use vorbis. Problem seems to go away for me at q8, anything below that the artifacts are extremely obvious.

Vorbis 1.1 RC1 in SVN

Reply #51
Quote
This version still has probems with the badvilbel sample. Is there anyway this can be fixed? It's pretty much the only reason I won't use vorbis. Problem seems to go away for me at q8, anything below that the artifacts are extremely obvious.
[a href="index.php?act=findpost&pid=224669"][{POST_SNAPBACK}][/a]


What sort of problems are you hearing?

Vorbis 1.1 RC1 in SVN

Reply #52
Quote
Quote
This version still has probems with the badvilbel sample. Is there anyway this can be fixed? It's pretty much the only reason I won't use vorbis. Problem seems to go away for me at q8, anything below that the artifacts are extremely obvious.
[a href="index.php?act=findpost&pid=224669"][{POST_SNAPBACK}][/a]


What sort of problems are you hearing?
[a href="index.php?act=findpost&pid=225040"][{POST_SNAPBACK}][/a]


I only hear the problem during the parts with the loud static noise. I guess the problem also sounds like static but of a different kind and not as loud. Try listening to it with headphones @ q6, you will definitely hear it.

I also want to add that during the loud static parts the bitrate goes up to about 450kbps  with q6 and about 580kbps with q8.

Vorbis 1.1 RC1 in SVN

Reply #53
Quote
This version still has probems with the badvilbel sample. Is there anyway this can be fixed? It's pretty much the only reason I won't use vorbis. Problem seems to go away for me at q8, anything below that the artifacts are extremely obvious.
[a href="index.php?act=findpost&pid=224669"][{POST_SNAPBACK}][/a]


Not to attack you, nor to nitpick or over generalize, but can you expand upon why you will not use Vorbis, only and specifically because of the presence of this problem sample?
WARNING:  Changing of advanced parameters might degrade sound quality.  Modify them only if you are expirienced in audio compression!

Vorbis 1.1 RC1 in SVN

Reply #54
Yes, this one problem sample is the only reason I won't use Vorbis. It was between Vorbis and LAME, I went with LAME --aps because it didn't seem to have a problem with this sample. So far I haven't heard a problem with any song while using LAME, but that doesn't mean there aren't any. I'm not properly trained to pick out artifacts so there could be many of them I just don't know what to listen for. But I don't think any training is needed to hear the problems with this sample.

Vorbis 1.1 RC1 in SVN

Reply #55
Quote
This version still has probems with the badvilbel sample. Is there anyway this can be fixed? It's pretty much the only reason I won't use vorbis. Problem seems to go away for me at q8, anything below that the artifacts are extremely obvious.
[a href="index.php?act=findpost&pid=224669"][{POST_SNAPBACK}][/a]

Interesting sample indeed. The problem is very obvious up to quality 6.99 but going to disappear from quality 7 to 8. IMO it is worth trying to explore where the big difference between 6.99 and 7.00 comes. I don't know if this problem can be fixed easily or not but want to fix this problem.

Vorbis 1.1 RC1 in SVN

Reply #56
i did some test with badvilbel sample and found that encoded with garf's gt2 @ -b 999 settings (tuned vbr ~160 kb/s) it gives me average bitrate 210 kb/s and it's transparent to me. but encoded with gt3b1 @ -q 5 average bitrate is 312! and it has very obvious distortion.
so conclusion is that has been something wrong during development after rc2 was released.

sorry for bad english 

ps: what about give back vorbis development to rc2 stage?

Vorbis 1.1 RC1 in SVN

Reply #57
Quote
This version still has probems with the badvilbel sample. It's pretty much the only reason I won't use vorbis.
[a href="index.php?act=findpost&pid=224669"][{POST_SNAPBACK}][/a]


oh for mercy's sake 

any reasonable codec *shouldn't* be able to encode that sample with any type of reasonable compression.  it's just noise... and i don't mean that subjectively; it really is scientific noise.  compression works because the encoder can judge what data can be thrown out without affecting the perceived sound - that can't be done here because there's a random distribution of audio elements, as in any noise.  compression also works because patterns in data can be represented in simpler terms - can't do that here either because there's absolutely no pattern to random noise.

you've already said that you don't know what to listen for to pick out artifacts in music.  add to that that you expect a good encode of something that's inherently designed to resist encoding.  i'd say that you'd do well to look over the whole site and listen to other views on what format to use.  unless you really are trying to encode someone's "electronic symphony of nails on a chalkboard in no particular key," then ogg will more than meet whatever tasks you give it (*reasonable* tasks).  a sample like this is better left to a lossless codec, but that doesn't mean that the lossy codec in question is broken in some way.

ogg does not have problems with the sample... the sample is the problem.

Vorbis 1.1 RC1 in SVN

Reply #58
I have a feeling that we won't see coupled 5.1 when 1.1 comes out.

Vorbis 1.1 RC1 in SVN

Reply #59
Quote
I have a feeling that we won't see coupled 5.1 when 1.1 comes out.
[a href="index.php?act=findpost&pid=225856"][{POST_SNAPBACK}][/a]


Who knows. Do you have any source you can cite?

If Monty intends to do so I think he should call it "Vorbis 1.0.2 Steroids Edition™" but not Vorbis 1.1...

Vorbis 1.1 RC1 in SVN

Reply #60
Interesting.  Ive just tried the GT2 encoder @ -b 999 (based on the old RC2?  Sorry if im getting confused im just getting up to speed  with all the different versions) with my problem sample (http://www.hydrogenaudio.org/forums/index....showtopic=23424)

I get an avg bitrate of 184 and no sign of the problems ive been experiencing.  The file is actually only very slightly bigger than megamixII @q4 (which sounds terrible in comparison)  586KB Vs 563KB for 26secs.  They both have roughly the same avg bitrate but one sounds much better than the other.    All the newer encoders fluctuate the bitrate between higher and lower peaks and troughs.  Whereas the old encoder doesnt flucuate as much.  IE its min bitrate is more, but its max bitrate is less, but avg out roughly the same.    This is the same even for gt3b2 at >q5.  I have abxd this with the original up to q7.

Vorbis 1.1 RC1 in SVN

Reply #61
Quote
Who knows. Do you have any source you can cite?

If Monty intends to do so I think he should call it "Vorbis 1.0.2 Steroids Edition™" but not Vorbis 1.1...
[a href="index.php?act=findpost&pid=225873"][{POST_SNAPBACK}][/a]


According to this:

Code: [Select]
r7047 | xiphmont | 2004-07-08 13:07:11 +0900 (Thu, 08 Jul 2004)

Tag 1.1 libvorbis release candidate 1; pending any last minute bugfixes;
this will be 1.1


This seems to suggest that apart from bugfixes, 1.1RC1 willl be 1.1.

Vorbis 1.1 RC1 in SVN

Reply #62
It does seem pretty bad. I just abxed it with ease and that's amazing for me.

Code: [Select]
-------------------------------------
WinABX v0.23 test report
07/14/2004 22:56:44

A file: D:\listeningTests\Originalsmall.wav
B file: D:\listeningTests\megamix2q4.wav

22:57:08    1/1  p=50.0%
22:57:13    2/2  p=25.0%
22:57:15    3/3  p=12.5%
22:57:20    4/4  p= 6.2%
22:57:29    5/5  p= 3.1%
22:57:32    6/6  p= 1.6%
22:57:35    7/7  p= 0.8%
22:57:39    8/8  p= 0.4%
22:57:41    9/9  p= 0.2%
22:57:49  10/10  p< 0.1%
22:57:51  test finished


It sounds like a puff of air in the first second. 

Definitely a difference detectable between q 4 and 5.  q 5 seems to sound better (less noise)

Code: [Select]
-------------------------------------
WinABX v0.23 test report
07/14/2004 23:01:01

A file: D:\listeningTests\megamix2q4.wav
B file: D:\listeningTests\megamix2q5.wav

23:01:15    1/1  p=50.0%
23:01:21    2/2  p=25.0%
23:01:25    3/3  p=12.5%
23:01:28    4/4  p= 6.2%
23:01:31    5/5  p= 3.1%
23:01:34    6/6  p= 1.6%
23:01:37    7/7  p= 0.8%
23:01:40    8/8  p= 0.4%
23:01:45    9/9  p= 0.2%
23:01:49  10/10  p< 0.1%
23:01:51  11/11  p< 0.1%
23:01:53  test finished


I think I know the reason why q 5 (GT3b2 mode) works better than q 4 (QKTune mode).  I'll look into it.  Should be very interesting.  Excellent sample, btw.  Many thanks.

Vorbis 1.1 RC1 in SVN

Reply #63
Cool, glad if it ends up being a help in any way.    I can abx gt3b2 up to q7 (havent actually tried q8 though, but not bad thru my useless onboard card and crappy phones).  Its at 2.5 secs that its more obvious for gt3b2 @q5 and above.

  It does seem that it might be because the bitrate troughs too low to cope with it.  (whereas encoded by GT2 it doesnt suffer from this).    Look forward to testing whatever you come up with

Vorbis 1.1 RC1 in SVN

Reply #64
Quote
This seems to suggest that apart from bugfixes, 1.1RC1 willl be 1.1.
[a href="index.php?act=findpost&pid=225880"][{POST_SNAPBACK}][/a]


Indeed... well... at least an official release with a nice quality increase... better than nothing.

Vorbis 1.1 RC1 in SVN

Reply #65
Quote
I think I know the reason why q 5 (GT3b2 mode) works better than q 4 (QKTune mode).  I'll look into it.  Should be very interesting.  Excellent sample, btw.  Many thanks.
[a href="index.php?act=findpost&pid=225886"][{POST_SNAPBACK}][/a]



Out of curiousity what are your preliminary thoughts on the problem?
r3mix zealot.

Vorbis 1.1 RC1 in SVN

Reply #66
Quote
Interesting.  Ive just tried the GT2 encoder @ -b 999 (based on the old RC2?  Sorry if im getting confused im just getting up to speed  with all the different versions) with my problem sample (http://www.hydrogenaudio.org/forums/index....showtopic=23424)

I get an avg bitrate of 184 and no sign of the problems ive been experiencing.  The file is actually only very slightly bigger than megamixII @q4 (which sounds terrible in comparison)  586KB Vs 563KB for 26secs.  They both have roughly the same avg bitrate but one sounds much better than the other.    All the newer encoders fluctuate the bitrate between higher and lower peaks and troughs.  Whereas the old encoder doesnt flucuate as much.  IE its min bitrate is more, but its max bitrate is less, but avg out roughly the same.     This is the same even for gt3b2 at >q5.  I have abxd this with the original up to q7.
[{POST_SNAPBACK}][/a]

I hear similar artifacts from this sample as the badvilbel sample calx provided in this thread. These samples require many short blocks (lame-aps encodes these samples in short blocks as many as 50%!). If we tighten preecho/postecho thresholds, the problem takes a turn for the better. That's why the problem almost disappear at quality 7, where vorbisenc starts to use _psy_global_44[3] (the 2nd severest preecho/postecho tuning value), I think.

Changing _global_mapping_44 (setup_44.h) to use the 2nd severest tuning value at quality 4 improves the problem much (but the problem is sill there). The encoded sample is here (copy and paste URL): [a href="http://www.geocities.com/nyaochi2000/sample/OrbitalMeltdown-q4test.zip]http://www.geocities.com/nyaochi2000/sampl...down-q4test.zip[/url]
This tuning introduces bitrate bloating with some killer samples (e.g., 154Kbps for badvilbel sample). IMO it's challenging to deal with this kind of samples by tweaking parameters without bitrate bloating.  I have no idea why current vorbisenc suffers from these samples, but I want to check later whether vorbisenc uses short blocks properly or not for these samples. This is my speculation. 

EDIT: Be sure to copy the URL and paste it to the location bar in your web browser due to the restriction of geocities.com

Vorbis 1.1 RC1 in SVN

Reply #67
Dont know how pertinent/relevant it is (please excuse me if im mistaken on anything, im certainly no expert on this), but i just tried the following after noting that the bitrate peaked and troughed far more on all the newer builds than on GT2.    It made sense to me to at least try smoothing the troughs out particularly.

I tried:  --managed -b 170 -m 160 as a test (with megamix II as the build).  The resulting file was 177 avg bitrate (almost identical to q4), whilst it doesnt sound great, it does make a better job of the problem sample than just selecting q4 (in fact it sounds better than q5 to my ears regarding the problem at least - although in may have slightly negative effects elsewhere)

EDIT:  Posted this before i saw your reply Nyaochi.  Id be very interested to see what you come up with.  (btw you link seems dead at the moment)

Vorbis 1.1 RC1 in SVN

Reply #68
NOTE- all with reference to problem sample mentioned above. 

A little more testing has been interesting (for me at least).  Q5 with megamixII (or gt3b2) yeilds huge avg bitrates of ~244, yet is still readily ABXable from the original.  Personally being brutally honest i find this worrying that an encoder such as ogg vorbis should stumble on any sample (And further not be close to transparency - i have ABXd u p to q7  - not sure of bitrate) so badly at this kind of bitrate. 

I dont know if its a short block/pre/post echo related issue but i expanded my above experiment and used --managed -b 230 -m 200 (with megamixII) and achieved a bitrate on this sample of 224 (smaller than q5 with megamixII or gt3b2) and it sounds all but indistinguishable from the original (i havent attemped a proper ABX on this as yet, but the difference is staggering - but what i would expect from this kind of bitrate to be honest).     

Obviously i dont know the reasons behind this, perhaps the managed mode with these parameters is affecting the short bit allocation (or pre/post echo) in some way, i dont know.  But I do know that to be able to reach pretty much transparency at less than q5 bitrates when q7 doesnt, just by putting a couple of parameters in place is not good (obviously this is just in my view)

Vorbis 1.1 RC1 in SVN

Reply #69
Quote
I hear similar artifacts from this sample as the badvilbel sample calx provided in this thread. These samples require many short blocks (lame-aps encodes these samples in short blocks as many as 50%!). If we tighten preecho/postecho thresholds, the problem takes a turn for the better. That's why the problem almost disappear at quality 7, where vorbisenc starts to use _psy_global_44[3] (the 2nd severest preecho/postecho tuning value), I think.

Changing _global_mapping_44 (setup_44.h) to use the 2nd severest tuning value at quality 4 improves the problem much (but the problem is sill there). The encoded sample is here (copy and paste URL): http://www.geocities.com/nyaochi2000/sampl...down-q4test.zip
This tuning introduces bitrate bloating with some killer samples (e.g., 154Kbps for badvilbel sample). IMO it's challenging to deal with this kind of samples by tweaking parameters without bitrate bloating.   I have no idea why current vorbisenc suffers from these samples, but I want to check later whether vorbisenc uses short blocks properly or not for these samples. This is my speculation. 

EDIT: Be sure to copy the URL and paste it to the location bar in your web browser due to the restriction of geocities.com
[a href="index.php?act=findpost&pid=225933"][{POST_SNAPBACK}][/a]


That is exactly what I did (changing the _global_mapping_44) and the problem is reduced quite a lot, though there is something like a 40 kbps bloat    I don't know whether it is a good idea to do it though.

It would be nice to have a small tool that gives us some idea about the distribution of block sizes in a vorbis file or graphically analyse them.

Vorbis 1.1 RC1 in SVN

Reply #70
Quote
Quote

I think I know the reason why q 5 (GT3b2 mode) works better than q 4 (QKTune mode).  I'll look into it.  Should be very interesting.  Excellent sample, btw.  Many thanks.
[{POST_SNAPBACK}][/a]



Out of curiousity what are your preliminary thoughts on the problem?
[a href="index.php?act=findpost&pid=225914"][{POST_SNAPBACK}][/a]


Basically nyaochi summed it up.  If you zoom into the waveform in CoolEdit or Audition, you see that within a short space of time, it consists of very fine peaks.  I assume these are the 'microattack' samples that guruboolez talks about.  Vorbis needs to switch to short blocks in order to encode these effectively and it uses a thresholding scheme.  Since q 4 uses rather 'light' thresholds, Vorbis doesn't switch to short blocks just quite enough, causing a smearing effect (the noise).  This can rectified by switching to more aggressive threshold, but it causes bitrate bloat and even then, it doesnt seem to be transparent.

Here is a (tentative) Megamix 2.1 where q 4 now uses more aggressive preecho/postecho threshold:

[a href="http://www.rarewares.org/quantumknot/oggenc-megamix21.exe]http://www.rarewares.org/quantumknot/oggenc-megamix21.exe[/url]

Vorbis 1.1 RC1 in SVN

Reply #71
I wonder: why isn't it possible to change the sensivity to attacks by a simple command line, rather than modify the code itself? It could be interesting for some people interesting to code with the best quality possible some specific audio tracks (some electronic album for exemple). Other people would choose the basic setting, but power-use shouln't have this choice?
It's like GT3/QK32 aditionnal tuning: why not an option for them?

Something like that in OggDropXPd:

[span style='font-size:12pt;line-height:100%'][ ] [/span]use QK32 tuning (may increase average bitrate by 0...30%)
[span style='font-size:12pt;line-height:100%']
  • [/b][/span]use GT3b2 tuning (may increase average bitrate by 0...30%)
    [span style='font-size:12pt;line-height:100%']
    • [/b][/span] use agressive short-block switching (may increase average bitrate by x%)
Wavpack Hybrid: one encoder for all scenarios
WavPack -c4.5hx6 (44100Hz & 48000Hz) ≈ 390 kbps + correction file
WavPack -c4hx6 (96000Hz) ≈ 800 kbps + correction file
WavPack -h (SACD & DSD) ≈ 2400 kbps at 2.8224 MHz

Vorbis 1.1 RC1 in SVN

Reply #72
Quote
I wonder: why isn't it possible to change the sensivity to attacks by a simple command line, rather than modify the code itself? It could be interesting for some people interesting to code with the best quality possible some specific audio tracks (some electronic album for exemple). Other people would choose the basic setting, but power-use shouln't have this choice?
It's like GT3/QK32 aditionnal tuning: why not an option for them?

Something like that in OggDropXPd:

[span style='font-size:12pt;line-height:100%'][ ] [/span]use QK32 tuning (may increase average bitrate by 0...30%)
[span style='font-size:12pt;line-height:100%']
  • [/b][/span]use GT3b2 tuning (may increase average bitrate by 0...30%)
    [span style='font-size:12pt;line-height:100%']
    • [/b][/span] use agressive short-block switching (may increase average bitrate by x%)
      [a href="index.php?act=findpost&pid=226047"][{POST_SNAPBACK}][/a]


That's an good suggestion.  I guess oggenc does have much less tweaking options than mppenc.

Vorbis 1.1 RC1 in SVN

Reply #73
Quote
That's an good suggestion. I guess oggenc does have much less tweaking options than mppenc.


Or even better a few added command-line switches to the advanced-encode-option on the encoder that allow you to tweak noise biasing and mapping values, etc? Would be quite convenient ;-D.
budding I.T professional

Vorbis 1.1 RC1 in SVN

Reply #74
I was thinking of suggesting something like this myself, it would be a useful feature to have.    I will try the revised version you have linked.  I tried Nyaochi's tweaked version and it is indeed better, but still not great.    I am still a bit confused as to why the problem can be alleviated so much (more than in Nyaochis version) by the use of the managed option as i mentioned above, without increasing the bitrate.    As I mentioned before I did this to try to mimic the behaviour of the old GT2 encoder (-b 999 setting used) which didnt display this problem at all, to not have as large bitrate swings occurring.    Low and behold mimicing (as far as possible using the managed -b 170 -m 160 option) the less dramatic swings of GT2 results in a dramitcally better sound and no increase in bitrate. 

I was seeing huge bitrate swings, from as little as 130 to way over 300.  A 200+kbps range.  Now thats all great if its doing it right, but to me (please tell me if im wrong, im only going logically on the data i have and the limited knowledge i have also) its not.  We always talk about wasting bits, well in a way chucking over 300 kbps at one section and then going all the way down to 130 in the next section and causing audible problems is wasteful.  A slight re-apportioning gives better results. 

Perhaps rather than just switching on things that increase the bitrate to overcome the problem should you find one, there could be another switch to use in conjunction with it that will sacrifice bits elsewhere in order to provide a more uniform level of transparency over the whole track.  (this would allow you maintain the bitrate level of encoding that you initially wanted)

EDIT:

Ive tested megamix2.1.  It is an improvement.  But its given me a huge average bitrate of 210kbps for q4.    And doesnt sound any better than the managed mode settings i used for 35kbps less.