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 212146 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #625 –
Quote from: vina54 on
Was there a reason why Helix had the 48 kbps per channel artificial limit?

From a source code comment:

Code: [Select]
// for public use, fail ridiculous bitrates

I think those were just safeguards against users shooting themselves in the foot and then voicing disappointment - Helix was a consumer-facing piece of software.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #626 –
This comment sounds very reasonable. Kudos to the developers  :D
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #627 –
I really love the fact that -SBT is a public switch since at -SBT= 1 It acts just like "--Allshort" in LAME. I wonder If the Helix's perceptual model could be tuned to switch to "-SBT=1" in really heavy transient rich audio. Because the other tests where LAME 3.99.5 was used It seems to be quite bad at detecting transients, If you move the pre-echo triggering area in Eig to the start LAME seems actually realises It needs short blocks.


OptimFrog PC | TAK -p4m(Phone)