After 4 Years, HydrogenAudio Opens New 128kbps Listening Test
kwanbis writes "After more than four years, a new MP3@128kbps listening test is finally open at HydrogenAudio.org! The featured encoders are: LAME 3.97, LAME 3.98.2, iTunes 8.0.1.11, Fraunhofer IIS mp3surround CL v1.5, and Helix v5.1 2005.08.09. The low anchor is l3enc 0.99a. The purpose of this test is to find out which popular MP3 VBR encoder outputs the best quality on bitrates around 128 kbps. All encoders experienced major or minor updates that should improve audio quality or encoding speed, and we have a totally new encoder on board. Note that you do not have to test all samples — it is a great help even if you test one or two. The test is scheduled to end on November 22nd, 2008."
good headphones are a must for such close listening tests. you'll only be able to hear really major differences with most speakers.
Wow, what a mess. Download this package. Now download fourteen more packages (DownThemAll is the only reason I didn't give up right then). Y'know, I'm kinda interested in this subject, as I have no trouble hearing artifacts in most 128kbps CBR MP3s, but this is just a huge pain in the ass. Wouldn't a simple Flash app have made things so much easier?
You know what, I thought I'd be nice and give this a shot, but the amount of effort involved just isn't worth it. If it isn't 'click on this link, listen, rate', it's too much work. Download x, install x, email x - way, way, way too much work for what is being given in return.
Umm... 128 Kbps? Seriously? And no Ogg Vorbis, AAC etc... If you're bothering to set up a listening test, why limit yourself to 128 Kbps MP3?
Also, this should really be set up as a blind test, you get to listen to two clips, and have to choose which is better. The clips are randomized, of course... I could go on, but I'd just make myself sound even more arrogant. ;)
.: Max Romantschuk
The ABC/HR zip, and one sample zip. Each sample zip is a separate test that can be run completely separately from the others. Testing each sample may take quite some time (it took 1-2 hours for a single sample last night for me) - so splitting this up actually does make a bit of sense. That said, even on Windows this test has been plagued with problems. I've had to downgrade to Java 1.5 to avoid a crash.
That's great if you're trying to use a codec for a purpose it was never designed for and nobody actually uses. Would you choose a JPEG codec based on its ability to encode/decode raw audio? Would you choose a car based on its ability to traverse the English Channel?
Spectral music might make for great samples for this kind of testing, but your assertion is ultimately unsubstantiated unless you can provide real listening test results that show it makes for a more sensitive test. There are all kinds of subtle things going on that might seem to make for great encoder testing, but largely turn out to make an imperceptible difference. Just because so many overtones exist (99% of which do not exist in msot acoustic music, btw!) doesn't mean they are necessarily audible if they are perturbed. More specifically, I'd anticipate that most FFT-based imaging techniques would hammer encoder lowpasses very hard, but would not be nearly as hard on preecho performance or stereo imaging artifacts. In a lot of situations, the preecho is a lot more important than the lowpass.
It was 10 years ago when I bought a Rio PMP-300, the first readily available flash-based MP3 player. It came with 32MB of internal memory, and would accept a single SmartMedia card, 32MB max in size (which I quickly went out and bought).
Back then, the size of your MP3 files mattered a whole lot more. At 128K CBR, I could fit 6 to 9 songs on each bank, depending on how long they were. The artifacts were noticeable to even my poor hearing. So I then stepped up to 160kb CBR and then LAME -remix (VBR, average ~ 190K ) encoding setting. I will make a note here that not all MP3 encoders are created equal - there is no fixed encoding standard, just for decoding.
With the VBR files, I could only fit 3-6 songs per bank of the Rio, so yea, it mattered then. If I wanted a specific CD to take to the gym with me, I had to think about what I put on the Rio. Often I couldn't fit the whole CD on the device or I had to swap play order to better use the slack space in each memory partition.
Can you even buy a MP3 player with less than 1GB of internal flash memory today? Skip past something like the iPod shuffle or equivalent at 1 and 2 GB, and you are quickly looking at 4GB, 8GB, 16GB or more.
I just encoded my copy of Linkin park's Minutes to Midnight CD that I bought with LAME 3.97 high quality VBR and it came out to 77.6 MB for the whole thing with the average bit rates in the 230kb/s to 270kbs. It wouldn't fit on the RIO at this quality. On the cheapest iPod Shuffle, I could fit 13 similarly sized CDs at this quality encoding. On the cheapest iPod Nano, around 100 similarly sized and encoded CDs.
My point??
128Kbs is sooo 1990s.. We've moved on. Storage, be it flash or Hard drives, has gotten order(s) of magnitude cheaper and bigger. So why aren't we moving our mindset about default MP3 quality UP to reflect the change? Make very High quality VBR the default and raise the average quality bar.
You said that if you look at a spectrum as an image you can spot degradation in a lossy encoder. That's entirely irrelevant, since mp3 is a perceptual encoder; it deliberately loses information that, according to its predictive model, listeners cannot actually hear. To show that it fails to do this, you need to conduct a blind listening test with the encoded and un-encoded version, and actually reliably (i.e. significantly more than 50% of the time) pick out the encoded one.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10