Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: New very hard to encode test sample (Read 4182 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

New very hard to encode test sample

Very hard to encode test sample (at least for MP3-encoders) found by nickname "h".
From Regurgitator's "Music Is Sport"

use LPAC lossless coder to decompress it.
lpac -x -n short.pac

This sample is very hard for mp3-encoders, especially for Lame even at 320kbps or with dm-insane. MPC -standard handles it very well, Vorbis rc2 160kbps has some trouble. Psytel -normal handles it also well. Fraunhofer Alternative HQ 256kbps mp3 handles it better than Lame at any bitrate, although there are clear distortions.

The test sample belongs to the same "extreme" group with:
Juha Laaksonheimo

New very hard to encode test sample

Reply #1
You probably used -ms with 320 k mp3?
This mono-esque sound benefits a lot with joint stereo, like with my current favorite:
-b320 --nspsytune -h -t -k -Z -mj --nssafejoint --athtype 2 --scale 0.95
I didn't hear a difference with this one yet, can you?


New very hard to encode test sample

Reply #2
You're right Hans. And your Lame switches does make it quite good.
I didnt do ABX blind tests, but I think there's still more backround hiss (probably pre-echo hiss) with your settings than in the original. It's pretty good though.
Juha Laaksonheimo

New very hard to encode test sample

Reply #3
I haven't tested this sample with those lines yet Hans, but I did do a little bit of testing overall and my conclusions were basically the same as JohnV's.  It does seem that a bit of custom tweaking can help eliminate some of these problems that even LAME has, but I really wish that these type of situations could be detected, and a different technique would be used during coding, instead of having to use a different command line altogether.  Of course, I wouldn't know how to program this myself, but I really think it would be possible to implement this type of thing somehow.  It seems some of the ideas for future improvement of LAME could help with this, but I wonder if a less radical solution could be found in the meantime.

I am glad though that mpc does so well on this sample.  These type of situations just reaffirm the belief I have that mpc is really great overall with regard to consistency in quality, especially for much of the harsh electronic music where you find these killer clips quite frequently.  Mpc's ability to handle these types of clips well over and over is one of the primary reason I use it, especially being a fan of unusual electronic music, and a synth player myself

Any idea if a fix for this type of situation can be implemented easily in vorbis?  Since mpc and aac can seem to handle it, I would imagine vorbis could as well once tuned more.