Skip to main content
Topic: RC3 Quality graphs (Read 4425 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

RC3 Quality graphs

I have made some quality analysis of RC3.
Quality perceived by eaqual in function of -q
for several samples and one full reference song.

I have placed in the same graph bitrate allocation
and analysed also mp3 quality and bitrate with
lame --alt-preset standard

It should help those trying to decide their own
optimal -q

Can be found at:

RC3 Quality graphs

Reply #1
I'm not surprised that vorbis uses so few bits to encode 60.wav, because of its very simple structure. Similarly, I'd be suspicious of the EAQUAL results for 60.wav - it's quite possible that it's a degenerate case for EAQUAL, which may be particularly sensitive to artifacts with this sample.

In fact, I'm very suspicious of EAQUAL in general  - although what you are doing is certainly more valid that saying that one codec is better than another based on a difference in EAQUAL value of less than 0.1...

RC3 Quality graphs

Reply #2
60 is a very simple structure, but there are in the samples other simple structures that however give more or less the same general shapes of the other files, or the reference song.

My feeling is that there is a bug here, anyway my ears tell me they do not care  It should be only important
for Monty in the case he sees something unexpected,
for further tweaking.

Regarding the MP3, of course I was not comparing codecs (I understand from Garf that eaqual is better
suit for comparing among different quality levels of the
same codec rather than same quality of different codecs), but a reference. -q x means nothing for many people, and ODG -1 even less. By having a lame level
with a standard switch I intend to provided a wider view
(without making the graph to annoying

It ended up being a script since I kept adding more options, but in principle was very short and straight forward. I was looking a -q where ODG starts getting asymptotically. I think I will end up using -q 6 or 7.

But I will need to wait for v1.0 since if I go with -q 7 is because I can peel it, and Monty has said today that RC3 files will not be peeled by peeler 1.0. RC3 is peelable but you will need to write your own peeler.

So I will keep the script around for the future releases

Cheers, AGS.

RC3 Quality graphs

Reply #3
So I will keep the script around for the future releases

I look forward to seeing it with RC4 - although it would be nice to reduce the number of samples you used (it took me far too long to understand your graph fully, although I was without the aid of coffee  ). I'll be regenerating my bitrate-quality data for RC4, so feel free to use that (I use a smaller step size than you, which brings out some interesting features that are lost when using 0.5).

RC3 Quality graphs

Reply #4
No problem. I am also willing to see how RC4 improves quality for lower bitrates  Anyway you can send me
a file with the same format I showed in my page (that phpin.txt) and I can create a graph with that.

I would create a do-it-yourself page were people upload the file and get the graph, but I am concern about Trojans. That file contains full blown php, so by now I need first to see the contents myself

I would have liked to go with smaller increments, but although my desktop is an Win Athlon XP, my server only a K6III+ (at least can be always-on with low power consumption  and I belong to the UNIX troupe (and ogg123 for decoding was linux-only). And of course I wanted to see the results FAST. I can now reduce the increment and wait for a week more calm

I'll try to get linux on my desktop too by RC4, but in any case I will be happy  if you provide the processed information and avoid me overheating my room. By that time will be summer

In future tests I will reduce the amount of samples. I went with many since before hand did not know what to expect and wanted to be on the safe side. Now I can remove those samples that get too similar results, and avoid having colors as yellow, bright yellow, dark yellow, yellowish, gold, golden, goldie, etc

Cheers, AGS

RC3 Quality graphs

Reply #5
I have a request; would it be possible to plot the GT2  128kbps, 160kbps and 350kbps modes on that graph?

I'd like to know how they compare vs the RC3 modes.


RC3 Quality graphs

Reply #6
My pleasure Garf but...

source code? binary?

I can only do it automatically on linux. As far as I remember that on-line version is only windows binary, isn't it?

BTW what were exactly your tunings? Weren't they
patches you submitted after RC2 that are now in RC3?

Jon: My transient window reads:

### Transcoding: +labilirrubina_ogg_00.0.wav exists. Updating and skiping...
### Transcoding: +labilirrubina_mp3_standard.wav exists. Updating and skiping...
### EAQUAL: +labilirrubina_ogg_00.0.odg exists. Updating and skiping...
### EAQUAL: +labilirrubina_mp3_standard_00.0.odg exists. Updating and skiping...
### Transcoding: +labilirrubina.wav -> +labilirrubina_ogg_00.1.wav
Opening with wav module: WAV file reader
Encoding standard input to
        standard output at quality 0.10
        [100.0%] [ 0m00s remaining] -

Done encoding.

        File length:  4m 05.0s
        Elapsed time: 3m 50.7s
        Rate:        1.0643
        Average bitrate: 69.6 kb/s

### EAQUAL: +labilirrubina.wav -> +labilirrubina_ogg_00.1.wav

You see, .1 increments. Lets see how long it takes
If it finishes before the weekend I might even try .001

I am not expecting to discover any new things, but the graphics will be much cooler

Cheers, AGS

RC3 Quality graphs

Reply #7
Originally posted by AGS
My pleasure Garf but...

source code? binary?

I can only do it automatically on linux. As far as I remember that on-line version is only windows binary, isn't it?

Install in place of your normal vorbis lib.

BTW what were exactly your tunings? Weren't they
patches you submitted after RC2 that are now in RC3?

Not really patches...modifications to the psymodel tuning. Since the psymodel changed, RC3 is a bit different.


RC3 Quality graphs

Reply #8
That means oggenc RC3 will run properly and behave like RC2 with libvorbis?

I tried to configure/compiled and got:

checking for Ogg... no
*** Could not run Ogg test program, checking why...
*** The test program failed to compile or link. See the file config.log for the
*** exact error that occurred. This usually means Ogg was incorrectly installed
*** or that you have moved Ogg since it was installed. In the latter case, you
*** may want to edit the ogg-config script:
configure: error: must have Ogg installed!

Wanted to have it running overnight, but I am too tired to find the problem. Will run tomorrow night. Good night. Time to sleep.

RC3 Quality graphs

Reply #10
Very nice work AGS, very useful too.

Do you think you could plot three seperate graphs seperately instead? Namely:

bitrate vs -q
ODG vs -q
ODG vs bitrate

I think plotting both bitrate and ODG vs -q on the same graph isn't that useful and can be confusing. Also, the ODG vs bitrate graph might be of interest.


RC3 Quality graphs

Reply #11
If it's of any use to anybody, for reasons I can't think of at the moment, I've still got a tar.gz kicking around of the nightly CVS dated 9 Dec 01, ie. pre- RC3.

My compiles and utilities are at

RC3 Quality graphs

Reply #12
OK, maybe I'm just stupid (and I'm not ruling that out), but when I go to all I see is a threaded discussion list.
It's is not, it isn't ain't, and it's it's, not its, if you mean it is.  If you don't, it's its.

RC3 Quality graphs

Reply #13
Well, some people have reported that.

I was using a redirection provider that is currently down. Then I opted for these days to read the HTTP_REFERER and call javascript history.go(-2) if you did not come from the right place ie: trying to see some other pages that you were not supposed to. Just pictures of my baby

But it seems that MANY people are removing the HTTP_REFERER. I guess you are using webwasher?

Anyway, I have removed that filter now. My other pages became not accessible by this from outside, but I am not expecting visitors there, and should be only until my provider is back (hopefully very soon)

Try again.

Back to the main issue, I am trying to satisfy some of the requests.

1) I have reduced the increments from .5 to .1, it is still processing. EAQUAL is very slow, and I have one full song (now being calculated 100 times!) That graph should be up tomorrow.

2) I have been asked to reduce the amount of samples. Actually the more the better results, but the graphic gets confusing for some.

I thought first to remove some samples. But after seeing no slashdot effect  I decided to switch back to dynamic pages + a form. I have got no load problems. This way I will let the user turn off and on any line as wish, chart size, etc.

If I get inspired that will be online before bed time.

3) tangent requests should be trivial, all the data is already there. Probably will go together with 2)

4) Garf has requested to graph his tuned RC2. I need to wait till 1) is finish, or none of them will finish soon  Probably up in a couple of days.


Anyway, when there is something new two see I will announce it here.

Cheers, AGS.

SimplePortal 1.0.0 RC1 © 2008-2019