new Open Source mp3 Encoder from Helix Community Options

[Wombat]

I did a lot of tests concerning HF behavior last night being worried a lot because of Wombat's result.

After all this abxing HF rich 'normal' music I keep up being happy with Helix. Of course this is pure subjective. However I think despite my age I'm not totally insensitive towards HF behavior according to my mp3 listening tests at lower bit rates where lowpassing is a must and where my abx successes have often ben founded on differences in HF. Not a real argument I know.

Anyway there is something specific with Wombat's sample as I have seen in spectrum analysis. HF is cut off way below 18.6 kHz (even without the explicit lowpassing). But I've seen it only with this sample . Spectrum analysis with other samples I've tried was in accordance with explicit lowpassing and did not cut off HF additionally.

I have not tested much with Helix. I threw in some of my sample folders and listened. This sample was easy to catch to me so i reported it.
I have to admit that i tried some more diffcult HF samples and found nothing else.
Just for the record i did another ABX with my dm_s sample and reached 8/8 without a problem.
@level
I will try your suggestion and leave out the forced lowpass.

Other than that Helix is impressive immune against artifacts!
If somehow the "Accurate Lenght" info could be implemented it would be a very complete solution.

[QuantumKnot]

Be cautious when commenting about spectral analysis here. The HF behaviour of Helix seems very similar to that of Xing (though that shouldn't be surprising). That is, the > 16 kHz cutoff only occurs during sharp transients, not all the time like in iTunes AAC or Vorbis.

[Wombat]

Be cautious when commenting about spectral analysis here.   The HF behaviour of Helix seems very similar to that of Xing (though that shouldn't be surprising).  That is, the > 16 kHz cutoff only occurs during sharp transients, not all the time like in iTunes AAC or Vorbis.

dm_s is of that kind. That´s why lame seems to be that better here.

[halb27]

Finally I succeed to hear the problem with dm_s (10/10). Before I was concentrating on the obvious bright sounding parts, but now I realize the problem from the very beginning of the sample where the sound is rather sonore on first 'glance' but does have HF parts.
Once heard I find the problem rather obvious too.
Not to do explicit lowpassing doesn't change things.

Now that we know thanks to QuantumKnot this behavior is triggered by transients I had a look again at trumpet, herding_calls and atem-lied. Spectrum analysis showed the same behavior for trumpet and atem-lied (atem-lied spectrum looks reals strange in the 16 kHz area).
But I could not reliably abx, neither trumpet nor atem-lied.

Well, HF behavior isn't excellent. But if this is the trade for preventing artefacts to a great extent (and it looks like that) I am content.

What impresses me most is VBR behavior. I use -V140 (tribute to my paranoia) and found with difficult samples average bit rate goes up to something like 280 kbps, while easy tracks are encoded with something like 170 kbps average bitrate.
Usually average bit rate is around 225 kbps.

I will use Helix for my forthcoming productive encodings, but will switch back to Lame as soon as the distortion or 'sandpaper' problem is solved.

[halb27]

I just tested the real bad pre-echo sample eig with HELIX (among other encoders).

Helix -V120 -X2 -SBT450 -TX0 -HF2 isn't transparent of course, but to me precision is better than with other mp3 encoders even when using higher bitrate settings (including 3.97b3 -V0, 3.90.3 api).

[halb27]

It has been mentioned that Helix at higher quality settings seems to be rather robust against artefacts. I just was impressed by Helix' performance on eig using level's setting with -V120 and -V150.

This motivated me to investigate the drawback of Helix, HF behavior, in more detail.
I did a lot of encodings from my musical archive, and usually everything was fine to me. But it was not always like that. With Fleedwood Mac's Rhiannon (from the album 'Gretest Hits') I could abx 9/10 missing HF in the 18...21 sec range. I looked at the spectogram and saw that there is something like a soft limit at 16 kHz - not very much is encoded beyond 16 kHz.
I played around a bit and found HF content increases with quality setting - compared to -V120 it's better with -V150 and even better with -B160 (cbr320). But it didn't totally help with the spot I found.
Playing around a lot I finally found that in this case explicitly omitting the range beyond 16 kHz is the best way to go. When I didn't use the -HF2 switch I couldn't reliably abx any more. Looks like -HF2 has an effect on the range below 16 kHz.

I was not fond of giving away everything beyond 16 kHz but I gave it a try. I tested a lot of samples and often thought I found something missing. But abxing showed me I was wrong. After so much work and becoming aware that I'm obviously too old or too deaf to hear anything beyond 16 kHz I was lucky I finally found a spot in Rickie Lee Jones' version of Under the Boardwalk where I got at least a 8/10. But I had a hard time with it.
After all this work I feel I really don't miss something within real live listening situations if I don't get something from sfb21.
Sure this will be different for young people or other people with good HF listening capabilities, but keeping in mind that with the last 128 kbps listening test
Lame -V5 with its 16 kHz lowpass was more or less transparent to many testers so may be being having a 16 kHz limit isn't an issue to other people too.

I also tried Wombat's dm_s sample one more time. I could easily abx the missing HF but looking closer at it I found this is true to me only at the very start. When I started the abx range just a fraction of a second away from the very start I couldn't abx the problem. This doesn't say that everything is fine, and looking at the spectogram it is obvious that not much is encoded beyond 16 kHz (and in this case using -V150 or -B160 doesn't improve things), but at least the pretty audible (to me) issue is limited to the very start where it is not uncommon that encoders behave in a suboptimal way.

Because of the extraordinary robustness against pre-echo and other problems I will use Helix -V120 -X2 -SBT450 -TX0 (apart from wavPack lossy for the best of my music) until the Lame 3.98 branch has come to full maturity.

This post has been edited by halb27: Nov 25 2006, 19:30

[smsmasters]

Where can I find a helix frontend?

Thanks

[halb27]

I use foobar as a universal encoding frontend.
You can configure any CLI encoder to work with foobar.

[halb27]

News about Helix' non-ideal HF behavior resp. HF setting:

When new dBpoweramp came out I found myself very happy with it, bought it, and re-ripped all of the CDs that are of great value to me (also because I don't have all of these valuable tracks as ape-Files).
At the same time I realized I can play AAC on my rockbox armed H140 and gave it a try.

What I found with one of my latest CDs (Sandrine Kiberlain: Manquait plus qu'ça) which is an absolute favorite of mine is that the AAC encodings have a more 'vivid' sound than my Helix -B128 -X2 -SBT450 -TX0 encodings I know very well. I was able to abx the difference (this however was hard while the mere-listening difference seemed obvious to me). I gave -HF2 another try and things became alright (at least with abxing - I still have the impression it's not exactly as 'vivid' as the AAC encodings, but I guess that's placebo).

So I will use -HF2 again.

This post has been edited by halb27: Feb 25 2007, 19:51

[halb27]

The beforementioned CD by Sabrine Kiberlain showed up more problems.
Sibilants aren't reproduced very well, and I found HF spots with percussion in the background where differences to the original are audible, and fiddling around with the settings doesn't really help (and is a bad option anyway).
I should mention that I'm talking about subtle differences but for very high bitrate I don't find it very acceptable. The lacking 'vividness' of my last post did I find by mere listening because I know this CD very well. Same is true for the sibilants.

So Helix is not the good encoder I hoped it is.
In the high bit range area I prefer again good old Lame 3.90 (hopefully soon: 3.98). Things might look different for people who often listen to music that is prone to pre-echo effects, as it looks like Helix really shines in this field.
Helix does have it's merits because it's still true to me that it is robust against artefacts, and that it's VBR method is very well behaved. But Helix works no miracle, it's just a respectable competitor, and maybe the sweet spot using it is something like -V55 ... -V120 depending on personal considerations.

Added:
I should remark that the sibilants on this CD may be problematic to other encoders too. I am about to try Nero CLI AAC for my Rockbox based H140 and I found -q 0.6 may have a very slight problem too. Exactly speaking I was not able to reliably ABX the problem so formally speaking there is no problem. But I can't totally ignore it as within the first 5 trials I could identify the suspected encoding in a rather reliable way. I abxed several sessions and usually it was like this.

This post has been edited by halb27: Mar 3 2007, 13:53

[Remedial Sound]

I just wanted to say that I really like this codec for it's speed! I've taken to using this in foobar to transcode lossless to MP3 for my flash portable (iAudio G3), and on average it takes only 1:00 to 1:15 to transcode a single album, vs. 3:30 to 4:00 with LAME vbr-new (w/ dual-core processor).

I realize that quality may not be up to LAME per listening tests (and general public perception) but it's quite adequate enough for my temporary transcodes (non-golden ears, listening on cheaper headphones).

Has there been any further development on this encoder? I assume not; I'm using the version up at rarewares last updated December 2005.

I currently use -V75 (yields bitrates roughly equivalent to LAME -V4) -X2 -U2 in my command line. Would someone be able to explain in layman's terms what the -TX switches do (and if one is already default), and/or what tweaking the SBT accomplishes? For reference I've put the hmp3.exe -help below - I find it to be a bit cryptic.

CODE

file-file MPEG Layer III audio encode v5.1 2005.08.09
Copyright 1995-2005 RealNetworks, Inc.

Usage: mp3enc <input> <output> [options]
<input> and/or <output> can be "-", which means stdin/stdout.

Example:
mp3enc input.wav output.mp3

Options:
-Nnsbstereo -Sfilter_select -Aalgor_select
-C -X -O
-D -Qquick -Ffreq_limit -Ucpu_select -TXtest1
-SBTshort_block_threshold -EC
-h (detailed help)


B[bitrate]Per channel bitrate in kbits per second.
Encoder will choose if -1. (default)
M[mode] Select encoding mode: mode-0 stereo=0 mode-1 stereo=1 dual=2 mono=3.
V[vbr_scale]
Selects vbr encoding and vbr scale. Valid values are 0-150.
N[nsbstereo]
Applies to mode-1 stereo mode only. Number of subbands to
encode in independent stereo. Valid values are 4, 8, 12, and 16.
The encoder limits choices to valid values. The encoder
will make a default selection if nsbstereo = -1.
Valid values for Layer III are 3-32.
S[filter_select]
Selects input filtering: no filter = 0, DC blocking
filter = 1.
if filter = -1 the encoder will choose (default)
A[algor_select] 0 = track input, 1=MPEG-1, 2=MPEG-2, xxxxx=sample_rate
C c0 clear copyright bit, c1 set copyright bit
O o0=copy, o1=original
X MPEG compatable Xing header, -X2 with/TOC
U u0=generic, u2=Pentium III(SSE)
Q disable_taper, q0 = base, q1 = fast, q-1 = encoder chooses
D Don't display progress
F Limits encoded subbands to specified frequency, f24000
HF high frequency encoding. Allows coding above 16000Hz.
hf1=(mode-1 granules), hf2=(all granules), -B96 or -V80 need
TX tx6, test reserved 6 or 8 seems best (startup_adjustNT1B)
** v5.0 TEST 1 as of 8/15/00
** v5.0 TEST 2 8/18/00
** v5.0 TEST 3 default tx6 (prev = tx8)
** v5.0 TEST 4 mods to short fnc_sf, ms corr. hf enable > 80
** v5.0 TEST 5 fix odd npart, ix clear
** v5.0 TEST 6 add reformatted frames
** v5.0 TEST 7 drop V4 amod
** v5.1 2005.08.09 (see CVS log for details)
SBT[short_block_threshold]
short_block_threshold default = 700
EC Display Encoder Setting

[halb27]

Yes, speed is great, but quality also in many respects, and your choice of -V75 is in Helix' sweet spot range IMO. A very respectable competitor to Lame -V4.
The encoding options are really cryptic. I also tried to learn about the TX option and didn't find anything. According to my understanding of the help contents the default is TX6.
A while ago I did some testing with -V55 and to me the result was slightly better when not changing the defaults than using level's setting (-SBT450 -TX0) which is the only setting with specific experience available.

This post has been edited by halb27: Mar 9 2007, 18:58

[shadowking]

With -v75 I am experiencing severe ringing with nearly all music that has flanged electric guitars. Its damn quick encoder, but how do I make this ringing go and keep filesize sensible ?

[Remedial Sound]

@halb: thanx for the insight
@shadowking: That's interesting. I listen primarily to electronica/hip-hop and so far I haven't encountered any artefacts, though granted these are non-golden ears. Maybe you could post a short sample clip of the source so we can try some different switches?

[poppy10]

Any updates on this?

[Skylined ;)~]

Any updates on this?

I've seen Helix mp3enc v5.1 Open Source encoder patched 2005-12-20 on rarewares

I don't know if this is the latest CVS compile...

Since then i've seen... from http://www.dbpoweramp.com/codec-central-realaudio.htm
For dBpoweramp R12 or newer...

Real Audio Helix Encoder Release 5
Encodes to Real Audio (including Lossless), also included mp3 Helix encoder: a blisteringly fast encoder, 100x encoding speed (2GHz Dual Core), 4x faster than Lame.

But this seems to be the same as the one on Rarewares...

file-file MPEG Layer III audio encode v5.1 2005.08.09
Copyright 1995-2005 RealNetworks, Inc.

Can someone verify this is the latest CVS?

The mp3 encoder *might* be updated in the new realplayer plus beta

This post has been edited by Skylined ;)~: Aug 8 2007, 07:52