What are the advantages and disadvantages of using AAC over MP3? Other than hardware support.

Wiki: (AAC) Designed to be the successor of the MP3 format, AAC generally achieves better sound quality than MP3 at many bit rates.

I know Lame MP3 at lower bitrates is hard to compare to when it comes to VBR quality.

AAC is a little newer and codes a lot better for very low bitrates. At higher bit rates (192k) theres not much difference other then hardware support.

I would use AAC if you need 128k or lower and don't mind reduced hardware support. Otherwise MP3 is nice due to universal compatibility.

So the higher bitrates in AAC wouldn't be as good as the higher bitrates in MP3?

it's true that mp3 decoder is lets resource intensive ??
this can save some battery life

No. They are excellent. There is not much difference between MP3 and AAC, both perform equally well. There are many listening test, you might try to examine some of them and see the results.

Depends on the device. Generally everything has a well optimized MP3 decoder since its the standard. Many devices have less well optimized codecs for other formats. However on some devices (ipods) AAC is just as fast decoding as MP3.

According to this Wikipedia entry:

http://en.wikipedia.org/wiki/Advanced_Audio_Coding

The AAC specification was written with mp3's known design-limitations in mind and it has new technologies that solve some problems of mp3. But mp3 is older and encoders like LAME have been fine tuned over the years to a degree where many of these issues were circumvented (at least with high bitrate files). For high bitrate files, the difference is negliable because mp3 is very optimized but AAC, although having better technological conditions, isn't as mature yet. Even when it gets better tuned, you can't get any better then transparent, so AACs strenght lies in lower bitrate regions.
But at low bitrates (<128 kbps) AAC is definitely better then mp3. Mp3's limitations come into effect here since there isn't enough bitrate to encode around them.

At the end of the day it comes down to what bitrate you use for your music. At high bitrates say 160kbps and up MP3 performs just fine compared to AAC and you also gain compatibility. Where at low bitrates 128kbps and lower AAC really pulls ahead of MP3. Oh and compatibility with AAC isn't much of an issue these days anyway, even Microsoft is now supporting AAC. Still there's nothing stopping you from using both.

AAC is a newer generation of lossy audio codec than MP3.
So, it is more advanced in audio coding compared to mp3.
The AAC format has more sample frequencies, and it is much efficient in encoding (from the aspect of filterbank, stationary and transient signals etc....)

Going to sound quality.....
At 64kbps, HE-AAC sounds almost as good as MP3 at vbr -v5
(well, to my ears.... I have a hard time distinguishing them )
while Mp3 at 64kbps doesn't sound good. Even at 48kbps (HE-AAC), the sound quality is still acceptable.
I'm using AAC vbr quality 0.55 (about 200kbps average) on my nokia phone and sony walkman and they sounded really, really good....

I'm not sure about the disadvantages of AAC (maybe a little bit slower encoding speed compared to lame 3.98..)

anyway... you should explore yourself to know how good is aac codec compared to mp3...
try encoding some samples at diffrent bitrate/setting and compare them to mp3...

I can think of some disadvantages of AAC, they mainly focus around compatibility. AAC software and hardware compatibility has increased over the years thanks to the success of iTunes and iPods. However, you still have to be careful which portable player you purchase. The SanDisk Sansa line does not support AAC audio (their top end player does but the rest don't). Even then, AAC support can still be buggy. The Creative Zen was having issues with Nero AAC files for some odd reason. It was fixed when Nero came out with their new AAC encoder. Creative didn't do anything to solve the problem, Nero did. Additionally, many factory installed car CD decks still support only mp3 and WMA files. Some of them support AAC but only through the use of USB media. Another disadvantage is the lack of a unified tagging structure. mp3 has ID3 tag, there are different versions of it (v1.1, 2.2, 2.3, 2.4, etc.) but they are still standards. The AAC community never came up with a standard and there was a time when everyone used their own technology. The growth of the iPod and iTunes has made Apple's tagging setup become the unofficial standard. However, there are still some devices that don't support Apple's AAC tagging structure. The PS3 is one big one. I have to use software (TVersity) that will automatically convert the tags on-the-fly as it copies them over to my console.

I use Nero's AAC encoder as I have an iPod, Xbox 360, PS3, Wii, and an iPod integration kit in my Honda Civic. I can play my AAC files anywhere I want. However, I had to spend $70 for this iPod kit as my factory stereo would playback audio/mp3/WMA CDs only. You just have to be aware that you may come across some device that doesn't work with AAC files or the tagging system that they use. Also, as others have said, most modern day lossy encoders begin sounding alike at high bitrates. AAC may have all these advantages on paper but the Lame mp3 encoder has really pushed the mp3 format beyond what many thought it was capable of. Past listening tests have shown that it can really compete with both the iTunes and Nero AAC encoders even at lower bitrate settings (128kbps VBR).

I went with Nero AAC because it was able to provide transparent results for me at -q0.45 (but I use -q0.50 as it resulted in around a 0.2MB increase per file). I think that Lame does a very good job at -V 3 but I was still able to ABX some songs from that setting meaning that I had to go higher. Even at -V 2, there were still some songs (mainly from Nine Inch Nails and Marilyn Manson) that I could ABX. So, for me, I went with Nero because it could provide completely transparent results at -q0.45. Even with the use of -q0.50, the file sizes were smaller than with -V 2 and Lame (about 1-2MB smaller per file).

In addition to what Kornchild is saying, there are very few standalone DVD players can play AAC files.

I see MP3 support in almost all of them and WMA supported in many of them, but I can't recall seeing any that support AAC files. I'm sure one or two exist, I just don't know of the brand/model.

So, while one can burn a CD-R full of 100 or so MP3 or WMA files and the standalone DVD player will play them, you can't do the same with AAC.

Parity at higher bitrates is not true. Especially the following features have enabled AAC to handle hard to encode content much better than MP3 will ever be able to.

• Higher coding efficiency for stationary signals (AAC uses a blocksize of 1024 samples, allowing more efficient coding than MP3's 576 sample blocks)
• Higher coding accuracy for transient signals (AAC uses a blocksize of 128 samples, allowing more accurate coding than MP3's 192 sample blocks)

Well, actually the first just enables it to be more efficient, but the second can really help with complicated material.

As good as LAME has become over the years, it can't surpass the format's inherent limitations. Many bad experiences with MP3 have been fixed in the AAC specification.

Just compare the number of known killer samples. It is several times higher for MP3 than AAC. Look at how the Nero devs were able to eliminate one killer sample after another. Many LAME killer sample's could not be fixed sufficiently for years. The format just isn't flexible enough.

• Much better handling of audio frequencies above 16 kHz

Most people can't hear frequencies over 16-17 kHz. If you can, AAC will be able to handle this content much more easily.

Add AAC's native VBR support instead of a hacked implementation in the case of MP3, where still many players choke although being 100% spec conforming.

Efficiency only matters at low bitrates. At higher bitrates its irrelevant since theres too many bits anyway.



Yes but theres an order of magnitude more MP3 users, so no surprise that theres more problem samples. If AAC ever becomes popular like MP3, then people will find a lot more samples.



This is false. VBR support is native to MP3 and AAC.

(and broken VBR support is hardly a problem unique to MP3, I had my iPod for ages before it could decode VBR AAC files without randomly skipping ahead)

Advantages:

Better precho handling.
Supports higher freqs.
Supports higher bitrates.
Outperforms Mp3 at any bitrate.
No sfb21 bloat.
Better track seeking.
ISO standard.

Disavantages:

Limited (but growing) support.
Poor decoder support i.e Creative.
Comes in many flavours LC, HE, LD etc.
Patented to the teeth.
Not many well tuned command lined AAC encoders.
iTunes M4A vs MP4 file extention.
Getting gapless playback to work under Linux.

-
I have been using AAC at 200kbps VBR for a while now for my iPod, which offers me better sound and most of time produces smaller files then my old LAME V2 encodes. Most of the time LAME V3 and V2 is transparent to me, but i found too many problems such as drum smearing and i can ABX quite a few songs from Ministry, Metallica and Skinny Puppy. While i only have a few problem tracks with Nero at 0.55.

Higher transient resolution is an accuracy and not an efficiency feature.

1. The biggest lossy music retailer worldwide is Apple.*
2. For years, most AAC killer samples could be fixed. MP3's couldn't. Use the search function.
3. Problem samples usually don't just pop out of the mass but are actively researched at communities like Hydrogenaudio. Actually we have had even more activity regarding AAC samples in the last years. Still the number of unfixed MP3 samples is higher.

So as much as you utterly want MP3 to be better in this regard, it just isn't. The MP3 spec was finalized in a kind of rush. A lot of stuff has been fixed or done better in its successor.



Read the spec before making false claims. VBR support has never been officially included for MP3. A MPEG compliant hardware decoder does not have to support it. It is a feature later added by codec developers, not by its standardization committee. MP3 has originally been designed around constant bitrates.



I don't know what crappy encoder you have used. I have never had a problem like this. AAC has a variable bitrate design from the ground up. CBR and ABR are actually constraints to its basic operation.** In the case of MP3 it's the opposite, VBR is an arbitrary pseudo standard extension to the original spec. If a player manufacturer wants to support MP3 VBR encodes there is enough information out there to implement it, but he won't find it in the official specification.


* As of January 2009, the store has sold 6 billion songs, accounting for more than 70% of worldwide online digital music sales.
** Probably because codec developers had the most experience with CBR codecs like MP3, early AAC encoders were also mainly ABR/CBR implementations.

Licensing for AAC is AFAIK pretty straight. It's all handled by a single institution and fees are capped. Isn't that even more complicated and costly for MP3?



Well, we have Nero on Windows, Linux, and Mac (through Wine). Its quality is beyond doubt. On the Mac there is additionally afconvert on the command line and a nice CoreAudio API. Its quality is also excellent. Quality-wise I'm not missing anything. OK, a open source product in the same quality league would be nice.

It's just if you want to use EAC or foobar2000, your stuck with only FAAC or Nero AAC, which is good encoder btw. Also a new open source AAC encoder to replace FAAC would be awesome, am getting sick of being stuck with FAAC when i rip DVDs with Handbrake.

Relevance?



MP3 has been used by far more HA members and for far longer. The well known MP3 problem samples date back the better part of a decade. HA members prefer it by a factor of several:

http://www.hydrogenaudio.org/forums/index....showtopic=68338

Integrate the area under the MP3 and AAC curves:

http://img206.imageshack.us/img206/3774/ha1fg1.png

And tell me which you think has had more careful listening for longer. You're so focused on the numerator that you're forgetting the importance of the dominator when calculating a ratio and have come to an unsupportable conclusion. Retract it.



Been posting here about using AAC since before you were an HA member, noob.



I do not believe this is correct. Quote this from the specification to me.



Ahead Nero. The problem is well documented in these forums. And since I'm not so lazy to tell you to search, I'll even provide a link:

http://www.hydrogenaudio.org/forums/index....showtopic=17773



I've never had a VBR MP3 problem.

I thought you may have underestimated the number of circulating AAC tracks on this planet.



Well, a decade time to fix them. The Ahead devs, and I don't think LAME devs are less capable, are usually able to fix such issues in less than a year. Do you still want to neglect this to be an indication that MP3 has just more inherent (and actually relevant) limitations? The same decade that you cite with respect and its problem samples didn't just help MP3 to mature, but have also influenced the AAC spec.

AAC is not a competing format, but MP3's official successor and was partly developed by the same scientists and institutions as MP3. Much of the experience made with MP3 went right into AAC. So its not maturity vs. the new kid on the block. I'm pretty confident that there will never be as many outstanding problems with AAC as there are with MP3, especially regarding pre-echo and high frequencies. The latter has always been kind of a mess for MP3. The official bitstreams for decoder compliance tests even exclude the matter completely.



I can't. The spec only defines the bitrates 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, 192, 224, 256 and 320 kbit/s. No mention of VBR.

Very well. Then what is the relevance of me underestimating the number of circulating AAC tracks on this planet? I fail to see the connection to your argument.



I do. It is a vague and unsubstantiated generalization of an opinion you hold. It indicates nothing beyond the fact that you disagree with me, a fact I am already aware of.



For what its worth, this is wrong. AAC-LC had already been more or less finalized by then, which is what you seem to be referring to above.



Since this doesn't appear to refute or even address the numerical counter-evidence I have provided to show that you are wrong, I will take this as a tactless retraction of your above argument that somehow ratios can be evaluated independently and without knowing their denominators and move on. If you think some part of what I have quoted is an argument in and of itself, feel free to pursue it further.



So much for "Read the spec before making false claims". I suppose "trust me because I'm pretty sure I'm right and can't be bothered to check" just didn't sound as clever.

Well, I guess you didn't get that I can't because it's not in there. ISO/IEC 11172-3:1993 does not mention VBR. Only the bitrates, that I have cited.

What you claim is wrong and I can't cite what's not there. Ask some LAME devs if you don't believe it.

Looking at the compliance vectors, some are VBR, so unless I am completely mistaken, you appear to be wrong. Feel free to double check:

he_44khz.bit all bitrates at 44,1 kHz (padding included)
[...]

Frame Action
---------------------------------------------------------------------------

1-10 bitrate = 32 kbit

11-20 bitrate = 40 kbit

21-30 bitrate = 48 kbit

[...]

A simple google search reveals dozens of links confirming what the specification says.

Taken from ISO 11172 with a modified date in 1994.



Amazing.

By numerical counter-evidence you mean the hydrogenaudio user polls, that are supposed to support your argument that 6 years of additional development basically don't have improved AAC over MP3?? I regret trying to convince you in the first place. So please bear with me if I don't follow every thread of your argument. Even if some of them may be consistent in themselves, I can't take the basic claim that they shall support serious.

AAC was a considerable improvement over MP3. Ask LAME developers about their headaches with high frequency encoding (sfb21 anybody) and AAC developers why they didn't share them. Look at why so many pre echo problems couldn't be eliminated for MP3, but could for AAC. The AAC spec was improved significantly over MP3. That's the data from my point of view and I consider the rest is rhetoric to defend a questionable thesis.

The ISO example you cite, shows perfectly why spec compliant MP3 is basically fixed bitrate oriented in a crude way. You can only switch betwen bitrates 32, 40, 48, 56, 64, 80, 96, 112, 128, 144, 160, 192, 224, 256 and 320 kbit/s back and forth, but can't just exactly allocate as much bytes to a frame as you need. That's not VBR but VFBR, variable fixed bitrates.

If you want to see it done right, look at AAC. For every frame there can be allocated as many bytes as needed. No need to switch between a set of fixed rates. There's also generally less interdependency between frames, which makes it a lot easier for true VBR.

Finally, what's an MPEG spec compliant VBR header for a mp3 file? Why is there a Xing, LAME, and FhG flavor when it is part of the spec as you claim?

That's also not true, btw... Before I had become a member at HA you never had even mentioned AAC. The first time you commented on it was five days later. And doesn't that look that familiar? Even back then you were already trying to convince people to just stick with MP3 (instead of answering the original question wether there were portable players that supported AAC):



So we could have had exactly the same discussion already six years ago. Back then I was already highly impressed with Dolby's AAC encoder implemenation in MusicMatch Jukebox, but I hated the program's shiny plastic interface and there was no alternative, so I rarely used it until Nero became available.

You've edited my sentence to say something other then it originally did. Please don't do that. The original was perfectly clear before you removed its meaning.







I'm curious, when you do this thing where you pretend you haven't been wrong and insulting the entire time, is it because it would hurt your ego to admit a mistake, or because you're just too big a jerk to care about being civil?



haha



MP3 too.



Nonsense. AAC frames still have overlap because of the IMDCT.



You're really creepy.

"In order to provide the smallest possible delay and complexity, the decoder is not required to support a continuously variable bitrate when in LayerI or II. Layer III supports variable bitrate by switching the bit_rate_index."
quote from ISO/IEC 11172-3.

Ok, I obviously went too far, when I said it isn't mentioned. On the bitstream level each frame can have one of the 15 pre defined bitrates instead of an almost arbitrary frame size (between smallest and biggest allowed frame size) in AAC.

I initially claimed that players choke - the stream decoder is only one part of this. There is still no official spec for VBR file handling.* This manifests in the inability to both display a file's total playback time and provide skipping capability. The only possibility would be a full file scan before each playback. And tell me just one player that would do the latter, it's just far too ressource intensive for real world implementations.

In reality the lack of an official spec nowadays still results in players, that don't only fail to display a file's total playback time and provide skipping abilities, but choke completely when fed with VBR files. It breaks their implementation's assumptions (while their internal stream decoder might well be able to output a signal). Several onboard MP3 players in Audi's current lineup fall into that category. And since there is no official spec that would have been broken, you can't return the units for not delivering what had been promised. AFAIK the latter is no problem in AAC's (or the mp4 container format's) specification because there is an official definition instead of three different software developer created pseudo standards as in the case of MP3.

* And having to chose one of 15 predefined bitrates for each frame isn't optimal, either. That's why I called MP3 basically a CBR based design, where VBR operation is an extension (at least on a file level) and AAC a basically VBR based design where CBR and ABR operation are optional constraints.

Those 15 framesizes are just for segmentation. The audio (or main) data belonging to that frame's side info can be spread over multiple frames or take up less than 1 frame. It allows for any byte size main data, just like in AAC, the segmentation is just much more complicated.

Besides the technical details, sorry for being such a dick head this time, Mike Giacomelli.

Accepted, but I still take issue with much of what you've said:



Of course decoders can have bugs. No one disagreed. Hell I even linked you to an AAC decoder with an equivalent bug. This is so obvious it goes without saying.



What you actually meant to say is that theres no official container that provides seeking information for MP3, and that is closer to the truth. ISO/IEC 11172-3 only defines a bitstream, not the container. AAC works the same way, with ISO/IEC 13818-7 only defining the bitstream and not the container as well. There is actually an MPEG container for MP3 that provides everything you mention, I believe its defined in ISO/IEC 14496-1 and called MP4 (though its not used much in practice) as well as a number of containers that officially do support it and are used in practice (RA and ASF for instance).

The problem you're getting at is that people have decided in practice to use raw MP3 bitstreams, which is why seeking is tricky, particularly for old decoders.



No. Any decoder that does not decode VBR fails the compliance tests and is therefore officially broken. The spec is clear on this point. You can take it back and complain but they're not going to care. People walk all over the MPEG specs everyday.



I've actually done a lot of work on audio decoders, so I can confidently say you have no idea what you're talking about here. Bugs creep into decoders all the time because they're complicated not because people are somehow unable to find documentation about how they work (well aside from the MS formats). MPEG ones especially encounter problems due to complexity. If your decoder doesn't handle a codec feature its required to, its a bug. This happens to MP3 decoders (though I've never seen it in practice since MP3 is so old and they're essentially all debugged by now) and to AAC decoders (my old iPod).



And you were wrong. Seriously, read the spec, or at least the HA wiki entry on the bit res in MP3. You need to understand how frames work before trying to explain them to us.

In case anyone is interested in some published "official" listening tests results on MP3 vs. AAC, I suggest reading this:

G. Soulodre, et. al, "Subjective Evaluation of State-of-the-Art 2-Channel Audio Codecs," 104th AES Convention, May 1998.

If you want to skip the text, take a look at Figure 3 on page 19.

Some background knowledge:

By the time of this test, the tested AAC encoder was about 2 years old. The MP3 encoder was almost 10 years old.
The bass clarinet, harpsichord, and pitch pipe items in this test reveal a weakness of MP3. Most likely, these items will not be transparent for MP3 at any bitrate up to and including 320 kbps. And most likely, they will be transparent for AAC at 320 kbps or even less. If anyone is interested, I can do a blind test of these three items (since I have access to them) at 320 kbps AAC vs. MP3.

Chris

Thats so old its basically irrelevant. None of the modern MP3 or AAC codecs even existed when it was written.

If you still have access to the lossless version, it would be great if you could share some <30sec samples. If your upload contingent is already full, I have some spare space available.

What exactly is so irrelevant about it? The test compares Fraunhofer's new (at that time) AAC encoder against Fraunhofer's 10-year tuned reference MP3 encoder. Are you trying to say that the encoders used in that 1998 test basically "sucked" with regard to today's encoders? I think I clearly wrote that the test items for which MP3 did bad in this test are items which reveal a weakness of the MP3 codec structure (actually, they are also quite hard to encode transparently with AAC). That's still the case with today's codecs. I hope that, time permitting, I can support this with a blind test soon.


The bass clarinet and harpsichord items belong to the SQAM CD, which you can download here. Unfortunately, the pitch pipe is a copyrighted recording by Dolby, so I can't share it.

Chris

Here's another test from that time. This has more music items in it, so MP3 does much better.

D. Meares, et. al, "Report on the MPEG-2 AAC Stereo Verification Tests," ISO, February 1998.

Chris

Here is a ready-made set of above samples for LAME 3.98.2 MP3 and Quicktime 7.6 AAC at bitrates 128, 192, 320 (CBR) and V2, Q127 (VBR). V2 and Q127 both have an average target bitrate of ~192 kbit/s. The WAVs are also included. All other settings were left at their defaults.

28 files inside the archive, 10,2 MB: "rapidshare.com/files/238901987/ABX.zip" (prefix "http://", the board disallowed Rapidshare link provision).

Maybe somebody wants to add Nero encodes.

I'll try a round of ABX later this day.

Samples encoded by Nero AAC 1.3.3.0 at q 0.50, q 0.55, 128 + 192 + 320 CBR and 2 pass ABR.

Nero AAC encodes

Important: do not ABX an encoded file vs. the original WAVE. Decode to WAVE and remove the codec delay at the beginning of the file. The waveforms need to be perfectly time-aligned, otherwise even transparent items may be ABX-able simply because when making loops, the start and end points of the waveforms will be slightly different.

For SQAM 17a and 40a, I uploaded decoded and delay-compensated LAME CBR encodes at 128 and 256 kbps in WAVE format here (ad-free). For SQAM 17, I removed 0.5 seconds of excess silence at the beginning of the file. Rpp3po, if possible, please upload this on your space. My download is only valid for two days.

For SQAM 40a, I could ABX LAME CBR at 256 kbps. I failed for 17a with LAME CBR 256 kbps (that already sounded relatively good at 128 kbps, actually). I will post my results for LAME 320 kbps here later.



Update: The 320 kbps LAME CBR decoded and delay-compensated WAVE files for the two above SQAM items are available here. Again I was able to ABX SQAM 40 at LAME 320 kbps. It is still not as "crispy" as the original.



Chris

Foobar is able interpret gapless information from lossy files. Doesn't its ABX component do the time synching implicitly, when it converts the lossy files to WAV prior to a round of testing?

Yes. If someone manually tweaks foobar's decodes afterwards he will only break time sync.

Maybe for MP3, but not for the QuickTime MP4 files in your upload. When I ABXed that at 256 kbps, I could hear a difference due to delay. But again, this might not be the case for nero MP4 files (nero decodes seem to be delayless). But to avoid the possibility of delay in the first place, one should decode to the same format as the reference file and do "manual" delay compensation.

Chris

Ok, sounds sensible to use pre-converted wavs, then. Have you removed the delays by hand or do you know a tool to do this automatically?

rpp3po, I did this by hand. Don't know of any publicly available tool. Opened the LAME MP3s in Audition, removed the first x samples (where x = 2257 for LAME and 1088 for your QuickTime files), saved as 16-bit WAVE file. To open MP4 files in Audition, I used the FAAC/FAAD plug-in.

Chris

So, here are my results for SQAM 40 with nero 192 kbps CBR. As you can see, I got the first three right, but it went downhill from there, so ultimately, I failed. To eliminate fatigue as the reason (it's midnight in Germany), I'll do this again with fresh ears tomorrow. Anyway, nero 192 kbps to my ears sound at least as good as LAME (or MP3 in general) at 320 kbps.



Chris

Here are my first preliminary results. For now I have skipped sample 17a, because I could not identify any characteristic artifacts in the first run. I continued with sample 40a:

LAME CBR 128:



Notes: Laughably easy! Background totally wobbly, like a chorus effect or early internet radio. If I hadn't known it's 128kbit/s straight from a WAV I would have put money on that it is a transcoding.

LAME V2:



Notes: Already harder. Focused onto range 0:00.4-0:01.6. Original is identifiable as having a more defined 'punch' at the first low note.

LAME CBR 320:



Notes: Terribly hard, but beatable. Again focused onto 0:00.4-0:01.6. First try already false. One sample seems to have time smearing in its highs compared against the other. Several mistakes, pauses needed due to fatigue. Focussing your ear strictly at the first punch, without letting it get 'carried away' by the sound that instantly follows, reveals ringing highs.


I really like the samples. These are excellent recordings. Thanks for the reference!

40a is a natural instrument, not a synthetic test sample and I'm not impressed with LAME's performance! The VBR algorithm also does not get the gravity of the situation and fails to scale up higher than 196 kbit/s average.

Let's see how the AAC contenders compare to that. CBR 320 was quite tiring. I may try it later tonight or tomorrow.



Here you go: rapidshare.com/files/239055214/sqam_17_40_lame_cbr_128_256.zip

Not to be a pedantic prick, as I not questioning what is claimed to be heard, but whatever happened to the idea of doing a fixed number of trials? This pattern of constantly varying the number of ABX trials caries the taint of shopping for answers, be it justified or not.

The results do not reflect tests of anything relevant.



I'm saying they're not today's encoders.



What you wrote clearly was your hypothesis, which you then proposed to test. Thats very good. But you've already explained that those results don't support or even test your hypothesis, so why did you recommend I read them exactly?

I don't agree. Sometimes, as in the first two cases, the difference is so laughably easy, that it would be a boring waste of time to continue testing far below the 1% probability of guessing threshold. I'm doing this in my free time. So I wouldn't want a minimum number of trials above 8. It's also a question of stamina, you want to save this for higher bitrates.

But you can't take 8 as a fixed number, because that's not suited for harder samples at the edge of audibility. For that you need more. In my opinion as long as a subject delivers <1% results and you get to see the whole track record, that's fine. It will show wether someone just oscillated around 50/50 and somewhen hit stop after 50 tries or if there was a significant trend. In my 3rd run I don't see any indication that this looks like the results of random oscillation.

According to what you've stated, you're watching the results as they come in, which is also invalid procedure.


I wasn't calling anyone out by name - for you are not the only one, rpp3po, who has been doing this as of late.