IPB

Welcome Guest ( Log In | Register )

MPC vs VORBIS vs MP3 vs AAC at 180 kbps, 2nd checkup with classical music
guruboolez
post Aug 21 2005, 19:33
Post #1





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



Preliminary notes


Last summer I performed a blind listening comparison between three different audio formats, all set for ~175 kbps encodings. The purpose of the test was to investigate about encoding quality with classical music (and only classical) and to see which format would be the most efficient (i.e. the closest to transparency at lowest bitrate possible) for this kind of music. As jumping-off place for bitrate I took MPC –standard preset which was indisputably recognized as the best encoding solution outputing at 175...190 kbps on average. And indeed, the test ended on musepack superiority. MPC was even superior to Vorbis and MP3 at presets presenting higher bitrate (~195 kbps for LAME, ~185 for Vorbis against ~175 for musepack). Consequently, MPC encodings appeared to sound better and to be smaller at the same time. Amazed by the existent gap between all contenders I conclude my specific test with these words: “I didn’t think that MPC –standard was so in advance”.

My vacation are now quite over. I performed during my free time a big checkup of lossy quality at 80 kbps and 96 kbps (this one has to be translated in english dry.gif ), and it’s too late now to complete the 128 kbps I planned to do in the same silly conditions (150+35 tested samples). But I used my small remaining time to do again the listening test at 175 kbps I did last year, with the same 18 samples and the same hardware.



Why doing again the same test?


As a result of constant evolution of most audio encoders I consider my previous results as really outdated. I recall that Vorbis encodings were done with MEGAMIX I (hybrid encoder melting aoTuV beta 2, Garf Tuned 2 and Quantum Knot tunings). This encoder didn't subsist for a long time... and doesn’t exist anymore; it was replaced by MEGAMIX II, then official 1.1 with Impulse Trigger Profile + Impulse Noisetune switches, which was finally followed by aoTuV beta 3 and beta 4. The same goes for LAME: 3.97 alpha 3 was tested, and during this time LAME developers have submitted eight new versions of this alpha and a few other ones (lame_may, lame_june...)! MPC has also changed: from 1.14 beta to 1.15 alpha which is now considered as safe to use.
As a consequence of this evolution, problems audible last years (kind of ringing for LAME, or noise and coarseness for Vorbis) may be corrected or at least be lowered. The first purpose of my test is therefore to check the outcomes of recent tunings done for high bitrate settings.

There’s also a second point which stimulated me to do again the test and this point is called AAC. I haven’t tested AAC last year for technical and moral reasons. Technically, iTunes encoder couldn’t be set to ~175 kbps; Apple's AAC encoder wasn't also gapless and is for my purpose unsuitable for my conception of artefact-free encodings. I also felt as dishonest the inclusion of Nero AAC: it had recognized issues with classical first and a new encoder supposed to solve these problems was announced as imminent. Some readers suggest me to include faac as competitor, but I felt as unfair to test an encoder which was probably not the state of the art of AAC format and to compare it to the most advanced implementation of other formats (MEGAMIX and LAME 3.97).
I never regret my choice. But this absence of AAC frustrated my curiosity for a long time, because I had strictly no idea about comparative performance of this format with other contenders. That’s why I decided to absolutely include AAC this time. WMAPro will also be tested this time if possible.

The purpose of my test is therefore to obtain a fresh photography of the current performance of all modern lossy formats with classical music using the most advanced implementations for each of them.


I. Choosing the encoders


My purpose being to test most advanced encoders the choice of format hasn't to be controversial for most of them:

MP3: LAME 3.97 alpha 11. Release date: July 2005. Note: --vbr-new encoding mode.
MPC: mppenc 1.15v. Release date: march 2005.
Vorbis: aoTuV beta 4. Release date: June 2005, updated in July 2005 (merged with SVN 1.1.1).
WMAPro: no choice here: it's 9.1 or nothing. Release date: during 2004.

Choosing the good AAC encoder is much harder:
Apple AAC: There's still no VBR mode with iTunes. Consequently it's currently impossible to use Apple's AAC encoder unless other contenders will output an average bitrate close to either 160 kbps or 192 kbps. It's unlikely...
Nero Digital AAC: the most advanced VBR AAC encoder and therefore better placed to represent the AAC format. Big problem: should I use the 'high' and defaulted encoder or rather the 'fast' one which is really better at lower bitrate with classical music? The first one is still recommended by all Nero's developers and it's a valid reason to choose it instead of something they don't consider as stable enough (Garf, JohnV and Ivan Dimokovic). But the situation has maybe changed since their recommendation; I wouldn't also discard too quickly the possibility of using an encoder working better for the difficulties proper to the musical genre I'll test. The debate could be endless if a trivial but objective argument hadn't close the debate: the average bitrate of VBR mode of both encoders (see below).
faac AAC: testing faac might also be interesting. And even for fun, it would give me the possibility to oppose four different open-source implementations of four different formats smile.gif But such friendly comparison has a price: increasing the onerousness of the test which is anything but easy at this bitrate...


II. Targeting a bitrate


The purpose of my test is not to see what encoders could do with xxx kbps for each sample; I don't plan to force each encoding reaching a precise bitrate. My purpose is to stay close to the real usage of a vast majority of listeners (if not all...): using for every encoding one fixed setting which should statistically corresponds on average to the desired bitrate. That's why it's really fundamental to precisely know the average bitrate corresponding to a defined preset. And there's only one way to get it: encoding several tracks or albums.
Last year, I used as reference ~20 classical (+3 non-classical) albums. This year, I decided to be more methodical. I’m now using 150 different tracks (I mean full tracks) coming from 150 different CD in order to increase the variety of encoded tracks. It’s important to note that I didn’t choose randomly those tracks. I meticulously worked to get a representative microcosm of my full classical library, balanced between different grand ensemble (vocal, orchestral, chamber, soloist recording). This collection is nothing more than the 150 full tracks from which I’ve extracted 150 short samples in order to build a “catalogue raisonné” of musical situations occurring with classical music (see this test).

I genuinely expect from this methodically constructed library to be a highly representative panel of my classical collection. My assumption could be verified by checking the average bitrate of the entire collection encoded with WavPack -fx5 (all my >1000 CD digital library is encoded with this preset): 642 kbps for the selection of 150 tracks against 635 kbps for a complete set of more than 15000 tracks. The deviation is inferior to 1%! blink.gif Statistics are really magical.


III. Observing bitrates


I started with MPC which must give the reference bitrate. All other competitors have to be set in order to get a similar value.


MPC: --quality 5 corresponds precisely to 184,54 kbps. This is higher from what I expected first (~175 kbps). The 150 reference tracks are maybe not as representative as supposed. I also tried 1.14 (used last year) with the same preset and --xlevel: 176,28 kbps, much closer to the native average bitrate of --standard profile and reassuring me about the representativity of my collection of tracks. The bitrate has therefore inflated by 4.7% from 1.14 to 1.15v with classical.
=> I'll therefore try to get from all other encoders a setting which outputs to 184,5 kbps ±2% (180,5...188,1 kbps).

MP3: I first tried -V2 --vbr-new, which corresponds to the former --preset fast standard. Average bitrate is 181,79 kbps. Now, this value is lower from what I estimated last year (and that's why I tested -V3 in addition to -V2)... Indeed, 3.97alpha3 -V2 would output to 192,99 kbps. Nice gain (-5.80%). Obviously LAME developpers also worked on efficiency. Gain is great enough that LAME --preset standard could now be fairly compared to MPC --standard. But I recall another time that it only applies for classical (I suppose that bitrate is higher with other musical suffering from sb21 issue).

Vorbis: aoTuV beta 4 -q6,00 leads to 181,48 kbps. This is lower than what I expected, and it's also lower than MPC --standard bitrate. I get 186,99 kbps for the old MEGAMIX I. Bitrate has therefore be lowered with latest aoTuV.
-q6,00 could therefore be directly compared to MPC --standard and LAME --preset fast standard (for classical music).

WMAPro: VBR75 leads to 150,24 kbps. The next available preset is VBR90 and it leads to 203,96 kbps. Both are very far for the range I fixed and consequently WMAPro can't compete in this test.

Nero Digital AAC: Like LAME and WMAPro Nero Digital doesn't offer any precise VBR scale but seven presets. -internet leads to ~142 kbps for both 'high' and 'fast' encoders. -streaming high corresponds to 176,14 kbps and -streaming fast to 193,33 kbps. Consequently none of them is inside the fixed range; the closest one is -streaming high and is therefore the less unacceptable solution (I recall that the 'high' encoder is still the recommended one).

faac AAC: this is the only encoder able to fit into the fixed bitrate range (thanks to the precise VBR scale alla vorbis & mpc). AAC faac –q 175 leads to 180,92 kbps. This –q setting won’t probably correspond to 180 kbps with other musical genre and that’s the occasion to recall another time that the whole test is specific to classical music and nothing else.


Recapitulative table

CODE
         bitrate_2004   bitrate_2005     evolution in kbps   ...in %

MPC          176,28         184,54            +8,26 kbps      +4,69 %
MP3          192,99         181,79           -11,20 kbps      -5,80 %  
Vorbis       186,99         181,48            -5,51 kbps      -2,95 %
AAC faac   not tested       180,92              --              --
AAC Nero   not tested       176,14              --              --


=> faac, LAME, aoTuV are very close each others (difference is inferior to 0,9 kbps!). MPC presents a higher bitrate (+3 kbps) and Nero Digital a lower one (-5 kbps). The gap between the extreme is worrying: approximately 5% corresponding to 8 kbps. That's not a huge difference but these eight missing kbps may lead to a significant difference in quality. I could discard Nero Digital for this test but I would consider this choice as a mistake. For my own curiosity I'm also very impatient to see how would perform an advanced implementation of AAC in comparison to other formats, even if bitrate are not fully comparable.

=> As a consequence I decided to test both Nero Digital AAC and faac AAC, and I will consider Nero Digital presence as a "bonus" interesting to watch rather than an entire competitor. That's why my final diagramme (plots) will graphically separate Nero AAC results from other contenders. I hope this will avoid unecessary debate about any kind of unfairness based on bitrate disparity.



SUMMARY

Are going to be test:

AAC: faac 1.24.1. Release date: end 2004 (?). Setting: -q175
AAC: Nero Digital aacenc32 v.3.2.0.15. Release date: June 2005. Setting: -streaming (high/default encoder).
MP3: LAME 3.97 alpha 11. Release date: July 2005. Setting: -V2 --vbr-new
MPC: mppenc 1.15v. Release date: march 2005. Setting: --quality 5
Vorbis: aoTuV beta 4 based on 1.1.1. Release date: July 2005. Setting: -q6,00



IV. Additional information


I performed all my last listening tests on a Creative Audigy 2 soundcard, which resamples everything to 48000 KHz. Some people consider that internal resampling (transparent in my opinion) is treating unfairly musepack and would biased any listening test. To cut the controversial short, I installed my (better) Terratec DMX6Fire 24/96 which doesn't resample 44100 KHz files (I'm not using it anymore for daily listening because of interference with my VIA chipset).

HARDWARE & SOFTWARE SETTINGS:

soundcard: Terratec DMX6Fire 24/96
headphone: BeyerDynamic DT-531
amp: Onkyo MT-5
software player: Java ABC/HR 0.5 beta 5.
software decoder: foobar2000 0.83 (in order to automatically get files free of offset and to solve my incompatibility issues occuring with Vorbis).

TESTING PRINCIPLES:

ABX phase : To limit the listening fatigue and to end the test before I left my appartment, I restricted the ABX tests to the most transparent encodings (note > 4.00).
Number of trials : eight trials as a minimum. I recall that schnofler's ABC/HR software doesn't reveal to score until the test is closed by the user (and it also can't be resume). Therefore the number of trails hasn't to be fixed: as long as score is hidden the pval isn't ruined. That's why I add more trials when I suspect bad results. I never exceed 16 trials: if something is really transparent I didn't persecute the encoding smile.gif
Notation : My notation was very severe last year, with a full dynamic range of notation (a lot of notes were inferior to 2.0). That's why I decided to add 10 points to each score (in order to disconnect the notation from the usual corresponding scale). This year, I tried to respect the ITU scale. When a difference is audible but not really annoying, the notation is at least equal to 4.0 and my hairs must stand on end to allow a notation inferior to 2.0 (from "annoying" to "very annoying"). Notation is still severe (I keep in mind that all encodings were set at 180 kbps) and that's why results I get here can't absolutely not be compared to other listening tests I done, especially those performed for low bitrate settings. By the way, there are no anchors in this test (high anchor is of course unecessary here).
Samples: Same as last year. See this thread.
Gain: I hadn't modify the gain of any file. All were played at their original volume.

This post has been edited by guruboolez: Aug 31 2005, 11:00
Go to the top of the page
+Quote Post
 
Start new topic
Replies
guruboolez
post Aug 22 2005, 22:02
Post #2





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



QUOTE (user @ Aug 22 2005, 01:02 PM)
Regarding MPC, the result is split, somehow for classical samples there seems to be a degration in quality and size-effectivity (bitrate boost), comparing MPC v1.14b with MPC v1.15v
I cannot dare to ask Guru, to compare this sample set again between 1.14b and 1.15v to get a ranking of this new multiformat test including not only 1.15v but also 1.14.
*

There are two different problems in my opinion:

- bitrate consumption: mpc --standard has increased by more than 10 kbps compared to former release of mppenc (I can post a full bitrate table if you want). 1.15 series is by far the version which presents the highest bitrate (not only with classical: people listening different kind of music have confirmed it - but how much is something I can't say). But this inflation is not necessary a problem: some users don't really care about few additionnal kbps, and it could bring higher quality (higher bitrate doesn't necessary mean lower efficiency).

-quality (with classical): I'm not sure that 1.15 presents regression compared to 1.14 beta. The problem maybe occur earlier. I compared 1.15u to a much older release of mppenc (1.01j) which clearly revealed issues with the latest version of mppenc (+ inflated bitrate). Now I can't tell when exactly the problem happened, or if the quality (with classical) has slowly decreased with version > 1.0 stable.


QUOTE (Aoyumi @ Aug 22 2005, 01:09 PM)
Thank you for a test and a detailed report, guruboolez.
This result is glad also for me. It proves what the direction of my tuning was not mistaken in.  wink.gif
(...)
Magic does not exist there.  rolleyes.gif
*


As usual, congrats to you Aoyumi. I have tested three times your encoder (at 80, 96 and now 180 kbps) and each time I discovered the results with a deep sigh... of astonishment. I probably have to cease my listening tests before people start to suspect me from zealotry tongue.gif Congrats! Your job is near to reconciliate me with high bitrate lossy encodings.

QUOTE (arman68 @ Aug 22 2005, 01:25 PM)
Interesting that lame 3.97 outperforms AAC. There is still life in the old dog  wink.gif  Good to know when planning to use a portable which only supports AAC and MP3.
*

I don't want to defend Nero AAC, but keep in mind that LAME -V2 and Nero Digital -streaming won't probably lead to similar music with most musical genre. I don't have the material to build a precise bitrate table with anything else but classical, but from whay I read in the past it's Nero AAC -normal which produce a similar bitrate to LAME --preset standard. And -normal should sound better than -streaming tested in my comparison. It's very important to remind that -besides the samples- the fairness of presets used in my test is not universal.


QUOTE (Ivan Dimkovic @ Aug 22 2005, 04:18 PM)
(...) as Guru already noted, fast mode was not regarded stable enough, and in the current version - it is still not.
*

I'd like to ask you what does the unstability issue of 'fast' encoder consist. I know two serious issues:
- smearing (it seems that 'high' encoder has better pre-echo handling).
- bloated bitrate on some occasions. I made a graphical comparison which illustrate this point. Bitrate are based on 150 full tracks (> 16 hours of music):



As you can see both curves are parallel for 80% of the samples. But for the 20% remaining one, the -fast encoder start to use more and more bits and encodes the lasts samples with more than 250 kbps (275 kbps for the last one). -high is less hysterical and it stays under 200 kbps (199 for the biggest).

Are there other known issues with -fast encoder?

Anyway, congrats for your work smile.gif I'm pretty impatient to see you working more intensively on the LC core.

QUOTE (Corsair @ Aug 22 2005, 05:16 PM)
What I'm trying to say is that, unlike most other genres, classical samples can be very different and so when you have a thorough test like this one, you can get a pretty good overall picture of each codec (encoder).
*

I'm fully agree with you: 'classical' is a generic term which doesn't really mean anything and which wrongly encompasses most written instrumental/lyrical music composed before the 20th century.
About lossy encoding: I would also believe that any encoder able to handle perfectly all situation encountered with 'classical' would be a champion for every musical genre. But such encoder don't exists and my current listening test is also far to represent all possible situations happening with classical. That's why it would be nice to see tests focusing on other problems than those tested here.
My results can't of course be generalized and extrapolated to other musical genre as well as it would be excessive to believe that results could be totally different with a another set of samples.

This post has been edited by guruboolez: Dec 29 2005, 22:45
Go to the top of the page
+Quote Post
user
post Aug 23 2005, 12:04
Post #3





Group: Members
Posts: 873
Joined: 12-October 01
From: the great wide open
Member No.: 277



QUOTE (guruboolez @ Aug 22 2005, 10:02 PM)
QUOTE (user @ Aug 22 2005, 01:02 PM)
Regarding MPC, the result is split, somehow for classical samples there seems to be a degration in quality and size-effectivity (bitrate boost), comparing MPC v1.14b with MPC v1.15v
I cannot dare to ask Guru, to compare this sample set again between 1.14b and 1.15v to get a ranking of this new multiformat test including not only 1.15v but also 1.14.
*

There are two different problems in my opinion:

- bitrate consumption: mpc --standard has increased by more than 10 kbps compared to former release of mppenc (I can post a full bitrate table if you want). 1.15 series is by far the version which presents the highest bitrate (not only with classical: people listening different kind of music have confirmed it - but how much is something I can't say). But this inflation is not necessary a problem: some users don't really care about few additionnal kbps, and it could bring higher quality (higher bitrate doesn't necessary mean lower efficiency).

-quality (with classical): I'm not sure that 1.15 presents regression compared to 1.14 beta. The problem maybe occur earlier. I compared 1.15u to a much older release of mppenc (1.01j) which clearly revealed issues with the latest version of mppenc (+ inflated bitrate). Now I can't tell when exactly the problem happened, or if the quality (with classical) has slowly decreased with version > 1.0 stable.



yeah, I know it from posts, I used to use MPC 1.01j once, too. And 1.14 for some time, until I switched to 1.15u,v.
The bitrate increase is not only for classic or your impressive 150 samples, but also clearly known, reported here in forum, too, when comparing 1.14 with 1.15r,s,t,u,v. The bitrate increase happens in all genres, classic, jazz, pop, rock, metal probably, too.
I agree, that we don't need to discuss the bitrate as such.
I am using 1.15 myself, as it improved other problem samples. But I was pointing to the facts, just to make it not forgotten..


One remark to the validity of this test and others:

If a (the!) trained person tests samples, the results will be more consistent than you carry out a test with a bigger group which includes "deaf" people, who just lower the p-values, who don't add any significance.
Of course, primarily you have to say, that this test is primarily valid only for this 1 test-person.
But we have some history here, and the reason why Guruboulez tests are very welcomed here, is following: Other persons repeated gurus tests (with or without posting results) and eitehr confirmed them, or admitted, not to hear the difference, but most important: no contradiction.
By experience some people here know, that guruboulez results are valid not only to him, but also to other persons, normally worded "made same experience".
So, if somebody above tries to play "devils advocate", and questions validity of this test, he should not ridicule himself. The only way to question results is in presenting listening test with opposite/different results.


--------------------
www.High-Quality.ch.vu -- High Quality Audio Archiving Tutorials
Go to the top of the page
+Quote Post

Posts in this topic
- guruboolez   MPC vs VORBIS vs MP3 vs AAC at 180 kbps   Aug 21 2005, 19:33
- - guruboolez   V. Results and detailed comments Sample 01:...   Aug 21 2005, 19:34
- - guruboolez   Sample 12: Liebestod Short description: Soprano vo...   Aug 21 2005, 19:35
- - guruboolez   VI. Statistical analysis and conclusions It m...   Aug 21 2005, 19:51
|- - Lyx   QUOTE (guruboolez @ Aug 21 2005, 08:51 PM)Vor...   Aug 21 2005, 23:03
- - JeanLuc   Jesus Christ ... now that's one hell of a list...   Aug 21 2005, 19:53
- - guruboolez   Thanks:) Few words to say that I had to split the...   Aug 21 2005, 19:55
- - SirGrey   Wow ! Great work. Very interesting... Especial...   Aug 21 2005, 20:13
- - skelly831   AMAZING Guru! This is the kind of test that m...   Aug 21 2005, 20:25
- - HbG   You're invaluable to this community! And,...   Aug 21 2005, 20:40
- - rjamorim   Awesome! Thank-you very much, Bin Boolez*...   Aug 21 2005, 21:10
- - bug80   I bow, guruboolez. Great test! Now if only m...   Aug 21 2005, 21:19
|- - Yaztromo   Thanks Guru. It's more than obvious you've...   Aug 21 2005, 21:31
- - ff123   Guru, I'm always amazed to read the professio...   Aug 21 2005, 21:37
- - Cyaneyes   Guru.. you've made me very happy I purchased a...   Aug 21 2005, 21:45
- - Lyx   Amazing. When you think he cannot get any better, ...   Aug 21 2005, 21:58
- - CiTay   Well done, guruboolez!   Aug 21 2005, 22:39
- - Busemann   QUOTE • Apple AAC: There's still no VBR mode w...   Aug 21 2005, 22:48
|- - guruboolez   Thanks to you for all support QUOTE (Busemann ...   Aug 22 2005, 02:45
|- - rjamorim   QUOTE (guruboolez @ Aug 21 2005, 10:45 PM)Is ...   Aug 22 2005, 02:59
|- - guruboolez   QUOTE (rjamorim @ Aug 22 2005, 02:59 AM)QUOTE...   Aug 22 2005, 03:09
|- - rjamorim   QUOTE (guruboolez @ Aug 21 2005, 11:09 PM)I...   Aug 22 2005, 03:42
- - NumLOCK   Great work Guruboolez ! It is normal though -...   Aug 21 2005, 23:19
- - vinnie97   holy eff, excellent test, Guru! *not worthy* ...   Aug 21 2005, 23:28
- - kwanbis   excellent guruboolez   Aug 21 2005, 23:47
- - HotshotGG   QUOTE What is the cause of vorbis' noise issue...   Aug 22 2005, 00:09
- - vlada   Great test, thank you. I'm just wondering, how...   Aug 22 2005, 00:19
- - bond   great test! and great work from aoyumi!   Aug 22 2005, 01:34
- - kl33per   Awesome work guru. I don't recall the test one...   Aug 22 2005, 02:08
- - LoFiYo   Great work Mr Guru. Your occasional listening test...   Aug 22 2005, 02:10
- - PabUK   Excellent test, as always. Thanks.   Aug 22 2005, 11:48
- - Sunhillow   Wow! A great test, Guru!   Aug 22 2005, 12:33
- - user   Chapeau Guruboolez ! Congratulations to the p...   Aug 22 2005, 13:02
- - Aoyumi   Thank you for a test and a detailed report, gurubo...   Aug 22 2005, 13:09
|- - arman68   Very good and comprehensive test. Thank you. It c...   Aug 22 2005, 13:25
- - echo   Once again I am impressed by your professional lis...   Aug 22 2005, 13:22
- - Zurman   Impressive ! And quite surprising (vorbis...   Aug 22 2005, 15:20
- - Ivan Dimkovic   Hi, First of all, thanks Guru for your very hard ...   Aug 22 2005, 16:18
|- - Corsair   QUOTE (Ivan Dimkovic @ Aug 22 2005, 04:18 PM)...   Aug 22 2005, 17:16
- - Mr_Rabid_Teddybear   I'm now really happy I recently purchased this...   Aug 22 2005, 16:33
- - HotshotGG   QUOTE Probably, change of ATH, noise/tone masking,...   Aug 22 2005, 17:37
|- - Aoyumi   QUOTE (HotshotGG @ Aug 23 2005, 01:37 AM)QUOT...   Aug 23 2005, 14:43
- - Ivan Dimkovic   QUOTE (Corsair @ Aug 22 2005, 04:16 PM)QUOTE ...   Aug 22 2005, 17:49
- - Digisurfer   Time to play devils advocate. What is the point of...   Aug 22 2005, 21:26
|- - sh1leshk4   QUOTE (Digisurfer @ Aug 23 2005, 03:26 AM)Wha...   Aug 22 2005, 22:05
|- - Lyx   QUOTE (Digisurfer @ Aug 22 2005, 10:26 PM)The...   Aug 22 2005, 22:06
|- - guruboolez   QUOTE (Digisurfer @ Aug 22 2005, 09:26 PM)Tim...   Aug 22 2005, 22:13
|- - rjamorim   QUOTE (Digisurfer @ Aug 22 2005, 05:26 PM)I c...   Aug 22 2005, 22:14
|- - Digisurfer   QUOTE (rjamorim @ Aug 22 2005, 03:14 PM)QUOTE...   Aug 22 2005, 23:20
|- - guruboolez   QUOTE (Digisurfer @ Aug 22 2005, 11:20 PM)Spe...   Aug 22 2005, 23:52
- - germanjulian   thank you for this great test.   Aug 22 2005, 21:35
- - guruboolez   QUOTE (user @ Aug 22 2005, 01:02 PM)Regarding...   Aug 22 2005, 22:02
|- - user   QUOTE (guruboolez @ Aug 22 2005, 10:02 PM)QUO...   Aug 23 2005, 12:04
|- - rjamorim   QUOTE (user @ Aug 23 2005, 08:04 AM)If a (the...   Aug 23 2005, 14:43
||- - guruboolez   QUOTE (rjamorim @ Aug 23 2005, 02:43 PM)QUOTE...   Aug 23 2005, 14:59
||- - rjamorim   QUOTE (guruboolez @ Aug 23 2005, 10:59 AM)Tru...   Aug 23 2005, 15:52
|- - guruboolez   QUOTE (user @ Aug 23 2005, 12:04 PM)The bitra...   Aug 23 2005, 14:49
- - Axon   While I don't doubt that this is a very signif...   Aug 22 2005, 22:08
|- - ching-3   Great work guru, a very good test. I always beli...   Aug 22 2005, 22:13
- - Lyx   I think the flaw in your logic is that you see thi...   Aug 22 2005, 23:33
- - QuantumKnot   It is always very enjoyable and informative to rea...   Aug 23 2005, 00:27
|- - Mo0zOoH   I feel great urge to thank Guruboolez and Aoyumi f...   Sep 2 2005, 00:58
- - vinnie97   I have to agree with Guru. Either these artifacts...   Aug 23 2005, 01:28
- - boiling_ice2k4   nice listening test guruboolez great to see the ...   Aug 23 2005, 03:19
- - HotshotGG   QUOTE What can I say? I am extremely happy with Og...   Aug 23 2005, 05:25
- - DARcode   Awesome piece of work and information, simply awes...   Aug 30 2005, 15:27
- - guruboolez   Here is the bitrate table (based on 150 full track...   Aug 31 2005, 11:19
- - esa372   Wow! Thank you, guruboolez!   Aug 31 2005, 15:26
- - Pio2001   Thank you for the test. I hope it will encourage o...   Sep 1 2005, 22:34
|- - bug80   QUOTE (Pio2001 @ Sep 1 2005, 11:34 PM)And I t...   Sep 1 2005, 22:50
|- - ff123   QUOTE (bug80 @ Sep 1 2005, 01:50 PM)QUOTE (Pi...   Sep 2 2005, 21:37
- - alter4   And in my opinion, the handling pre-echo mechanism...   Sep 2 2005, 06:14
|- - Yaztromo   QUOTE (alter4 @ Sep 2 2005, 06:14 AM)And in m...   Sep 2 2005, 10:34
- - Aoyumi   QUOTE And in my opinion, the handling pre-echo mec...   Sep 3 2005, 04:22
- - alter4   I tested castanets2 with beta4 Now I have no ABX l...   Sep 5 2005, 08:17
|- - Yaztromo   I will test with beta4 in the next couple of days.   Sep 5 2005, 10:02
- - alter4   the first click in castanets2, no comment!   Sep 8 2005, 09:52
|- - Aoyumi   QUOTE (alter4 @ Sep 8 2005, 05:52 PM)the firs...   Sep 8 2005, 14:04
- - alter4   My friends (I ask theirs to help) say that in cast...   Sep 8 2005, 15:23
- - Aoyumi   >alter4 Can the portion which you ABX(ed) be sh...   Sep 11 2005, 07:45
- - liekloo   I know I'm late. Very late even. But I don...   Sep 15 2005, 22:35
|- - zima   Very impressive...I wish I had sometimes this kind...   Sep 16 2005, 19:35
|- - beto   QUOTE (liekloo @ Sep 15 2005, 06:35 PM)I know...   Sep 16 2005, 21:02
- - Seymour   Guruboolez Great test! Thanks. Surely I'l...   Sep 17 2005, 14:39
- - VEG   Wow! Vorbis bested that MPC on 180kbps?! I...   Sep 22 2005, 21:09
|- - kornchild2002   Thanks for the testing. I can't help but thin...   Sep 22 2005, 22:40
|- - stephanV   QUOTE (kornchild2002 @ Sep 22 2005, 11:40 PM)...   Sep 23 2005, 08:42
- - Donunus   I was just wondering if upping lame 3.97 to preset...   Sep 23 2005, 11:37
- - beto   probably yes. but that's an assumption.   Sep 23 2005, 12:23
- - SCIF   Does anybody with good headphones want to abx-test...   Oct 28 2005, 05:47
|- - de Mon   QUOTE (SCIF @ Oct 27 2005, 08:47 PM)Does anyb...   Oct 28 2005, 08:18
|- - SCIF   QUOTE (de Mon @ Oct 28 2005, 05:18 PM)I bet G...   Nov 2 2005, 06:31
- - kuniklo   I just came across this thread today. Thanks to G...   Oct 31 2005, 22:39
- - lextune   Thanks for this interesting and informative post. ...   Jan 6 2006, 21:37
- - Garf   Re-opening so discussion can continue.   Jan 9 2006, 12:13
- - vinnie97   I saw this thread was locked yesterday with no exp...   Jan 9 2006, 23:38
|- - kode54   QUOTE (vinnie97 @ Jan 9 2006, 02:38 PM)I saw ...   Jan 9 2006, 23:49
- - vinnie97   No need to be testy. I didn't see that *other...   Jan 10 2006, 00:30


Closed 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: 26th December 2014 - 23:05