(note: '-m' won't do a lot, if anything, without '--managed')
I compressed Coldplay's "Yellow" with - aoTuV beta 4.51 and libogg 1.1.3 (static gcc 4 compile) with impulse_trigger_profile - oggenc 1.0.1 (ubuntu's official build)-q 1 -m 80oggenc: 2.4 mbaoTuV: 2.8 mb (+16%)
Both files' bitrates go from 70 to 90 (-m 80 does not work that well). I hear no difference side by side.My question is: what is the goal of the aoTuV encoder? Better quality no matter is that means bigger filesizes?
I also encoded that song with mp3Lame 3.96.1switches: -V 8 --vbr-new Filesize: 3.1 mb (+34%) I can hear the differences in some parts.
I was running with q 1 alone, but some files were too many kbps below 80 so I decided to use q 1 and -m 80 and it generated a bigger files for the same songs so I guess it does something but it does not force bitrate above 80kpbs for every frame.Should I stop using -m 80 at all? (I don't want to use --managed)
My question is: what is the goal of the aoTuV encoder? Better quality no matter is that means bigger filesizes?
the trade-off between quality and small filesize is something that the user decides by choosing a quality level.
What you probably ment is you try to improve the quality per bit ratio, right?
Aoyumi, will it be possible to modify libvorbis so that if one use -q1 -m80, the effective minimal bitrate for each frame is 80 kb/s (idem for -M80)? This is useful for that devices that support a min or a max bitrate, as needed by fedetxf, so we don't need to use a higer quality level, such as -q2, to be sure we are not under the minimum.
So I see auTuV generated a 5.91% bigger file in the first case and a 5.65% bigger in the second.The -m80 switch in both cases has some effect (it is not ignored), but it does not enforce a minimum as expected. In the documentation is doesn't say the -m value is not enforced unless --managed is used. What is the point of -m without --managed if it still produces bitrates below the specified? In case of oggenc even the average is below 80, so we are sure it is not working. In the aotuv case the average is above 80, but XMMS shows the bitrate going below 80 is different parts.
I may be misunderstanding aotuv's gaols, but it seems to me aotuv's q1 is oggenc's q1.5 or something similar.
I am not very enthusiastic by aotuv's results. I get consistent bigger files and even if I had dull ears and I were missing the quality improvements (that I don't percieve), I could still encode with oggenc's q2 or q3 to get better quality if I did not mind for the higher bitrates.I may be misunderstanding aotuv's gaols, but it seems to me aotuv's q1 is oggenc's q1.5 or something similar.
Please use managed mode, when the bit rate needs to be forced. example:-b80 -m80-b80 --managedetc. Moreover, the bit rate is not managed in quality mode.
And about aotuv improvements. I'm sure aotuv's generated files have better quality, but they also have higher bitrates, so q1 vs. q1 are not comparable. It is like comparing oggenc 1.0.1 at q1 with oggenc 1.0.1 at q1.5.The particular song encodes below the nominal bitrate (80 kbps) with both implementations. Using headphones I can't hear any difference at all so my view is:
ABC/HR for Java, Version 0.52b, 14 8・2006Testname: Tester: haregoo1L = E:\Desktop\ogg\macabre_aoTuV_q1.wav2R = E:\Desktop\ogg\macabre_aoTuV_-b80 -m80.wav3L = E:\Desktop\ogg\macabre oggenc101_q1.5.wavRatings on a scale from 1.0 to 5.0---------------------------------------General Comments: ---------------------------------------1L File: E:\Desktop\ogg\macabre_aoTuV_q1.wav1L Rating: 3.01L Comment: ---------------------------------------2R File: E:\Desktop\ogg\macabre_aoTuV_-b80 -m80.wav2R Rating: 3.02R Comment: ---------------------------------------3L File: E:\Desktop\ogg\macabre oggenc101_q1.5.wav3L Rating: 2.03L Comment: irritating additional noise---------------------------------------ABX Results:E:\Desktop\ogg\macabre_aoTuV_q1.wav vs E:\Desktop\ogg\macabre oggenc101_q1.5.wav 8 out of 8, pval = 0.0030---- Detailed ABX results ----E:\Desktop\ogg\macabre_aoTuV_q1.wav vs E:\Desktop\ogg\macabre oggenc101_q1.5.wavPlayback Range: 10.406 to 14.866 1:43:07 AM p 1/1 pval = 0.5 1:43:10 AM p 2/2 pval = 0.25 1:43:13 AM p 3/3 pval = 0.125 1:43:15 AM p 4/4 pval = 0.062 1:43:19 AM p 5/5 pval = 0.031 1:43:22 AM p 6/6 pval = 0.015 1:43:27 AM p 7/7 pval = 0.0070 1:43:30 AM p 8/8 pval = 0.0030
aoTuV 4.51 -q 1.0 (bitrate 79kbps)aoTuV 4.51 -b 80 -m 80 (bitrate 84kbps)oggenc 1.0.1 -q 1.5 (bitrate 80kbps)Even if you could not find any differences, there can be differences.Evaluation with only 1 sample does not reflect real peformance on various music.This test means aoTuV 4.51 performs better on this sample for me.
If I test with the music I listen to, then why should I care jazz, tango or classical streams behave differently. I'm not evaluating the encoder in general, I'm trying to see what encoder to use for my music.
I'm not discussing quality since I don't have an expensive sound system, I'm just encoding for my portable player, but to me it is hard to see the advantage or aotuv simply because I can't compare with the same q value. I'd have to stick to a given bitrate which is hard when using vbr encoders.
Quote from: Aoyumi on 13 August, 2006, 03:30:03 AMPlease use managed mode, when the bit rate needs to be forced. example:-b80 -m80-b80 --managedetc. Moreover, the bit rate is not managed in quality mode.That should be stated in the help and man pages.
Please convey the opinion to the developer of oggenc. I am no concern at oggenc.
Quote from: Aoyumi on 15 August, 2006, 10:47:11 AMPlease convey the opinion to the developer of oggenc. I am no concern at oggenc.I know. Don't get mad at me.