Findings and a try at Technical Analysis
I've plotted two graphs for each encoder, one is the cumulative frequencies over the whole piece, the other one shows
a spectral view. When comparing these plots with the original wav files' plots some interesting things about the various encoders and settings
were revealed. I expect you to be able to configure your own favourite encoding software, so you won't find things like ease of use and
plugin-type comfort an issue here.
Here are my findings. Btw: I'm always open for comments and constructive criticism ;)
Fraunhofer mp3enc 160 kBps CBR
The classic. As mentioned before I included this encoder to have a reference to be able to see the improvements of newer developments in audio compression.
Clearly visble from the plots are errors when encoding frequencies above 160 kBps. Basically this only seems to work in the jazz piece (Honing trio - Walking on the moon) - probably because
there's most of the time only one instrument playing. In the spectral views the cut-off at 16 kHz becomes especially visible - only some very loud sounds seem to be able to cut through that barrier.
Besides that long encoding times disqualify this encoder.
I can't recommend using it any more.
Fastenc 160 kBps CBR
MusicMatch has decided upon including FhGs newest development with their Jukebox software, so this one now comes sort of free. After some recent problems with the
encoder in 5.x and early 6.0 and 6.1 versions of the jukebox software, the more recent versions seem to be quite capable.
If one compares the result of the classic encoder with those of the newer fastenc, a change in the psycho-acoustic model becomes visible. It cuts a bit less harsh at
16 kHz but the price seems to be stereo separation in higher frequencies. I've especially noticed that in the classical piece. The effect of cutting the heights seems actually
quite alright with the guitar piece (Sigi Schwab - Kasstensturz). As the guitar is 'tormented', this song almost hurts ones ears so it becomes a bit more 'pleasing' but also a lot less dynamic.
Overall impression is a bit better that the classic mp3enc version, but as encoding times are - in contrary to the new name - still quite slow.
I would not recommend this encoder either.
Fastenc 80% VBR
What I thought strange was that in spite of my manually setting the high frequency cutoff to 20 kHz fastenc still cut off at 16 kHz. This actually was one of the
issues with earlier versions of the fastenc codec, so that seems really strange. It only happened with the classic piece though - the rock version of the toccata has lost a bit too, but not as much. Perhaps the massive orchestral sound
was too much for this little encoder and it kind of ran home to mum - reverting to cutting off everything above 16 kHz ;)
With the other pieces, cut-off was at 20 kHz as configured (for the reasons I mentioned earlier). Another effect is the same
loss of stereo separation in high frequencies, both channels are almoste congruent. Despite these flaws the VBR code does better than CBR, file sizes are acceptable and
encoding time is very fast.
If you're not into classic music, this encoder is an option.
Fastenc 100% VBR
The same codec at 100% quality seems to work a bit better with the classic piece. There's a bit more left of the high frequencies - I think it performs about equal with the lame VBR code in that respect. Toccata's better too.
Stereo separation seems a good bit better as well. As this test is specifically about mobile devices, this aspect is really not _that_ important. If you're listening with the included headphones these things come with you
definitely wouldn't notice any difference I guess. As filesizes don't differ that much it is probably worth taking different quality settings for each muscial genre.
This codec is recommended though there are some issues.
Lame 160 kBps CBR
Looking at the frequency plot of the classical piece this is the best performance so far for a CBR encoded file though there's still left out. Stereo separation is
very good in all test which could well be due to the fact that I manually forced the encoder to use better quality stereo with the '-ms' option.
If for some reason you can't use VBR encoding I would recommend experimenting with lames' many options - I think its CBR code is superior to the
FhG versions. I kind of got the impression that their CBR code has not improved much over time - lame definitely is much more constantly developped which one realizes first and foremost when comparing encoding speed.
lame CBR is definitely recommended, especially for the very fast and high quality encoding.
Lame 256 kBps CBR
At considerable bigger file sizes 256 kBit / sec should better bring about an improvement in sound to be wort the effort. And it does!
With all kinds of musical genres I really couldn't discern original and mp3 copy. The technical tests reveal that almost all detail is captured. Once again the cutoff at 19.5 kHz has been configured and is not a flaw in the encoding.
Even in the plots it's very hard to make out differences. So if you've got the space this is definitely what you'll have to go for. You might even think about not applying the 19.5 kHz lowpass if your hearing is that good .)
Highly recommended, for classical music in peculiar.
Lame r3mix.net VBR
During encoding of the classic piece I noted a strange behaviour. Actually the codec seemed to use 112 kBit / sec and even below most of the time.
This resulted in a very small file - compared to other VBR mp3s of similar quality the lame-encoded version is about 300 kB smaller.
I didn't notice anything like that for the other pieces so I don't really know what to make of it. The other examples look excellent to me, there's not much
difference to the original to be noted in the plots. There's clearly enormous potential here - and as there's continous development going on we'll probably see
more improvement in newer versions. For me this is a fairly good compromise of quality, size and encoding time considerations - just not for classical pieces, as it seems.
But given what they usually are the classic freak will probably not even think about compressing his valued collection - and for the
rest I guess 256 kBit CBR would be the solution. One thing I have to mention: the codebase if changing quite often and is currently in beta stadium. If
you don't want to take a risk there's probably the FhGs VBR as the more stable solution.
Highly recommend for jazz and pop / rock music, not really for classic pieces.
The following table lists my personal likes an dislikes as found with the equipment listed on the overview page.
The Symbols are:
- [--] Encoding errors or heavy distortion and / or audible artefacts
- [ - ] didn't like it, some distortion or generally unpleasing
- [ o ] ok
- [ + ] good but not 'equal' to the original
- [++] I couldn't hear any difference
Encoding Times and Sizes
Depending on the amount of audio data encoding time can be a major issue when choosing the 'ideal' encoder. These times were
acquired on my notebook (Celeron 300, 320 MB RAM), so you will probably get better results. The other major concern is size of the files.
You could probably say that with 6 gig storage on hand you won't have to matter THAT much on filesizes - but a few bytes less could mean
space for one or two more albums to take with ;)