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: aoTuV vs. oggenc 1.0.1 filesize (Read 20339 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

aoTuV vs. oggenc 1.0.1 filesize

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 80

oggenc: 2.4 mb
aoTuV:  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 mp3
Lame 3.96.1
switches: -V 8 --vbr-new
Filesize: 3.1 mb (+34%)

I can hear the differences in some parts.

aoTuV vs. oggenc 1.0.1 filesize

Reply #1
Yes it is true that oggenc 1.0.1 will typically produce slightly smaller files than aoTuV at the same settings.
(note: '-m' won't do a lot, if anything, without '--managed')

I'll let someone else with better knowledge of Vorbis' internals answer the rest, but you are sort of on the right track.
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

aoTuV vs. oggenc 1.0.1 filesize

Reply #2
(note: '-m' won't do a lot, if anything, without '--managed')


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)

aoTuV vs. oggenc 1.0.1 filesize

Reply #3
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 80

oggenc: 2.4 mb
aoTuV:  2.8 mb (+16%)


Why you want to use -q1 (which match a bitrate of about 80 kb/s) with -m80?

Quote
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?


aoTuV has a better quality at the same bitrate. aoTuV has also changed how the bitrate is used in different file: on difficult samples uses a higher bitrate, on easy samples a lower one. You should not use -m or -M switch, unless you are interested in having a known bitrate. If you find -q1 sound not so good use -q2,

Quote
I also encoded that song with mp3
Lame 3.96.1
switches: -V 8 --vbr-new
Filesize: 3.1 mb (+34%)

I can hear the differences in some parts.

aoTuV vs. oggenc 1.0.1 filesize

Reply #4
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)

use ogginfo to check your files, with 1.0.1 I think you needed to specify --managed whereas with latest aotuv you don't. Check your args and the the values being used, because you may want -m 80000 or some similar figure.

karl.

aoTuV vs. oggenc 1.0.1 filesize

Reply #5
I'm encoding for my portable player. I want q 1 (good enough quality and small files), but the player only plays ogg from 80kbps and up, so with q 1 some songs are not played, so I increased the qality to q 2 (96 about kbps).

The player seems to accept up to 80 +/- 5 kbps, sometimes with q1 you end up with 70 or less and that is where it fails.

I thought -m 80 was making a difference since the files were bigger. Maybe I have to stick to q2 alone for those songs. What do you think?

aoTuV vs. oggenc 1.0.1 filesize

Reply #6
Remember that you can use fractions, e.g. -q 1.5

aoTuV vs. oggenc 1.0.1 filesize

Reply #7
I did a little bit more research.

Ogginfo tells me all my ogg file are corrupted!! it sais it found an empty space at some offset. All files play OK everywhere.

I notice the man page for oggenc is wrong.
It sais -m takes a number in kbps, but ogginfo tellms me -m 80 is 0.08 kbps minimum bit rate. So -m takes a number in bps.

aoTuV vs. oggenc 1.0.1 filesize

Reply #8
Last time I checked (with march lancer).. something like -b 80 -m 80 -M 80 --managed only changed in bitrate maybe +/- 2kbps.  If just -b 80 --managed is used, the bitrate is more variable.  I am quite sure the arguments for -m and -M are in kbps and not bps.

Using something like -b 96 -m 80 --managed might work for your player and still leave the encoder with room to move around.
Vorbis-q0-lowpass99
lame3.93.1-q5-V9-k-nspsytune

aoTuV vs. oggenc 1.0.1 filesize

Reply #9
My question is: what is the goal of the aoTuV encoder? Better quality no matter is that means bigger filesizes?

The target of the tuning for me is a better trade-off (filesize/quality).

aoTuV vs. oggenc 1.0.1 filesize

Reply #10
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?

aoTuV vs. oggenc 1.0.1 filesize

Reply #11
the trade-off between quality and small filesize is something that the user decides by choosing a quality level.

A trade-off is about the bit rate average of many samples, and the balance of each quality.
Quote
What you probably ment is you try to improve the quality per bit ratio, right?

Yes, it is one of the targets.

aoTuV vs. oggenc 1.0.1 filesize

Reply #12
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.

aoTuV vs. oggenc 1.0.1 filesize

Reply #13
Song: One
Artist: U2
Album: Achtung Baby

Switches -q 1 -m 80
aoTuv 4.51
Total Data Length: 2805474
Average Bit Rate (kbps): 81,278822
oggenc 1.0.1
Total Data Length: 2648810
Average Bit Rate (kbps): 76,740029

Switches: q1
aoTuv 4.51
Total Data Length: 2725472
Average Bit Rate (kbps): 78,961043
oggenc 1.0.1
Total Data Length: 2579665
Average Bit Rate (kbps): 74,736794

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 think the documentation is at least misleading:
-m: Specify a minimum bitrate (in kbps). Useful for encoding for a fixed-size channel.
-m n, --min-bitrate=n
              Sets minimum bitrate to n (in kb/s).

It is clear -m does not do that. It just increases the average bitrate about 2% in the case of q1.

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:

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.

aoTuV vs. oggenc 1.0.1 filesize

Reply #14
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.

It is not easy to unite the bit rate strictly for each frame.

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.

Please use managed mode, when the bit rate needs to be forced.
example:
-b80 -m80
-b80 --managed
etc.

Moreover, the bit rate is not managed in quality mode.

Quote
I may be misunderstanding aotuv's gaols, but it seems to me aotuv's q1 is oggenc's q1.5 or something similar.

Bit rate distribution actually differs considerably.

aoTuV vs. oggenc 1.0.1 filesize

Reply #15
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.


This is really not the case. Look at this page for summary of comparison between libvorbis 1.1 and aoTuV:
VorbisEncoders

aoTuV vs. oggenc 1.0.1 filesize

Reply #16
I may be misunderstanding aotuv's gaols, but it seems to me aotuv's q1 is oggenc's q1.5 or something similar.


Also note that you should not compare old libvorbis with aoTuV at, e.g., q1, but you should compare them at the same effective bitrate (as the tests in my previos link shows). Tests show that aoTuV is better. Also effective aoTuV bitrate is more near to the nominal bitrate (e.g. -q1 whith aoTuV is nearest to 80 kb/s than old libvorbis).
In general you should really use aoTuV.

aoTuV vs. oggenc 1.0.1 filesize

Reply #17
Please use managed mode, when the bit rate needs to be forced.
example:
-b80 -m80
-b80 --managed
etc.

Moreover, the bit rate is not managed in quality mode.


That should be stated in the help and man pages.

aoTuV vs. oggenc 1.0.1 filesize

Reply #18
Quote
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:
I'm curious about oggenc 1.0.1 which you stick to.
FYI here is my test result.

[!--sizeo:3--][span style=\"font-size:12pt;line-height:100%\"][!--/sizeo--]aoTuV 4.51 vs oggenc 1.0.1[/size]
encoders
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)

sample
macabre

Result
Code: [Select]
ABC/HR for Java, Version 0.52b, 14 8・2006
Testname:

Tester: haregoo

1L = E:\Desktop\ogg\macabre_aoTuV_q1.wav
2R = E:\Desktop\ogg\macabre_aoTuV_-b80 -m80.wav
3L = E:\Desktop\ogg\macabre oggenc101_q1.5.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: E:\Desktop\ogg\macabre_aoTuV_q1.wav
1L Rating: 3.0
1L Comment:
---------------------------------------
2R File: E:\Desktop\ogg\macabre_aoTuV_-b80 -m80.wav
2R Rating: 3.0
2R Comment:
---------------------------------------
3L File: E:\Desktop\ogg\macabre oggenc101_q1.5.wav
3L Rating: 2.0
3L 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.wav
Playback 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

Please note the following when you evaluate lossy encoding.

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.

P.S.
Use of Bitrate Management is NOT recommended in terms of quality.

aoTuV vs. oggenc 1.0.1 filesize

Reply #19
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 can't hear the difference, then there is no difference. It is a philisphical issue, but I think if nobody is in the woods to hear the tree falling then it does not make noise.

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.

aoTuV vs. oggenc 1.0.1 filesize

Reply #20
Quote
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.

Generally certified encoder works better on most occasion. We see no reason to use old, out-dated encoder anymore. What makes you devote all your interest to vintage encoder?


Quote
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.

Equipments do not matter. I tested with $10 earbuds, thus differences are audible even when you are using portable player.

As fpi pointed out, bitrate of aoTuV is proximate to nominal. You should adjust bitrate for tesing not q value.

aoTuV vs. oggenc 1.0.1 filesize

Reply #21
Some notes:
1) oggenc is only the frontend command-line applications; the 'engine', which defines the quality, is libvorbis.
2) What Ubuntu version are you using? Latest 6.06 uses vorbis-tools 1.1.1 (including oggenc 1.1.1) and libvorbis 1.1.2 (that included changes of aoTuV beta 2). I think you should update to 6.06, which include many new features.
3) Seems that vorbis development at xiph.org has stopped (the author of vorbis, monty, has gone away). This is the reason aoTuV beta 4.51 is not yet merged in official libvorbis (some time ago mounty found that aoTuV beta 3 was clearly superior to official 1.1).
4) If you can't tell the difference between the original and the encoded version, and you want to maximize your quality/filesize ratio, you should use a lower quality value (and a lower bitrate), staying near the limit where you hear distorsion (in your case this is not possible, because you need a min bitrate of 80 kb/s). However you should really use aoTuV 4.51, because most of the people valuating its quality found that has a better quality that all other libvorbis.
5) Next week I'll open a ticket on launchpad.net requesting to merge aoTuV 4.51 patch in libvorbis (already discussed on Debian and Fedora ML).