IPB

Welcome Guest ( Log In | Register )

4 Pages V  « < 2 3 4  
Reply to this topicStart new topic
80 kbps personal listening test (summer 2005), AAC MP3 Ogg Vorbis WMA
guruboolez
post Jul 14 2005, 02:38
Post #76





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (Cygnus X1 @ Jul 14 2005, 02:28 AM)
I ask because it might be interesting to see if there is any improvement when encoding directly in QT, which would let you resample to 32kHz.

Oh yes, it would be interesting... but Apple iTunes doesn't allow 32 KHz resampling at this bitrate (tested on iTunes 4.9, Win32). I must add that it surprised me.
Go to the top of the page
+Quote Post
aspifox
post Jul 14 2005, 10:12
Post #77





Group: Members
Posts: 41
Joined: 8-July 04
Member No.: 15153



Resampling is a different ballgame -- I'd pre-resample the samples with ssrc if resampling is going to be a factor. Oggenc's built-in resampling, for example, is terrible, while on the flip-side I find that a ssrc'd 45kpbs 22khz vorbis file with the lowpass lifted will very usually sound rather better (and have fewer killer artifacts) than a 45kpbs 44.1khz vorbis file (personal, double-blinded, very conspicuous). 80kbps+ might be a different matter, where I don't venture much.

This post has been edited by aspifox: Jul 14 2005, 10:15
Go to the top of the page
+Quote Post
Madman2003
post Jul 14 2005, 10:39
Post #78





Group: Members
Posts: 132
Joined: 18-February 04
Member No.: 12104



Why do you use a creative audigy and not an emu card or an envy24 solution that doesn't resample?
Go to the top of the page
+Quote Post
guruboolez
post Jul 14 2005, 11:40
Post #79





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



I have a Terratec DMX6fire 24/96, and the annoyance of audible clicks and pops is -far- higher than the annoyance of inaudible resampling process wink.gif
Go to the top of the page
+Quote Post
QuantumKnot
post Jul 16 2005, 02:14
Post #80





Group: Developer
Posts: 1245
Joined: 16-December 02
From: Australia
Member No.: 4097



QUOTE (guruboolez @ Jul 12 2005, 11:27 AM)
QUOTE (Mo0zOoH @ Jul 12 2005, 02:10 AM)
Edit: BTW, what else do we need to make the merged 1.1.1+b4 version the recommended one?


Probably additional listening tests, or maybe calling into question the way recommendations are done.
*



I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread, so I put one together very quickly at the time. Now that vorbis quality is starting to take some of the limelight, I think it is time to work out a systematic way of doing this.
Go to the top of the page
+Quote Post
HotshotGG
post Jul 16 2005, 04:26
Post #81





Group: Members
Posts: 1593
Joined: 24-March 02
From: Revere, MA
Member No.: 1607



QUOTE
I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread, so I put one together very quickly at the time. Now that vorbis quality is starting to take some of the limelight, I think it is time to work out a systematic way of doing this.


I honestly think there should also be page for it in the wiki to as well as the thread. The thread has had a significant impact though and applaud you for taking the time to put it together. What's important is that these changes in the encoder should merged into the next official Vorbis branch much like 1.1. That should first and foremost remain recommended encoder. All of the other binares should remain around here though for people who are interested in the latest bleeding edge changes or seeking an alternative wink.gif

This post has been edited by HotshotGG: Jul 16 2005, 04:38


--------------------
College student/IT Assistant
Go to the top of the page
+Quote Post
guruboolez
post Jul 17 2005, 14:29
Post #82





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (QuantumKnot @ Jul 16 2005, 02:14 AM)
QUOTE (guruboolez @ Jul 12 2005, 11:27 AM)
(...) or maybe calling into question the way recommendations are done.
*


I'm open to suggestions. In the beginning, we didn't even have a recommended vorbis encoder thread (...)


I suggest that we (note that I say "we" and not "you") don't recommend any specific encoder. There are many possible reasons to not recommend a specific encoder, but the less acceptable one is the one linked to the lack of listening tests. We have the chance to have people working hours and hours to improve the quality of an encoder (it's not necessary the case), and we can't tell them "bravo, but sorry we don't have any feedback to recommend your work".
If the community can't spent one hour of free time to make a listening test, the community don't have the right to give recommendation based on missing knowledge. It's just a sign of respect and the minimum we can do for the creative and innovative persons working for thousands or even millions people.

The recommendation should therefore be limited to explain the use of the encoder:
why users shouldn't tweak the default profiles
how people could solve some issue (pre-echo with --ITP as example)
explain all known problems with the encoder (specific artifacts)
why VBR and not ABR; tips to avoid playback problems with some flash players
....

There's no need to recommend an encoder, especially older one over newer and not-tested ones (I don't like the expression "non-tested": it supposes that developers are throwing their work to the public without bother to test it themsleves and it also supposes that the lack of report is a sign of lack of tests; I'd rather say: no news = good news wink.gif).
Couldn't we simply precise that:

1.1.1 is the latest CVS version, that quality is essentially based on the work performed by Aoyumi for aoTuVb2, and that this version is obviously not the most advanced version of vorbis?
aoTuV b4 is the latest version, and that this encoder solves x, y and z issues or bug, and consequently should offer the best results?
there are also other encoders, {slightly} outdated now, like GT2/GT3, Megamix, QK, ModestTuning and give of short description of them
?


I know that people like and request explicit answers to their problem: they want THE best encoder and THE transparent setting. As someone starting to have a good experience of multi-codec/multi-format blind listening comparisons, I can say that such encoders and such settings don't and probably won't exist. aoTuV b4, lame 3.97, Nero AAC... could outperform all their competitors, there are still problematic samples for them, some problems audible with the most advanced encoders but not audible with less recommendable encoders.
Go to the top of the page
+Quote Post
HbG
post Jul 17 2005, 16:00
Post #83





Group: Members
Posts: 289
Joined: 12-May 03
From: The Hague
Member No.: 6555



You can still say one encoder is preferable over the other for the majority of uses and the majority of genres. Just like you can say a certain bitrate is transparent to the majority of people on the majority of samples. Everyone with some knowledge will know such recommendations aren't absolute. Everyone else will be happy to follow them and feel assured they're getting the best out of Vorbis. Not recommending one but instead point out how the encoders should be used and the relative differences between them will, even if it is more correct, only be seen as vague.

I beleive keeping things simple for the average user, with one encoder to use, and no more settings than the bitrate, will help spread Vorbis more than the posibility of the recomendations being incorrect will hold it back.

I'm relatively new to this forum and things like ABX'ing, but if someone organises a testing effort for aoTuV b4 i'd be happy to participate. If for nothing else, just because Aoyumi deserves to see some community response to his work.


--------------------
Veni Vidi Vorbis.
Go to the top of the page
+Quote Post
a_aa
post Jul 17 2005, 19:27
Post #84





Group: Members
Posts: 42
Joined: 19-June 05
From: Bergen, Norway
Member No.: 22841



If this is a discussion on principles, it is not an easy one. I have few answers, but a lot of questions...

Is it not a recommandtation to precise that encoder N solves x, y and z issues or bug, and consequently should offer the best result? Is it OK to do this without comparitive testings to back it up? Isn't the fact that there will be more or less problematic samples for any encoder an argument to perform testings on different types of music and compare to other/older encoders - and would this be a sign of disrespect of developers or a sign of conservative thoroughness?

I agree that there is a good idea to have some kind of factbox on each encoder, almost like it has been done for lossless encoders. Unlike lossless encoders, where sound quality is pr def 100% for all the encoders, sound quality would be the key factor to distinguish between good and less good lossy encoders - would it be possible to show sound quality in a factbox? The problem will be how much one should to rely on theoretical improvements vs tested/verified improvements. To much emphasis on the latter can result in few users of an superior encoder (because of the waiting for test results), and to much emphasis on the first can lead to the embracement of an encoder which can't handle real life...

Mercedes-Benz launched their A-series some years ago, and they were very pleased with their development process. They had cut down on expensive real-life-testing, and instead used more computer simulation etc - problems arose when a swedish magazine performed the so-called "moose-test", in wich the car should do a fast manouvre to avoid crashing into a moose on the road. The manouvre resulted in a car up side down huh.gif . Not just once or twice, it was more of a rule than an exception. Basically - (insufficient) theory was beaten by reality...

The choice of this analogy may be an indication of where I'm heading - I don't know yet... wink.gif
Go to the top of the page
+Quote Post
pepoluan
post Jan 19 2006, 18:51
Post #85





Group: Members
Posts: 1455
Joined: 22-November 05
From: Jakarta
Member No.: 25929



This test has been linked to from the HA Wiki page on Listening Tests.

OT: To whoever in charge of the HA Wiki Main Page, is it possible a link to the Listening Tests page be added?


--------------------
Nobody is Perfect.
I am Nobody.

http://pandu.poluan.info
Go to the top of the page
+Quote Post
Jan S.
post Jan 19 2006, 19:51
Post #86





Group: Admin
Posts: 2548
Joined: 26-September 01
From: Denmark
Member No.: 21



QUOTE (pepoluan @ Jan 19 2006, 06:51 PM)
This test has been linked to from the HA Wiki page on Listening Tests.

OT: To whoever in charge of the HA Wiki Main Page, is it possible a link to the Listening Tests page be added?
*

Done.
Go to the top of the page
+Quote Post
pepoluan
post Jan 23 2006, 20:16
Post #87





Group: Members
Posts: 1455
Joined: 22-November 05
From: Jakarta
Member No.: 25929



QUOTE (Jan S. @ Jan 20 2006, 01:51 AM)
QUOTE (pepoluan @ Jan 19 2006, 06:51 PM)
This test has been linked to from the HA Wiki page on Listening Tests.

OT: To whoever in charge of the HA Wiki Main Page, is it possible a link to the Listening Tests page be added?
*

Done.
*

Uh... in the process I think you inadvertently killed the spacing between the "Downloads" section and the "Tests" section...


--------------------
Nobody is Perfect.
I am Nobody.

http://pandu.poluan.info
Go to the top of the page
+Quote Post

4 Pages V  « < 2 3 4
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 19th April 2014 - 14:06