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: Resurrecting/Preserving the Helix MP3 encoder (Read 40485 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #150 –
In fb2k I use -V35 - %d
I need to add -M3 for mono files...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #151 –
Quote from: rutra80 on
In fb2k I use -V35 - %d
I need to add -M3 for mono files...

Can you try passing an intermediate WAV file to hmp3 (instead of using stdin)? I've seen funky things happen with input from stdin on Windows with hmp3. Under normal circumstances, the -M switch should never be needed.
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #152 –
Apparently the problem is bit-depth higher than 16bit - mono files I tried were lossy or sequenced (internally 32bit float in fb2k), while the stereo ones that worked were 16bit lossless. Setting highest bps mode supported to 16bit in fb2k makes it work good even with pipe.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #153 –
I compiled hmp3 successfully on MacOS on a M1 (arm64). It encodes in a flash. Amazing encoder with similar quality.

What are you favourite parameters? Is -V120 (or -V150) -X2 -SBT450 -TX0 -HF2 still recommended? Anyone ABXed some settings? Thanks!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #154 –
Hmmm Helix seems to struggle with higher bitrates as far as I can see. It just doesn't know how to utilize more bitrate. Not a good choice for 320kbps CBR.
Opus VBR 256 + SoX

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #155 –
Quote from: Eurobeat_fan on
Hmmm Helix seems to struggle with higher bitrates as far as I can see. It just doesn't know how to utilize more bitrate. Not a good choice for 320kbps CBR.

So would you favor LAME over Helix?.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #156 –
Quote from: Eurobeat_fan on
Hmmm Helix seems to struggle with higher bitrates as far as I can see. It just doesn't know how to utilize more bitrate. Not a good choice for 320kbps CBR.

Not to stress TOS#8 but I never had any Issues with V120 ~ V150 with Noise/electronic/extreme metal. Feels like some here are trying to justify LAME when Helix MP3 does a lot better on way more samples mainly pre-echo rich ones. I gave up using AAC at 256kbps VBR when my Sony DAP's AAC decoder will ignore flies that reach 480 ~ 510kbps???.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #157 –
Quote from: Nani786 on
Helix MP3 does a lot better on way more samples mainly pre-echo rich ones.

I certainly have a soft spot for the Helix MP3 encoder (no surprises there, I guess), but I feel that this is a statement that deserves supporting data, just like Eurobeat_fan's "Not a good choice for 320kbps CBR" (at such bitrates I expect "usually transparent" results). Gathering data is good - learning what the encoders handle differently might highlight venues for improvement.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #158 –
Quote from: Nani786 on
Not to stress TOS#8 but I never had any Issues with V120 ~ V150 with Noise/electronic/extreme metal. Feels like some here are trying to justify LAME when Helix MP3 does a lot better on way more samples mainly pre-echo rich ones.

Sorry you just can't say stuff like that & walk away, without some ABX testing, or bare minimum some sample tracks.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #159 –
Quote from: maikmerten on
just like Eurobeat_fan's "Not a good choice for 320kbps CBR" (at such bitrates I expect "usually transparent" results)
What I meant about calling it an inferior choice is that it doesn't really utilize the bitrate it has in CBR 320 kbps. It continues to show its typical differences from LAME (sticking to mid-side stereo instead of true stereo most of the time, using sfb21 less often), and it leads to the fact that it almost never uses bit reservoir to its full potential. I have only seen Helix using 150 bytes out of 511 for any block possible but never the whole 511 byte, not for a single transient. This means that at 320 kbps we just waste bits for nothing, the bitrate is excessive to the psy-model that Helix utilizes and it can do just fine with, let's say, 224 kbps CBR. It may be not a problem in general but I'm pretty sure that Helix will fail on more samples than LAME does at 320 kbps simply because LAME has more ideas about what information to save into a 320 kbps file.

I don't have any complains about VBR mode in that regard (obviously).
Opus VBR 256 + SoX

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #160 –
Ah, thanks for elaborating, that's very useful context.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #161 –
Quote from: Eurobeat_fan on
Quote from: maikmerten on
just like Eurobeat_fan's "Not a good choice for 320kbps CBR" (at such bitrates I expect "usually transparent" results)
What I meant about calling it an inferior choice is that it doesn't really utilize the bitrate it has in CBR 320 kbps. It continues to show its typical differences from LAME (sticking to mid-side stereo instead of true stereo most of the time, using sfb21 less often), and it leads to the fact that it almost never uses bit reservoir to its full potential. I have only seen Helix using 150 bytes out of 511 for any block possible but never the whole 511 byte, not for a single transient. This means that at 320 kbps we just waste bits for nothing, the bitrate is excessive to the psy-model that Helix utilizes and it can do just fine with, let's say, 224 kbps CBR. It may be not a problem in general but I'm pretty sure that Helix will fail on more samples than LAME does at 320 kbps simply because LAME has more ideas about what information to save into a 320 kbps file.

I don't have any complains about VBR mode in that regard (obviously).

Sounds like the Helix Dev's so no reason to care about CBR since 98% of devices can handle VBR MP3.

Quote from: The Irish Man on
Quote from: Nani786 on
Not to stress TOS#8 but I never had any Issues with V120 ~ V150 with Noise/electronic/extreme metal. Feels like some here are trying to justify LAME when Helix MP3 does a lot better on way more samples mainly pre-echo rich ones.

Sorry you just can't say stuff like that & walk away, without some ABX testing, or bare minimum some sample tracks.


I'm Sorry does the Listening Tests sub-forum become Invisible when there public data showing Helix doing better than LAME like Kamedo2's at 192kbps?. I've never seen a public DBT with LibVorbis 1.3.7 vs aoTuV 6.03 yet the libvorbis encoder is the default encoder for Foobar2000.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #162 –
Quote from: maikmerten on
Yeah, the AAC encoder would have been very interesting, albeit I'm not sure it would be as mature compared to other AAC encoders as the Helix encoder is compared to other MP3 encoders. The Helix MP3 encoder has been around for a long time before being open-sourced. While I trust LAME more for (near-)transparent encodes (on grounds of being well-tested), at non-transparent, low bitrates (such as 96 kbps) it appears that Helix is pretty well tuned to keep the typical low-bitrate-MP3-artifacts somewhat less annoying.

For instance, check https://lame.sourceforge.io/download/samples/iron.wv (this is a sample file losslessly encoded with wavpack), decoded to iron.wav:

Code: [Select]
lame -q0 -b96 --lowpass 16000 --resample 44100 iron.wav lame.mp3

and compare to

Code: [Select]
hmp3 iron.wav hmp3.mp -b48 -F16000

(96 kbps stereo, lowpass 16000 Hz, 44100 Hz samplerate - well outside the usual comfort zone)

I'm aware that we do not listen with our eyes and that at HA, sound quality is not to be judged via spectograms, but this is an example where LAME has very audible problems with "bald patches"/"holes" in the spectogram, leading to the familiar "MP3 at too low a bitrate" artifacts, while Helix seems to be able to keep the frequency bands stocked much better, with obvious audible differences (looking nervously at TOS 8 ).

(I'd love to attach the encoded samples, but the copyright situation might not permit it. I'd love some freely available lossless test samples, e.g. CC-licensed)

I wonder if there's something for LAME to learn here.

Lame adds a ringing artifact in CBR / ABR mode + lower bitrate; perhaps up to 128 or 160k. 
Its easy to isolate and usually adding -q level < 3 can yield a significant improvement.  I use -q5 , perhaps
even -q7 for 128 or lower. For VBR it doesn't seem to be as effective.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #163 –
Quote from: Nani786 on


I'm Sorry does the Listening Tests sub-forum become Invisible when there public data showing Helix doing better than LAME like Kamedo2's at 192kbps?. I've never seen a public DBT with LibVorbis 1.3.7 vs aoTuV 6.03 yet the libvorbis encoder is the default encoder for Foobar2000.

You did not say your info, was from a listening test. even so if it's this one it does not show "Helix MP3 does a lot better" as you say, so maybe you can post some of your own ABX tests.
You never know, you may be the NEW Kamedo2.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #164 –
Quote from: Nani786 on
Sounds like the Helix Dev's so no reason to care about CBR since 98% of devices can handle VBR MP3.
No, they just didn't do extra tuning for high bitrates. Their psy model does incredible job at bitrates like 128-192 kbps but it doesn't use any strategy for scaling up aside from activating sfb21 (iirc HF2 switch does not work at bitrates lower than 192 kbps). This is actually a good approach - I even see parallels with Opus here (hell, even VBR decisions are pretty similar to what Opus does), the only problem is that MP3 as a codec is too bad for this approach, so to squeeze more potential out of MP3 at high bitrates like 320 kbps you need more complex solutions (and that's exactly what LAME does - more true stereo blocks, densier sfb21 frequencies, heavier bit reservoir usage).
Opus VBR 256 + SoX

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #165 –
I noticed that this encoder is very efficient when it comes to space and sound quality. I think it encodes MP3s in a very similar way to what the "-Y" switch does on LAME and if you are using the "V80-150" setting, then it would apply a hard lowpass filter at 20khz (kinda like what FDK/OPUS does). I think the reason why is because it forces the encoder to focus more on the lower frequencies (below 16khz) and not waste bits on the higher non-audible range
LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #166 –
Comrades, could we draw an intermediate conclusion by agreeing that Helix is ​​definitely a good choice, for example, when encoding audio books and radio plays with low bitrate, when non-MP3 codecs for some reason (e.g. old hardware compatibility) cannot be used? If so, what encoding parameters do you consider appropriate in this case?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #167 –
I think the original poster on here recommended the parameter -F16000 -B48 -N8 for low bitrate/radio streaming application and for streaming quality music is -V75 -X2 -SBT450 -TX0 -HF2 -F16000
LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #168 –
For low bitrate audiobooks (with occasional music in between), I guess -F16000 -B48 -N8 might indeed work as a starting point if you need CBR.

The latter command (-V75 -X2 -SBT450 -TX0 -HF2 -F16000) is a bit strange. Why enable high-frequency encoding (> 16 kHz), but put a 16 kHz lowpass there? Also not quite sure tweaking the short block threshold has clear benefits.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #169 –
Hmmm well I guess discard the -SBT450 one.  :D
I think I saw in the manual that you can use -HF-1 (that's I would use) and let the encode decide the high frequencies or not. Otherwise just disregard that as well. Therefore it'll probably be:

-V75 -X2 -TX0 -HF-1   ;)

If one wants some high frequencies then
-V80 -X2 -TX0 -HF-1 -F18000
would work as well


LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Helix MP3 Encoder v5.1.1

Reply #170 –
This is the encoder I use to prove that MP3 can still hold up.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #171 –
Aggrrhh, I've come across this limitation. Helix wants 16 bit.

Code: [Select]
$ hmp3.exe in.wav out.mp3 -V150 -HF2 -U2

 hmp3 MPEG Layer III audio encoder 5.2.1, 2022-12-19
 Utilizing the Helix MP3 encoder, Copyright 1995-2005 RealNetworks, Inc.

 PCM input file: in.wav
 channels = 2  bits = 24,  rate = 48000  type = 1
 UNSUPPORTED PCM FILE TYPE
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #172 –
Ah yes! One of the biggest limitations of this MP3 encoder is that it's only 16-bits only. No 32-bit floating unlike LAME and other modern encoders
LAME: -f -V 0 -Y
 Xing: -V150 -X2 -U2 -HF-1 -TX0

Re: Re: Helix MP3 Encoder v5.1.1

Reply #173 –
@KrajzegaX, have you examined the code of this Helix encoder?
Perhaps you could lift the veil of secrecy over -SBT450 -TX0 settings then.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #174 –
Quote from: Case on
I don't think Sector Boundary Error is correct term, that is related to incorrect writing of audio data to a CD.
This MP3 encoder just fails at being gapless. The way audio is sent to the encoder is irrelevant.

Quote from: Apesbrain on
Quote from: Kraeved on
@ApesbrainAlso, do you encounter such errors when encoding via pipe or when calling directly too (hmp3 in.wav out.mp3)?
Encoding via pipe. I guess it doesn't matter that SBEs are created. I was just curious since LAME did not exhibit this behavior. TBH, I'd need to check that again.

EDIT: Confirming LAME (32bits version 3.100) does not create SBEs.

I should learn to shut up sometimes. I just tested the Helix encoder and the latest version from Rarewares does write proper gapless info to the headers. But it seems to have some limitations or bugs as it doesn't do it when the data is fed through a pipe. Not even when the piped data is a full WAV with perfectly valid length fields.

Detecting this type of error is super simple. Just look at file length as samples and you'll see the original and the encode have different lengths. Such files can never be gapless. Easy workaround for this is to use temp file in foobar2000 converter. Replace the single dash '-' with '%s'.
And how this can relate to Audio CD sector boundaries, audio CDs require track lengths to be multiples of 588 samples. If a track length doesn't match that the burning software needs to pad it with silence. The files aren't gapless outside CD but when burned to a CD as-they-are, the tracks would get extra gaps between them.




MOD edit: added quotes before splitting post to a different topic