I am glad to hear this. I have forwarded the information and your thanks to my colleague.


Hmm, I must have missed the stdin input fix when I updated the Helix code a few months back, with what I thought were all the contributions from people on this thread. John33 applied the joint stereo patch to the rarewares source and built this separately. Therefore stdin works there. When I get back over the holidays I will patch the Helix source with the stdin fix. Thanks for noticing this.

I'd like to thank Karl as well. It's great that problems are getting fixed so promptly.

What's the difference between the -hf and -hf2 switches? Also, has anyone noticed them to give some sort of improvements in quality (by increasing low pass cutoff beyond 16 kHz on impulse-like parts)?

level posted earlier (post #170) that the encoder performed very well, in his opinion, with his command line. I wonder why no one has performed any ABX tests (and presented them)? I, for one, can't even ABX LAME @ -V 5 so it would be pretty useless.

There is one thing that has been bugging me for a while. Why do we need another open source mp3 Encoder if we already have Lame? I mean, Lame is great and is still being developed.

because of the speed of this one, surely? The 'market' that Lame 3.xx addresses is the market for top-quality mp3 encoding. Sometimes quality is only one of several desiderata; sometimes you want to quickly transcode from archived lossless sources for portable use. That's the 'market' where alternative fast encoders like this are called for. It might also be useful for people with iPods with the Lame clipping problem (who for some reason want to stick with mp3 instead of using AAC instead).

so is it much faster than gogo? How does the quality compare to gogo? Also, what is that Lame clipping issue on iPods you refer to?

I am a big fan of Lame too; however, Which is the problem with to have other alternatives? I like to have other alternatives; mainly, with this encoder that is extremely fast with good quality, probably not as good as Lame; but very close. At least, I have been able to see this with my ABX tests (in post #170), and that nobody until the moment has taken the time (or the interest) in checking.

Lame is the excellent encoder that is today by the effort of the developers and the extensive listening tests. I am sure that this Real encoder (Xing?) with some effort and tweaks could be a excellent competitor.

That I know, HA is a open-site to discuss and to improve encoders; not only one. The opposite to this is a close-mind position.

me too.

Actually, I think there is a general lack of interest in this mp3 encoder and people tend to be more interested in testing lame. For instance, I wasn't expecting a reply to my post about the -HF switch

As for quality compared with gogo, well, Real's mp3 encoder is basically an improved version of Xing (Xing used only long blocks while Real's added block switching to it), so I guess we could somehow refer:



I'm not too familiar with the lame clipping issue but I have heard that lame mp3s encoded with --alt-preset tend to skip on the iPod while the helix mp3s at this bitrate range are fine.

Regarding the first two questions, I can only go by the comparisons made or linked to earlier in this thread. And sure, gogo is a contender here too. But this encoder is also a relatively recent arrival, another reason why there's an active thread about it at this time (which is more or less what your question was about, I thought).

Regarding the third, I was intending to refer to the skipping/stuttering problem that's been reported sometimes for Lame playback on the 2G+ iPods, minis and so-forth - I have no idea why i typed 'clipping' instead. Probably the scotch talking. My bad.

Is it only me If i try to encode some music that starts loud and has no silence in the beginning an ugly loud "click" is added.

Edit: I found the answer myself. Some of my wav samples on the HD produce these clicks. These wavs are having longer wav headers for some reason. I don´t know with what application they were made but opening them in audacity and saving them again shortens this header and the clicks in the beginning while encoding dissapear.

Just tried -V120 -X2 -HF2 -SBT450 -TX0 -F18600 on trumpet, herding_calls and atem-lied (from problem sample and lame_attack thread).
Helix encoder yielded results which are perfect to me. The 'normal' music tracks I tried were fine as well.
I've been a very high bitrate CBR/ABR fan so far but about to convert to VBR of this kind.

Halb27: You keep talking about these same samples over and over. Do you realize that this encoder is underperforming on a lot of other samples?

Which samples? I would be very interested in some comparative data especially at low bit rates.

You are right, I'm concentrating on rather few problem samples apart from 'normal' tracks.
But what's wrong with it? If everybody shares his experience with those samples he knows best that's the way to go IMO.

I'm very interested in the other samples the encoder is underperfoming. Please share your experience.

At least Helix doesn´t add this sandpaper scratching noise to the other samples. Since 397 --vbr-new does this on a regular basis Helix at these high settings is often better than the actual V2 Hydrogenaudio recommendation

I encoded some music and have to say the HF performance is poor to even my aged ears. Like old fhg encoders it just lets pretty audible information dissapear.
Here is a very obvious sample and no, it is not only a spectral view problem.
Helix HF sample

People have talked about speed of LAME encoding, yet nobody seems to have noted the speed improvement in LAME 4.0 alpha builds.

What a pity.
I have put a lot of hope into this encoder because with all the music I had encoded so far things were fine to me.
Personally I can't hear the problem, but as I know from many problem samples I can't really concentrate on samples which are very much opposed to my musical taste.
How do you rate HF performance of other encodings? Does it look like being a rather isolated problem or is it more a problem of general HF behavior?

From what i remember of when i tried it, it simply uses -q 5, as opposed to -q 2 ( -q 3 in lame 3.97), which is part of the reason of this speed increase.

Lame 4.0 is completely different from the 3.9x versions. This is the reason of the speed increase.

You know that the general performance of any encoder cannot be determined by only one difficult sample.

For example Helix [-V120 -X2 -HF2 -SBT450 -TX0] beats Lame3.97b2[-V2] in the infamous aps_killer_sample. You do ABX tests in this difficult sample and you will see that Helix to perform a lot better than Lame there.

And you know that I could not suggest that Helix is better than Lame by that, right?

I used Helix [-V120 -X2 -HF2 -SBT450 -TX0] to test your sample (without the -F19000 combination). In my post #170; I described that the -F19000 combination was redundant, because only -HF2 has a cutoff in 19500 Hz. In addition, I said that apparently -F19000 was adding something of phasing effect there; however I suspect that you probably don't read this. If you want to test high frequency behavior the result will be more reliable without the -F combination and with HF2 enabled, not HF that is buggy.
The results were the same than halb27: I don't hear nothing bad there; In fact, it was transparent for me. In addition, I did a spectral analysis with Cool Edit Pro and the high frequency component (>16 Khz) is alive there. With velvet sample I did a spectral view too, and the high frequency component (>16 Khz) is very strong there.

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.

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.

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.

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).

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.

Where can I find a helix frontend?

Thanks

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

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.

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.

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.

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.

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 ?

@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?

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