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 44217 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #125 –
Damn it really wish they had Open Source their AAC encoder as well.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #126 –
Is it any good, or do they use licenced Fraunhoffer?
Error 404; signature server not available.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #127 –
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.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #128 –
I now updated the encoder so that proper CRCs are included in the info header. The very, very useful tool "mp3guessenc" is now happy regarding the tag CRC and music CRC.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #129 –
Marvelous! :) Rarewares compile updated.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #130 –
Thanks!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #131 –
I noticed one thing about the encoder version. In Mediainfo with CBR it shows garbage at the end of the version, where with VBR it is correct. Looking at the hex editor there is a difference of one byte.
CBR:
Code: [Select]
0000:0080 |                                           4C 41 4D |              LAM
0000:0090 | 45 48 35 2E  32 31 01 F0                           | EH5.21.ð       
VBR:
Code: [Select]
0000:0080 |                                           4C 41 4D |              LAM
0000:0090 | 45 48 35 2E  32 31 00 F0                           | EH5.21.ð       
A workaround for this is to change byte from 01 to 00 and after this operation correctly appears without strange characters. I don't know if this can be corrected in code, @maikmerten?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #132 –
Quote from: KrajzegaX on
I noticed one thing about the encoder version. In Mediainfo with CBR it shows garbage at the end of the version, where with VBR it is correct. Looking at the hex editor there is a difference of one byte.
CBR:
Code: [Select]
0000:0080 |                                           4C 41 4D |              LAM
0000:0090 | 45 48 35 2E  32 31 01 F0                           | EH5.21.ð       
VBR:
Code: [Select]
0000:0080 |                                           4C 41 4D |              LAM
0000:0090 | 45 48 35 2E  32 31 00 F0                           | EH5.21.ð       
A workaround for this is to change byte from 01 to 00 and after this operation correctly appears without strange characters. I don't know if this can be corrected in code, @maikmerten?

Hi, thanks for reporting, but to me it looks like that's a bug in Mediainfo.

The short version string in the info tag is 9 characters long. In C, strings are "zero terminated", meaning the end of the string is denoted by a zero value after the last character, to avoid having to store a string length somewhere else. The short version string, however, is not zero-terminated, it has a fixed length of 9 bytes, and directly following the short version string is the "Info Tag revision + VBR method" byte: http://gabriel.mp3-tech.org/mp3infotag.html#rev-method

For VBR, I write 0x00, to denote "rev.0 info tag, and unknown VRB type" ("unknown" because whatever Helix is doing with VBR, it does not match any specific LAME VBR method). This by chance happens to zero-terminate the short version string.

For CBR, I write 0x01, to denote "rev.0 info tag, and constant bitrate", which doesn't zero-terminate the short version string by chance anymore.

Does this lead to any further trouble, other than Mediainfo showing trailing garbage? I feel that hmp3 is doing the right thing here, but if it happens to format hard drives and set buildings ablaze, it might be better to compromise here.

(This, btw, demonstrates why standards need several implementations and clear documentation to achieve some robustness.)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #134 –
Maybe it is worth just to use a shorter string like LAMEH5.2 or LAMEH521 for better compatibility. I guess some other programs may also expect a null terminator there since it is usually there in existing files.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #135 –
I've been fiddling with the encoder name and confirm that it's a bug in MediaInfo. When I changed from "LAMEH5.21" to "LAME3.100" characters at the end disappear and "Encoder settings" appears underneath.
Quote from: VEG on
Maybe it is worth just to use a shorter string like LAMEH5.2 or LAMEH521 for better compatibility. I guess some other programs may also expect a null terminator there since it is usually there in existing files.
I tested these shortened encoder names and characters at the end do not appear. This is a good idea to solve this problem.
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #136 –
Seems that MediaInfo expects  LAME<singlechar><dot><something>

If there is a risk that other applications behave as MediaInfo, then the following strings could be considered:
LAMEH.520
LAMEH.5.2
LAMEH.52b
... the latter could be used for beta versions. But to flag that it is a beta, you could also replace "H" by "h" - at least as far as MediaInfo goes - so that 5.2 beta is LAMEh.5.2 and a "proper" release is LAMEH.5.2

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #137 –
The problem with having a shorter version string and then using the 9-th character to zero-terminate the 8-char string is that applications that actually work properly (not relying on zero-termination) might misbehave, as "0" is not a displayable ASCII character.

So, avenues to "fix" things: a) fix Mediainfo. If nobody steps in, I might file a bug report or b) always write 0x00 behind the short version string, also for CBR files, as initially suggested. I attached a representation of my currently preferred approach.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #138 –
"9 characters" isn't enough for MediaInfo:
LAME3.100 is OK
LAME3.99r is OK
LAME03.99 is not, despite being 9 characters.
LAME3.99 is not OK either, so it does require the 9th character ... did ancient LAME write NUL or something else?

So I think it needs the dot in the right place. If it is only MediaInfo, then ask them to fix it, but ...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #139 –
The easiest way I would choose option b, because decoder recognizes at Xing and Info header what kind of bitrate mode it is anyway.
This is my opinion. :D

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #140 –
This is how it is implemented there:
https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Audio/File_Mpega.cpp#L1432
And the most recent fix that was added because of LAME 3.100:
https://github.com/MediaArea/MediaInfoLib/commit/b9dc0b8de3a228fceadefd34744d2a073ecbb3ff
So it expects "LAME3.90" and newer, and the dot is expected at the fixed position. As an alternative, it supports "L3.99" prefix also.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #141 –
Clearly the problem lies in MediaInfo imposing constraints upon the content of the LameTag that are not present in its specification. While the LAME developers anticipated other software developers imposing such restrictions, I don't believe that they expected such tight constraints. It should be filed as a MediaInfo bug.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #142 –
Yeah, that parsing code is very specific - that's not very flexible. Thanks for finding the specific code locations!

I'll file a bug for MediaInfo and perhaps some insights will be generated how to handle things in a general matter.

edit: MediaInfo issue opened over at https://github.com/MediaArea/MediaInfoLib/issues/1637

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #144 –
MediaInfo change log:

Version 22.12, 2022-12-22
-------------
...
x I1637, MPEG-Audio: proper support of Helix MP3 encoder detection and encoder settings
...
--------------------

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #146 –
Hey guys, could you please help me solve my confusion? :)

There's a setting called nsbstereo - "Applies to mode-1 stereo mode only. Number of subbands to encode in independent stereo.  Valid values are 4, 8, 12, and 16.". What does it mean? I thought you can switch the whole block to mid-side or true stereo but you can't switch specific bands to ms/ss in MP3. Was I wrong?
Opus VBR 256 + SoX

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #147 –
Hi, Helix, unlike LAME, supports intensity stereo. As far as I can tell, with nsbstereo one selects how many bands are coded with intensity stereo, with the rest being coded with mid-side-stereo.

This, however, only works for a) CBR files and b) means that no short blocks will be used. The Helix encoder has two separate bit allocation engines. Intensity stereo is only supported with the old engine (CBR only, no short blocks) apparently directly inherited from Xing. The new bitrate allocation engine supports VBR and short blocks, but has no support for intensity stereo.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #148 –
Would it be possible for Helix to switch automatically between mono/stereo encoding? Currently it throws an error when I want to encode a mono file and won't change the commandline.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #149 –
Quote from: rutra80 on
Would it be possible for Helix to switch automatically between mono/stereo encoding? Currently it throws an error when I want to encode a mono file and won't change the commandline.

Hi, can you provide a command-line example that fails for mono files? Usually Helix should auto-detect mono/stereo...