new Open Source mp3 Encoder from Helix Community Options

[karl_lillevold]

OK, already tested the new build on my problematic sample (Benassi Bros)
Seems to work now also using stereo mode 1 (JS)
THANKS, KARL, TO YOU AND YOUR COLLEAGUE!

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

Does anyone tested it with stdin input? couldnt get it to work with fb2k or with cli...
Here is the switches im using with fb2k cli encoder "- %d -X2 -A1 -V50 -U2"

EDIT: oops... The version i downloaded form Rarewares does works, but from Helix binary download page doesnt.

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.

[QuantumKnot]

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

[QuantumKnot]

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

[DigitalDictator]

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.

[Jojo]

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.

[Cpt. Spandrel]

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

[Jojo]

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?

[level]

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.

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.

[level]

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

me too.

[QuantumKnot]

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

[QuantumKnot]

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?

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.

[Cpt. Spandrel]

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?

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.

[Wombat]

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.

This post has been edited by Wombat: Jan 5 2006, 12:22

[halb27]

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.

[shadowking]

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?

[woody_woodward]

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.

[halb27]

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?

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.

[Wombat]

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

[Wombat]

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

[ckjnigel]

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

[halb27]

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

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?

[[JAZ]]

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

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.

[Gabriel]

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

[level]

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

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.

[halb27]

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.