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: .Ogg Vorbis aotuv (Read 486940 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

.Ogg Vorbis aotuv

Reply #126
"Considering the amount of work involved in the Lancer builds, I imagine Blacksword is waiting for libvorbis 1.2.1 to be fully released before doing anything, as am I."

Well if that is the case I guess I'll just have to wait.  You are another one here who does great work -- thank you.

I must say Lancer is the reason why I prefer Vorbis over Nero AAC for my "living room listening notebook" - 35x vs. 13x encoding speed is a good argument.



.Ogg Vorbis aotuv

Reply #129
There is one small bug in the binary:

If the track title contains a ".", e.g. song called "99.9", when using foobar to write filenames using %tracknumber% - %title%, the ogg is written, but the filename is truncated, and the file has no tags.

This occurs on B5.5 and on the latest 20080722 version, but does not occur with the John33 compiles or with Lancer.

I can get around it by using this formatting string in Foobar 2000 converter:

%album artist%\%album%\$num(%tracknumber%,2) - $replace(%title%,.,_)

.Ogg Vorbis aotuv

Reply #130
There is one small bug in the binary:

If the track title contains a ".", e.g. song called "99.9", when using foobar to write filenames using %tracknumber% - %title%, the ogg is written, but the filename is truncated, and the file has no tags.

This occurs on B5.5 and on the latest 20080722 version, but does not occur with the John33 compiles or with Lancer.

I can get around it by using this formatting string in Foobar 2000 converter:

%album artist%\%album%\$num(%tracknumber%,2) - $replace(%title%,.,_)

Thank you for reports. I updated the binary of the test page.

.Ogg Vorbis aotuv

Reply #131
Thank you Aoyumi, it is fixed!

.Ogg Vorbis aotuv

Reply #132
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0).  I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz. 

Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)?  The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx.  Thank you, Aoyumi. 
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon

.Ogg Vorbis aotuv

Reply #133
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0).  I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz. 

Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)?  The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx.  Thank you, Aoyumi. 

Present venc.exe does not have the device to set lowpass.
However, I am going to release it as a new version after release of libvorbis1.2.1 formally.

.Ogg Vorbis aotuv

Reply #134
The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0).  I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz. 

Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)?  The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx.  Thank you, Aoyumi. 

What makes you think that Vorbis at 64 kbit/s with 16 kHz  lowpass will have better quality?  LAME at 128 kbit/s has 16 khz lowpass.
Pretending Vorbis to be 2x better? Insanity.

You´re asking dev for miracles.

.Ogg Vorbis aotuv

Reply #135
Hi:

I don't know if this has been asked previously, but I haven't been able to find anything that clears my doubts.

I'm a bit paranoid about "stability" and the lack of something with a trusty name like "release#" has in contrast to "beta#" doesn't make me feel confident in trusting it my beloved music.

I understand vorbis is a lossy codec and that requiring it to preserve my music intact is stupid and contradictory, but maybe something less pretentious like "Can I trust this not to screw my music up even if it's called beta?" is something more reasonable.
I ask because there must be a reason why 4.51 was renamed release1 but 5 and 5.5 are still beta even if b5 is now HA's recommended encoder (or is it 5.5 now?). Also, although I don't know how much of an authority their are, RareWares doesn't host b5 compiles any longer, only b5.5.

Can someone clear this a bit for me?
Thanks in advance.

.Ogg Vorbis aotuv

Reply #136
Hi:

I don't know if this has been asked previously, but I haven't been able to find anything that clears my doubts.

I'm a bit paranoid about "stability" and the lack of something with a trusty name like "release#" has in contrast to "beta#" doesn't make me feel confident in trusting it my beloved music.

I understand vorbis is a lossy codec and that requiring it to preserve my music intact is stupid and contradictory, but maybe something less pretentious like "Can I trust this not to screw my music up even if it's called beta?" is something more reasonable.
I ask because there must be a reason why 4.51 was renamed release1 but 5 and 5.5 are still beta even if b5 is now HA's recommended encoder (or is it 5.5 now?). Also, although I don't know how much of an authority their are, RareWares doesn't host b5 compiles any longer, only b5.5.

Can someone clear this a bit for me?
Thanks in advance.



Sure, I think the idea (and I can be corrected) of the AOTUV releases is that they are betas because the "libvorbis" releases are the official ones. 

The tests of the AOTUV releases have been posted extensively on this site via ABX tests and it has been given the thumbs up.  It is as good, and possibly slightly better than its nearest competition (LAME, Apple ACC, Nero ACC, MPC, WMA Pro) in the 128-192 range.  As far as I am concerned the majority of the tme I cannot tell the difference between Vorbis q6 (approx 192) and a lossless file.  My suspicion (without a systematic test) is that I would not be able to distinguish OGG q5 from a lossless file in the large majority of  cases.  The bottom line is that it is a top notch compression format.  Any AOTUV release deserves the highest level of consideration until proven otherwise.

- Jason

.Ogg Vorbis aotuv

Reply #137
So, is every "beta" stable, despite the semantical contradiction?



.Ogg Vorbis aotuv

Reply #140


So, is every "beta" stable, despite the semantical contradiction?


Not incredibly important here.


Well, that's not very helpful. I wouldn't ask if it wasn't of importance to me.



Sorry, I am trying to explain to you that it is to your advantage to use these "beta 5.5" versions.  The beta/official release won't be important until the 5.5 changes are added to the official Vorbis release.  Until then Beta is better.

.Ogg Vorbis aotuv

Reply #141
I think you are not understanding my question then.
I know aotuv is better. That's why I use it, as everyone else.

In my sentence "stable" should be understood as "no bugs that cause problems that spoil the result". I know lossy, by definition, "spoils" the original data in a sense. The only alternative then would be lossless.

My doubt comes purely from aoyumi's encoders nomenclature, that (with the exception of r1) are all marked/named as beta. Since beta, in general software terms, can mean unstable, buggy, not sufficiently tested, etc, I don't feel as confident using it as with something named release1, wich suggests it's stable, specially when the other released versions are all called beta, if only by contrast.

I have read about how and why beta4.51 became release1, but I couldn't find any other firm an clear statement about subsequent versions' reliability.

And that's the key point here, at least for me.
I don't have a reason to question aotuv encoders' quality and efficiency. There's enough feedback and praise here and in other places on the net to convince me. But having had a "release1" and then coming back to "beta" makes me think "hey, a new development cycle has started, you should wait for release2 for serious archiving" because, appart from quality and efficiency, I seek reliability; the confidence to encode and archive, and know all went OK.

But, just because it is called beta (after having a release name that suggested stability), I can't keep of my mind the thought that it may choke on something I throw at it and end up with something that sounds bad.

I need that reliability.

Now, I'm not asking Aoyumi to change his nomenclature or anything.
I just want someone who knows what he's talking about to make a clear statement about betaX releases reliability acording to the parameters explained above... If that's possible.
And let me repeat. It's not about how good it sounds.
I too encode most of my music at q5-q6 and don't hear the difference even though I think I have quite a good set of ears (not so good equipment, but anyway...). I know its good, it's just that I have a natural reticence to trust important things to a software labeled beta unless someone authoritative comes out and says "Yeah, you can trust this, it IS safe", or another satisfactory stance about the matter. I don't want surprises.

.Ogg Vorbis aotuv

Reply #142
You should check what's recommended to use. AFAIK they still recommend beta 5 here at Hydrogen. Check Wiki and see for your self. Maybe it's time to update? (unless beta 5 is still the recommended encoder!)

I guess Aoyumi will always keep his "beta" in the name, no matter what. (Just a guess tho). So in this case, you shouldn't worry too much about the encoder being a beta.
//From the barren lands of the Northsmen

.Ogg Vorbis aotuv

Reply #143
I guess Aoyumi will always keep his "beta" in the name, no matter what. (Just a guess tho).

Yes. His posts about [a href='index.php?act=findpost&pid=421624']Beta[/a] and [a href='index.php?act=findpost&pid=447623']Release[/a].

.Ogg Vorbis aotuv

Reply #144

The quality of aoTuV after beta 5 at low bitrates seems quite good (I am referring here specifically to -q0).  I think I may fail to abx some of my audio even at q0, if the lowpass was raised to 16khz. 

Is there a way to specify lowpass with venc.exe (or can such a feature be implemented)?  The quality is becoming too good for me to notice artifacts, so the lowpass is the only thing holding me back from abx.  Thank you, Aoyumi. 

What makes you think that Vorbis at 64 kbit/s with 16 kHz  lowpass will have better quality?  LAME at 128 kbit/s has 16 khz lowpass.
Pretending Vorbis to be 2x better? Insanity.

You´re asking dev for miracles.


Because I can (almost) always ABX a lowpassed sample, even with 'distortion'.  For some reason I can't easily hear 'distortion' and hence even LAME is acceptable to me at low bitrates with less agressive lowpass. 

There is no way Vorbis at 64kbps will beat LAME at 128kbps for most samples, of course.  Point taken.  But my own point is, it's more annoying for me (and more abxable!) to hear agressive lowpass than artifacts.
Copy Restriction, Annulment, & Protection = C.R.A.P. -Supacon


.Ogg Vorbis aotuv

Reply #146
aoTuV beta5.6 Pre Release (source code)
http://www.geocities.jp/aoyoume/aotuv/test

Someone, please compile to oggenc2

I'll attempt a compile later this evening, and I'll post back when it's available.

.Ogg Vorbis aotuv

Reply #147
OK, oggenc2 compiles:

Generic: http://www.rarewares.org/files/ogg/oggenc2...5.6-generic.zip

P3: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P3.zip

P4: http://www.rarewares.org/files/ogg/oggenc2...oTuVb5.6-P4.zip

I'll not post these 'officially' at Rarewares until libvorbis 1.2.1 is officially released.


.Ogg Vorbis aotuv

Reply #149
john33 and Aoyumi: Thank you for your very valuable help and dedication!

Edit: added Aoyumi (I'm so ashamed)