Skip to main content

Notice

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 Open Source mp3 Encoder from Helix Community (Read 223841 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

new Open Source mp3 Encoder from Helix Community

Reply #225
Quote
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.
[a href="index.php?act=findpost&pid=357982"][{POST_SNAPBACK}][/a]


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.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

new Open Source mp3 Encoder from Helix Community

Reply #226
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.

new Open Source mp3 Encoder from Helix Community

Reply #227
Quote
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.
[a href="index.php?act=findpost&pid=358035"][{POST_SNAPBACK}][/a]

dm_s is of that kind. That´s why lame seems to be that better here.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

new Open Source mp3 Encoder from Helix Community

Reply #228
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.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #229
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).
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #230
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.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #231
Where can I find a helix frontend?

Thanks

new Open Source mp3 Encoder from Helix Community

Reply #232
I use foobar as a universal encoding frontend.
You can configure any CLI encoder to work with foobar.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #233
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.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #234
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.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #235
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: [Select]
  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

new Open Source mp3 Encoder from Helix Community

Reply #236
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.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #237
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 ?

new Open Source mp3 Encoder from Helix Community

Reply #238
@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?

new Open Source mp3 Encoder from Helix Community

Reply #239
Any updates on this?

new Open Source mp3 Encoder from Helix Community

Reply #240
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
Do your ever wonder about your soul?
Can it be saved...

new Open Source mp3 Encoder from Helix Community

Reply #241
I wonder what is the recommended command line for Helix MP3 encoder for files between ~ 170 - 185 kbps (Lame's -V 3 and -V 2)? Please can you suggest me one? I've found somewhere this command line:
Code: [Select]
For music:
-X2 -U2 -V120 - %d

For voice:
-X2 -U2 -M3 -V40 - %d
Regarding the previous post, it seems that there's also a newer version than the one on rarewares... On dBpoweramp codec central there is a Real Audio Helix Encoder Release 6.
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

new Open Source mp3 Encoder from Helix Community

Reply #242
So how does Helix now compare to LAME?

new Open Source mp3 Encoder from Helix Community

Reply #243
So how does Helix now compare to LAME?
According to the previous posts - it is said that Helix is a bit worse in low bitrate settings and on par with the higher bitrates and is much faster encoder (5x to 10x realtime compared to Lame).
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

new Open Source mp3 Encoder from Helix Community

Reply #244
Regarding the previous post, it seems that there's also a newer version than the one on rarewares... On dBpoweramp codec central there is a Real Audio Helix Encoder Release 6.

This is RealAudio encoder pack that also contains helix.


So how does Helix now compare to LAME?

http://listening-tests.hydrogenaudio.org/s...tian/mp3-128-1/

new Open Source mp3 Encoder from Helix Community

Reply #245
According to the last public mp3 listening test at 128 kbps on average (2 years ago I guess) helix came out very well, judging from the usual average results it was on par with Lame, FhG and others.
Looking at the various test tracks in detail, each of the contenders had their weaknesses though overall results were great. Helix' weakness is with metal / hard rock music, but it was one of the best allrounders.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #246
This is RealAudio encoder pack that also contains helix.
Yep, thanks for clarification. After decompressing the dBpoweramp-encoder-helix.exe pack, I found out it is the same executable as the one found on rarewares.

Please can you suggest me a good command line for encoding around Lame's "-V 3" ?
Sorry for my poor English, I'm trying to get better... ;)
"The greatest trick the Devil ever pulled, was convincing the world he didn't exist."

new Open Source mp3 Encoder from Helix Community

Reply #247
I'd use the command line from that listening test: -X2 -U2 -Vxx, with xx so that you get at the average bitrate you're targeting at. I guess xx ~ 80 will do.
So I suggest to use -X2 -U2 -V80, or similar.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #248
I was wrong.
I just figured out with my standard test set of various pop music:
-X2 -U2 -V100 yields an average bitrate of 168 kbps.
For a comparison: Lame 3.98.4 -V3 yields an average bitrate of 166 kbps for this test set.
lame3995o -Q1.7 --lowpass 17

new Open Source mp3 Encoder from Helix Community

Reply #249
"Unholy thread resurrection, Batman!"  I just read through it, also because of the last MP3 128 kbps listening test, and noticed that the embedded pictures of the speed comparisons by Nyaochi are gone, probably because he changed his website since then. So here is the latest version in English that I could find from late 2006:

http://nyaochi.sakura.ne.jp/encoder-benchmark/

If I understood it correctly, the -U2 switch is optimized for Pentium III with SSE, not for a Pentium 4 with SSE2 and newer versions, right? And has the mystery been solved what all the other switches used in this thread actually mean?
ZZee ya, Hans-Jürgen
BLUEZZ BASTARDZZ - "That lil' ol' ZZ Top cover band from Hamburg..."
INDIGO ROCKS - "Down home rockin' blues. Tasty as strudel."