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 Listening Test (Read 77777 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Vorbis Listening Test

Reply #75 –
Oh, my...

Vorbis Listening Test

Reply #76 –
Quote
Oh, my...

I seriously hope you won´t have a nervous breakdown








finally: My 100th post.

Vorbis Listening Test

Reply #77 –
Quote
Oh, my...

Don't worry. It's probably a small mistake, easy-to-fix.
Anyway, there's no evidence that AoTuV+QK should be use. We must test it before, and find the ideal bitrate setting (of course, if you prefer take the responsability of using an untested version of vorbis, you could do it).

In my opinion, AoTuV beta 2 is a wise choice. For two reasons:
- -q4 could be use without problem. 128 kbps seems to be reached an average, for daily use as well for the short samples selected for the next test. The QK modified version is more problematic (opting for a quality setting inferior to -q4/128 would probably be questionned by some people, as weel as big 128 kbps overrun).

- AoTuV beta 2 was tested, and approved by four persons. It's not a strong collective approbation, but it's better than nothing. AoTuV+QK didn't compete. Bugs are always possible. It's the work of two indepedant developers. An hybrid encoder. Epistemologicaly speaking, it's very problematic to use something like that, even if the output quality is possibly better than AoTuV. If we found a bug after the test, the whole seriousness of the listening test might be ruined.

On the other side, both AoTuV beta2 and AoTuV+QK have a very short life expectancy. In few weeks, something like AoTuV beta 3 will be released. Vorbis 1.1 (major update) too... therefore, the conclusions of the next multiformat test about vorbis will quickly be invalidate. Whatever the choice of the codec for the test.

Vorbis Listening Test

Reply #78 –
Gosh, I think I've created a stir.

Firstly, can I say that the aoTuV + QKTune was just an experimental encoder and wasn't meant to be included in the multiformat test.  I guess I should have stated that but I did mention it in my earlier reply to guruboolez' questions about including pre-echo tunings into aoTuV and how it wouldn't be able to make the multiformat test. 

Quoting myself:
Quote
Yes, it should be quite easy to add pre-echo tunings to aoTuV though it is not going to be able to make the multiformat test.


I thought I'd give it a try for those interested but it's still too early to use it.  Also, it only includes changes to values that affect pre-echo.  There have been no point stereo changes.

Secondly, Aoyumi found the bug in my "rectified" source which is causing the problem, I think.  Therefore I suggest that people use the binaries on his test page rather than the ones I made.

Just for clarification, please use the binaries at

http://www.geocities.jp/aoyoume/aotuv/test

Aoyumi included the locale fix I emailed him so this version only uses a '.' (dot, fullstop).  Again, please make sure through testing of his binary (not mine) that the locale fix is not giving any strange bugs

Sorry for the confusion.

Vorbis Listening Test

Reply #79 –
Quote
Furthermore, since it was a thing that it cannot compile well by VC, correction was added and re-uploaded to the source code. someone check whether this moves normally? (I do not have VC)

Just to confirm, the source code from your test page now compiles flawlessly in VC

Vorbis Listening Test

Reply #80 –
I'm very sorry I could not contribute to this listening test because I had been busy recently.  I read aoTuV 20040402 was chosen for the upcoming multi-codecs listening test. I'm in favor of the decision too.  Although I had finished half of the test, I threw it away and began again another test, including oggencaqk -q4.

Here's my listening result:

Vorbis Listening Test

Reply #81 –
Quote
In few weeks, something like AoTuV beta 3 will be released. Vorbis 1.1 (major update) too... therefore, the conclusions of the next multiformat test about vorbis will quickly be invalidate.

Unless it's "Vorbis weeks' and 'Vorbis quick'

Vorbis Listening Test

Reply #82 –

Aoyumi is nevertheless faster, and he updates his encoder more often.

Vorbis Listening Test

Reply #83 –
Quote
Unless it's "Vorbis weeks' and 'Vorbis quick'

"God - give me patience. NOW!" 

Vorbis Listening Test

Reply #85 –
Quote
I'm about to start doing bitrate deviation tests and encoding. As I understand it, I am supposed to be using this binary:
http://www.geocities.jp/aoyoume/aotuv/ogge...x_20040402m.zip

so guys thats important now! we want vorbis to behave at the best possible way, right?

so everyone following this discussion closely get your nuts together, forget all the unnecessary discussions and tell rjamorim if he uses the right binary now!!!



rjamorim,
the version you linked to handles the ./, problem correctly
-q4,25 output 129kbps
-q4 output 123kbps on a small test here
I know, that I know nothing (Socrates)

Vorbis Listening Test

Reply #86 –
Yes.

Vorbis Listening Test

Reply #87 –
Quote

Aoyumi is nevertheless faster, and he updates his encoder more often.

Plus we should leave open the possibility that aoTuV may still sound better than the upcoming Vorbis "1.1".    I've had a quick scan over Aoyumi's modifications and they are quite interesting.

Nyaochi:
Don't worry.  This test did come up very suddenly.  And thanks for the results too.  Another thumbs down for 1.0.1

Roberto:
Yes, that is the binary that uses a . (dot) only.  And since it's a compile by anyone except me, it's gonna work fine.

Vorbis Listening Test

Reply #88 –
Quote
And since it's a compile by anyone except me, it's gonna work fine.

Although I don't use Vorbis myself, I really appreciate what you've done in the past months so please don't say those things!.

What you're doing here is unvaluable and don't forget you're human, cheer up and keep providing us your good Vorbis work.

edit: though I have to admit that was funny  .
XviD

Vorbis Listening Test

Reply #89 –
Quote
Plus we should leave open the possibility that aoTuV may still sound better than the upcoming Vorbis "1.1".    I've had a quick scan over Aoyumi's modifications and they are quite interesting.

I still don't quite understand the argument that the official Xiph vorbis implementation is supposed to be a "reference" encoder and that's why it may not fold in improvements.

Doesn't it hurt Vorbis overall to be fractioned into competing implementations?  So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate?  Doesn't seem optimal to me.

ff123

Vorbis Listening Test

Reply #90 –
hm now that rjamorim postponed the test we can maybe test and prepare a merged version

maybe a merged version, using the best parts from all tunings, would give the best results...
what do you guys think?
I know, that I know nothing (Socrates)

Vorbis Listening Test

Reply #91 –
Quote
Doesn't it hurt Vorbis overall to be fractioned into competing implementations?  So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate?  Doesn't seem optimal to me.

I can see your point.

Vorbis 1.0.2 is in CVS - just needs to be released AFAIK. Vorbis 1.1 will certainly take some time. There is probably enough time for Vorbis 1.0.3 - perhaps someone being in contact with xiph.org could ask if this may be a "community powered" version using some 3rd-party tuning.

This tuning has to meet some requirements:

- It should sound better (of course)
- it should not inflate bitrates

Benefits for xiph.org:

- new version "for free"
- prove Vorbis is open
- pressure for Vorbis 1.1 is lowered

Just my 2 cents...

Vorbis Listening Test

Reply #92 –
Quote
Doesn't it hurt Vorbis overall to be fractioned into competing implementations?  So now there needs to be a "recommended binary" for Vorbis encoders, which might even vary by bitrate?  Doesn't seem optimal to me.

ff123

I guess without competition, there can be no progress.

I already pointed to the possibility of a forking of Vorbis in a previous thread but the point is that the various Vorbis tunings still produce compatible files.  They can be played on any standard Vorbis decoder.  The only things we have changed are constants affecting various things that determine quality (that are there to be modified).  Incompatibility between the various versions is detrimental but we are not seeing that with Vorbis.

The only concern one has is that everyone is free to modify the Vorbis source code however they feel like and are not obliged to release it as open-source.  Hence it is possible for Vorbis-variants or forks to appear which are incompatible with Xiph Vorbis, yet still carry the "built on Vorbis" tag, and perhaps include patented and proprietary modifications.  Very hypothetical at this stage but forking is still a possibility.

Vorbis Listening Test

Reply #93 –
Forking the format or forking the encoder?
I don't think forking the format would be beneficial to anybody.
"To understand me, you'll have to swallow a world." Or maybe your words.

Vorbis Listening Test

Reply #94 –
Quote
hm now that rjamorim postponed the test we can maybe test and prepare a merged version

maybe a merged version, using the best parts from all tunings, would give the best results...
what do you guys think?

I think aoTuV is as good as it gets.  Nyaochi's results on aoTuV+QKTune don't indicate any sizable improvements which dispels the hope that the pre-echo issues that guruboolez raised could be solved by a simple merging.

Vorbis Listening Test

Reply #95 –
About pre-echo: I compared AoTuV against 1.01 CVS on some samples (like mandolin), and AoTuV souned sharper. Can't say if it's really pre-echo improvements, but the noise reduction seems to affect in a positive way the sharpness feeling (at least, on some samples).
Anyway, improvements are really nice. At mid/low bitrate (~96 kbps), vorbis AoTuV is probably the best encoding solution I ever heard (better for my taste than he-aac, at least -again- on some samples).
Nice work

Vorbis Listening Test

Reply #96 –
Excellent.  I'm gonna re-rip my copy of Vivaldi's Four Seasons using aoTuV.

And since I use CDex, I made these DLLs from aoTuV which can be downloaded from:

http://www.rarewares.org/quantumknot/aoTuV-dlls.zip

in case anyone is interested in using it.

Vorbis Listening Test

Reply #97 –
I have build a complete set of aoTuV RPMs for RedHat 9... please let me know if anybody is interested.

Vorbis Listening Test

Reply #98 –
Quote
Forking the format or forking the encoder?
I don't think forking the format would be beneficial to anybody.

Forking the encoder. There would be no benefit from changing the bitstream format IMO (it´s already flexible enough).

Vorbis Listening Test

Reply #99 –
Quote
Excellent. I'm gonna re-rip my copy of Vivaldi's Four Seasons using aoTuV


Sorry, but I am a little confused... 

At the risk of jumping the gun, what 'q' settings should be used for aoTuV vs GT3b2? (like q0-q4 = aoTuv; > q4 = GT3b2)

Also, is a merger between these two encoders being proposed???