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 19869 times) previous topic - next topic
0 Members and 1 Guest 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.
wavpack -b2.9cs.5
lame --preset cd -f

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