I just read this info from Karl here in Doom9



Could be great if someone can try to build a binary for windows at least....maybe John33

The source code link is broken, it's: https://helixcommunity.org/viewcvs/cgi/view.../codec/encoder/
I'll look at it, but there doesn't seem to be a simple d/l or anonymous CVS access, as yet, so it looks like grabbing a file at a time!!

What's RPSL/RCSL license, briefly?

You can d/l the doc and the source (including the RPSL licence text) from: http://homepage.ntlworld.com/jfe1205/helix_mp3enc.zip

I've not attempted any kind of build, as yet, this is just copied from the Helix CVS.

You need a free registration at helixcommunity.org to be able to acces their cvs server. More information: https://common.helixcommunity.org/2004/devdocs/quickstart

I beg one of my friend to compile a windows binary of this mp3 coder for me, and here it is:

http://www.hydrogenaudio.org/forums/index....showtopic=35540

Hope someone with good ear can evaluate this coder.

I could add this encoder in my next tests
I could make it work, but unfortunately I haven't found yet the magic formula to use it directly with foobar2000. Help would be appreciated For batch encodings (with PCM source only), I'm using Speek's Wav2Gogo (mp3enc.exe must be renamed as gogo.exe).

This encoder have a nice VBR scale (from 0 to 150).
Some points are obscure to me:



I'd say that quality is (clearly) inferior to LAME but speed could make this encoder more attractive.

Thank you guru.




I don't know all the options neither.

This coder is not considered stronger than LAME, but I'm afraid a lot of people want to know how good it can be.

As for the speed, a asm-enabled compile may be more faster (this compile didn't use asm code).

At the other forum they asked if this was the Xing encoder. Since it was Karl Lillevold who announced it, it may well be the case. Does anybody know? I couldn't open the .zip file and try it out.

Better wait to hear it from Karl himself. I couldn't see any XING headers in the sources, but considering the big amount of assembly code in there, I would suppose it is.

I'm trying to compile it with ASM, but they don't even mention what assembler you should be using! Hopefully it's MASM...

DigitalDictator, I have tried to download it @ HA with success. Your problem may be solved by clear the cache of your browser.

As we all know, Real bought Xing's mp3 encoder, so this coder have great possibility to be right the Real tweaked Xing. But this question is supposed to be answered by Karl himself.

The VBR mode sounds interesting. I've encoded 35 samples (from Roberto's listening tests) with -V50, and average bitrate was ~127 kbps (but with huge difference between samples). Quality was very interesting (forgot my previous comment about relative quality compared to LAME: serious testing is needed), and I'd say that it should be wise to give at least a try to this encoder.


About VBR and bitrate, it seems that some software have problems to calculate the bitrate. foobar2000 for example evaluate the bitrate at 80 kbps for each samples ?? MisterQuestionMan is also fooled. Only Encspot gives me reliable (I suppose) results. Also funny to see encspot detect three different encoders :
- Gogo (> 3.0) most often
- Lame (old) or m3e
- Xing (new)

http://foobar2000.net/divers/temp/RealEncspot.html
http://foobar2000.net/divers/temp/RealMQM.html

I also tried the vbr mode, after 'fix MP3 header' by foobar2000, the bitrate shows OK. This problem may due to the hush compile that cannot handle vbr-header right.

Note: The encoded mp3 is recognized as 'Xing (new)' by Encspot only when there's no short-block used.

Parameters: %s %d -V50
Highest BPS mode supported: 16


The BPS had me beat for a while.

Just tried with my collection of 150 samples. Average bitrate for -V50 setting is 122 kbps. Lowest bitrate happened with sample S26 (66 kbps) and highest one with sample A03 (250 kbps). Wow! That's VBR ! This last sample is now detected by Encspot as a Fhg (fastenc) source
Anyway, this sample proves if needed that a short-block switching algorithm is present, and is working:

long block = 15,2%
short block = 84,8% !!


I'm typing this message while listening the 150 samples, and the output gallery is far from being crappy. Some samples sound bad (solo harpsichord, percussions) but in average the encoder seems to be useable at this bitrate (not for archiving of course). I'm currently on my notebook I my judgment could be fooled by the poor output of the AC97 component; but on a weak DAP situation is not different.
Ah... I'm listening to piano, and pre-echo could also be annoying (S27 - S36 marimba too). Ringing on S30...
Well, it's MP3 at 123 kbps on average

It works fine now, thanks a lot!

Edit: sorry, it seems there's no need to recompile for now

Solution: Just add -X or -X2 to the commandline to solve the problem.

From mp3enc.exe -Help:

Yeah. Parameter should be "Parameters: %s %d -V50 -X" to get correct vbr-header.

Tomorrow, there will be a asm-enabled binary available.

I found a bug:

-V0 -X => no XING header
-V0 -X2 => no XING header

-V0 with 150 classical samples => 96 kbps and therefore could potentially be used in my next test with this group of sample.

[this is (almost) copied from my reply on doom9]:

If someone were to contribute standalone makefiles, or bugfixes, especially ones that on Win32 will include the i386 asm code, I am sure that would be most appreciated. I can check them into CVS (after a code review on the proper Helix mailing list).

Yes, this is based on the (infamous) Xing encoder, but it has been much improved from its early days, and does not suffer from the well known problems it had. This encoder was never included in any stand-alone Win32 Xing encoder app, but has been shipping with RealPlayer for a few years.

AFAIK, after these improvements, it was also licensed to a large h/w electronics manufacturer who chose it after extensive quality tests.

New compile with asm enabled and several bug-fixes.

Please check.

http://www.hydrogenaudio.org/forums/index....64&#entry313464

Youp, -V0 -X is fixed on my side.
I don't know what kind of miracle the asm compile could do, but encoding speed is now much faster! Thanks for this update

Once again, a way more readable source code than Lame.
To me this is very interesting, in the same category as the 3gpp AAC encoder.

when (if) the quality of the encoder has been checked out, would it be possible to "borrow" some ideas and implement them into LAME? Or maybe vice versa? If, as Gabriel states, the code is much more simple to understand?

I have the same kind of question. Can this encoder be improved based on that wierd license.

For LAME, I'm sure 4.x series will be much readable than current branch.

All but "pow34.asm" can be compiled with MASM. The last binary I upload didn't use this asm.

I'll upload the third compile with "pow34.asm" used (use the .obj file from cvs to link).

Edit: the third compile upload down.

The licenses are conflicting.

Licenses can't prevent you from borrow ideas.

Patents do that.

The project file for compilation uploaded.

There's 2 files modified by CML, who compiled it. It's "tomp3.cpp" and "xhead.c"

You can download it here:

http://www.hydrogenaudio.org/forums/index....showtopic=35540

True. One doesn't have to copypaste anyone's code, he can just write the same thing by himself.

Well, if there are good ideas, perhaps they will also be used in Lame. However, please note that the Real encoder is way simpler than Lame, and its quality is probaly lower than the Lame one (but it should still be a overall good encoder).

Regarding implementing stuff from Lame into Real's encoder, I am wondering why would anyone do that, except people from Real. Remember that Real's encoder, while beeing open source (ie source are available) is still Real's full property.

However I like seeing clean audio encoders that work well, this is refreshing fo me.

I was surprised at the encoding speed of Helix MP3 encoder and made a comparison with other MP3 (and some codecs for reference) encoders in 128kbps range. Helix VBR mode (with ASM enabled) is really fast and impressive. IMHO the sound quality of -V75, which gives roughly 128kbps, is even better than F-IIS CBR 128kbps (no detailed comparison done, sorry). Quality comparison with Gogo3.13a -b128 might be interesting for impatient users.



Here's a list of binaries I used for this comparison:
- Helix MP3 Encoder (the third revision, with assembly code enabled)
- Fraunhofer IIS MPEG Layer-3 ACM Codec (professional) (with ACMENC)
- LAME MP3 Encoder 4.0 alpha 14
- LAME MP3 Encoder 3.97 alpha 11
- GOGO-no-coda ver. 3.13
- Ogg Vorbis aoTuV beta 4 with speed optimization (Lancer 20050709)
- MPC Encoder 1.15v
- Monkey's Audio 3.99
- FLAC 1.1.2
- WavPack 4.2

EDIT: I added the list of binary links.
EDIT2: I added "LAME4 -V4 --noreplaygain" (just for reference ) since it's 20% faster (according to Takehiro).
EDIT3: I added the results for Helix MP3 encoder with "-U2" option enabled. Now "gogo 3.13a -b128" and "mp3enc -V75 -X2 -U2" are tied in terms of encoding speed.

Insane speeds indeed.

And I'm amazed that so many encoders are faster than MPC. I had never seen a comparison like that.

Does those results use the new faster compile of mppenc 1.15v

Yeah, I downloaded mppenc yesterday from musepack.net .

Since Helix MP3 encoder is based on Xing version 2, and that encoder performed 8x faster than the encoders of that time (at least that was the slogan), I don't see this as much as a surprise, but as a confirmation of the source, and a good job at maintaining the efficiency when improving the encoder.
It performed almost realtime (or maybe a bit faster) in a P-133 while LAME of that time ( 3.20? 3.40? can' remember) took around 20 minutes for a 4 minute song in the same machine.

On the other side, nice graph. Now, as you say, the interesting thing is the ABX test against gogo

nyaochi,
Did you try the latest binary? For my PC Helix MP3 Encoder is the fastest.

WAV 45:23
Helix MP3 Encoder 0:37
GOGO 3.13 1:52
Ogg Lancer 1:56
MPC 1.15v 2:27
FAAC 1.24.1 4:16
Lame 3.97a10 4:45
Nero 3.2.0.7 6:11

WinXP SP2, AMD Sempron 2400+, 512mb ram

Yes, the third version as I wrote in the list of encoders. I have no idea why Gogo is so slow on your machine, but the other figures look reasonable to me.

Naw... I don't know if I want that really... I must say I'm totally lost when it comes to licences and patents. You say it's open source but still full property of Real's? So, can the encoder be forked? Are third party allowed to tune it? Or do you have to ask Real before you release a tweaked version? Are they still working on it?

I tried it out and the speed is jaw dropping. I will try to ABX it at around 128 kbps. I totally suck at ABXing but I'll give it a try.

Everybody,

Helix mp3 encoder can be even faster when use -U2 switch, which include optimization for P3 (SSE?).

With all these speed optimization, the output MP3 file are not bit-identical. But it may not suffer the quality much (someone can explain if this statement is true?).

Edit: some error corrections

New project uploaded. Code cleaned and all asm can be compiled by MASM now.

Thanks for all your tweaking, compiling, and testing. I will download the latest exe and try it out myself I have to admit, this is much more feedback than I had ever expected when I announced the release on doom9. I was going to announce on hydrogenaudio too, but kurtnoise beat me to it ...

All these works are due to my friend CML, who do all these tweaking, compiling, and testing.

I'll thank you, karl_lillevold. You bring us this good mp3 encoder.

Now we all are expecting for guruboolez's next test report on lossy codecs @ 96k.

About my next test: few words to say that I'm currently in holidays, and I can't consequently work for my test. Don't expect anything before 2 weeks I'd say

~16 seconds for a 5:18 Minutes track on my old Intel PIII500 with "-V90 -X -U2" this is a ratio of almost tracktime/20! With Lame vbr-new I have somewhere between 3-4 and 2 in old vbr mode.

There's some 'hidden' switches to play with this encoder. But some of them don't even have notes in the source code.

For example, there's a '-tx', default is 8, later altered to 6. With larger -tx, the produced file became bigger. Can someone tell me what the hell this switch down?

The correspond source is in bitallo3.cpp, line which contain


And I wonder if there's something can do with the lowpass frequency. Default lowpass never exceed 16k Hz.

Maybe Karl Lillevold can tell us a little bit more about those switches, e.g. -U2, what happens with the quality when you add it? Are there any switches that bring down the speed but increase the quality?

Helix mp3 encoder windows binary rev4 uploaded.

This version has more detailed switch description with -Help

Edit: This rev5 has no restriction to -hf switch.


As of the quality with high frequencies encoded, can someone with good hearing do some listening tests?