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 46016 times) previous topic - next topic
maikmerten and 3 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #75
A version bump is certainly a good idea, if only as a differentiator. Can I also just add that the lametag version should be set to '0', the same as is set in the latest lame svn.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #76
A version bump to v6 would be a great idea. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #77
Well, thanks for the kind suggestion of the changes being enough to justify a major version. Personally, I think that while a version bump can be well justified, I think it should suffice to bump the version to 5.2.0. My reasoning: The encoding algorithms were not changed even a tiny bit, and thus the quality is unchanged. This is merely an update with bugfixes, fewer compiler warnings and one actually new feature (gapless playback).

Just keep in mind how long LAME is on version 3.xx, with much, much bigger changes and how much tuning went into that!

Given that the encoder name string can only consist of nine characters, but for good compatibility I need it to start with "LAME", I want a major/minor/tiny-version number in there and a decimal point to have it look like a parse-able number, I guess there is not much room for major cleverness in there. For me, this looks like "LAMEH5.20"...

Is this something people can live with?

I'm testing setting the lametag version field to "0", to follow LAME's example. edit: Interestingly, with the header set to version "0", eyeD3 won't find a LAME info header... john33, did you find a case where version "0" works, but version "1" gives trouble?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #78
....
I'm testing setting the lametag version field to "0", to follow LAME's example. edit: Interestingly, with the header set to version "0", eyeD3 won't find a LAME info header... john33, did you find a case where version "0" works, but version "1" gives trouble?
Well, no, but Gabriel's Mp3 Info Tag revision 1 spec provides for 20 bytes between the Xing/VBR tag and the lametag which, unless I am much mistaken, is not currently allocated/used in the tag written by lame. I can see what looks like a provision for it in xhead.c but the conditions are never met and nothing gets written. I don't believe that Revision 1 has ever been implemented.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #79
....
I'm testing setting the lametag version field to "0", to follow LAME's example. edit: Interestingly, with the header set to version "0", eyeD3 won't find a LAME info header... john33, did you find a case where version "0" works, but version "1" gives trouble?
Well, no, but Gabriel's Mp3 Info Tag revision 1 spec provides for 20 bytes between the Xing/VBR tag and the lametag which, unless I am much mistaken, is not currently allocated/used in the tag written by lame. I can see what looks like a provision for it in xhead.c but the conditions are never met and nothing gets written. I don't believe that Revision 1 has ever been implemented.

Yeah, I think you're right. Version 0 it is, then.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #80
...
Yeah, I think you're right. Version 0 it is, then.
In truth I don't think anything out there pays any attention to it, but I do think '0' is correct. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #81
Rarewares compile updated. :) Huge thanks to @maikmerten for excellent work in bringing this project up-to-date.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #82
Thanks for testing and making builds available :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #83
I updated the Xing wiki page.

I also searched the wiki for Helix entries and there were a few in the Private Listening Test page, so I updated the links and then decided to update all the url links as they were all borked.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #84
I updated the Xing wiki page.

Mmm.. Shouldn't AudioCatalyst be mentioned too there?  (and at RRW, there is also the Xing encoder)

Given that the encoder name string can only consist of nine characters, but for good compatibility I need it to start with "LAME", I want a major/minor/tiny-version number in there and a decimal point to have it look like a parse-able number, I guess there is not much room for major cleverness in there. For me, this looks like "LAMEH5.20"...

I don't remember it exactly now, but I remember that when lame went to lame 3.100, there were some software that choked with the version string change. Not sure if that's what happens with LAMEX5.11.

Also, I see this in the lame code ( VbrTag.c)
Code: [Select]
    /*
    NOTE:
            Even though the specification for the LAME VBR tag
            did explicitly mention other encoders than LAME,
            many SW/HW decoder seem to be able to make use of
            this tag only, if the encoder version starts with LAME.
            To be compatible with such decoders, ANY encoder will
            be forced to write a fake LAME version string!
            As a result, the encoder version info becomes worthless.
    */
    const char *szVersion = get_lame_tag_encoder_short_version();
Code: [Select]
/*! Get the _very_ short LAME version string. */
/*!
  It's used in the LAME VBR tag only, limited to 9 characters max.
  Due to some 3rd party HW/SW decoders, it has to start with LAME.

  \param void  
  \return a pointer to the short version of the LAME version string.
 */
const char*
get_lame_tag_encoder_short_version(void)
{
    static /*@observer@ */ const char *const str =
            /* FIXME: new scheme / new version counting / drop versioning here ? */
    "LAME" STR(LAME_MAJOR_VERSION) "." STR(LAME_MINOR_VERSION) P
    ;
    return str;
}


Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #86
Thanks for the Wiki updates!

And yeah, the code snippets seem to confirm that for maximum compatibility, one has to prefix the encoder name with "LAME"... :-/

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #87
I found a problem with CBR files, it shows that there is a variable instead of constant bit rate. The reason is for VBR there should be an "Xing" header and for CBR there should be an "Info" header.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #88
I found a problem with CBR files, it shows that there is a variable instead of constant bit rate. The reason is for VBR there should be an "Xing" header and for CBR there should be an "Info" header.

I think the proper solution here is to use the "Info Tag revision + VBR method" field, as specified in http://gabriel.mp3-tech.org/mp3infotag.html#rev-method

I'll implement that.

edit: Okay, I now implemented both the "Xing" (VBR) vs "Info" (CBR) header marking and the "Info Tag revision + VBR method" to denote CBR encodings. Thanks for testing!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #89
Just tested this and while fb2k interprets it as expected, Windows Explorer doesn't see the correct bitrate and therefore shows an incorrect length. My test was at 320kbps and Windows showed 312kbps, so 4 mins 15 secs became 4 min 22 secs. Incidently, neither version of lametag could read the tag, although the newer version can read a lame encoded CBR tag.

Edit: I think the issue is that lame fills the Xing/Info header to the standard length and the current hmp3 'Info' tag doesn't.

Edit 2: Padding out the Xing/Info header results in the earlier lametag reader reading the tag correctly with correct delay/padding, but fb2k fails to read the delay/padding and Windows Explorer still shows the wrong length!! Seems to be something weird going on here!!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #90
Question from a noob: I never used it, although I remember seeing passing mentions of the Helix open source media project long ago. But now that it was long dead, what's the point of resurrecting the Helix MP3 codec? Does it do anything that LAME can't? Is it maybe just so that there's another free alternative to it?

I'm not being dismissive. It's just curiosity from an admitted ignorance standpoint.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #91
There are listening tests showing that Helix is as good as LAME quality-wise, if not better...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #92
helix was better on some music as lame. A very robust encoder imho. It never had to much attention and to this day i still don't know why -TX0 did best with some samples :)
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #93
Helix was known to be very fast - what does it take to encode on-the-fly in realtime nowadays?

And yes a good pair of ears could distinguish Helix from LAME even at a bitrate of 193: https://hydrogenaud.io/index.php/topic,113324.0.html
(The bar diagrams overlap, but the ANOVA test concludes Helix scores significantly better.)

Edit: my memory is just not reliable here. Surely I didn't remember Helix coming out on top in any test, but it was surprising that it even was competitive, given its reputation as a fast one ... but then, LAME had speed-ups at some stage too?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #94
I remember that Helix didn't have any noticeable chirping at VBR ~128kbps while LAME V5 with current VBR model did. My memory may screwing around with me though.
Opus VBR 256 + SoX

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #95
Windows Explorer doesn't see the correct bitrate and therefore shows an incorrect length.

Okay, that's a bit problematic to debug, given that I don't have the source code for Windows flying around. Does the length read correctly when writing "Xing" into the header instead of "Info" (which, apparently, some players need to detect CBR files)?

But now that it was long dead, what's the point of resurrecting the Helix MP3 codec? Does it do anything that LAME can't? Is it maybe just so that there's another free alternative to it?

Well, actually I went into this journey because I'm interested in low-bitrate 24 kHz "super-wideband" MP3 files to encode speech content in a "plays everywhere" format for the Web and I find (and I may have to be a bit cautious here to not infringe on TOS 8 here) Helix to fare better in low-bitrate situations. This *might* have something to do with LAME's psychoacoustic being mostly tuned for 44.1 kHz CD rips (the source code has a few "only tuned for 44.1 kHz" remarks), while Xing/RealNetworks/Helix presumably cared a bit more for low-bitrate (dial-up) applications.

For low bitrates, where transparency isn't expected to be achieved anyways, Helix does, e.g., support some stereo trickery ("intensity stereo" - basically just encode gentle hints on the stereo image, instead of "proper" mid/side stereo) that LAME doesn't support.

For instance, compare

Code: [Select]
lame -q 0 --lowpass 16000 --resample 44100 -b 96 <input.wav> <lame.mp3>

with

Code: [Select]
hmp3 <input.wav> <hmp3.mp3> -F16000 -B48 -N8

(96 kbps, 44.1 kHz, stereo for both encoders)

on a track such as Michael Jackson's "Beat it". For me, LAME collapses in to a warbly smeary mess, while Helix remains quite listenable for streaming-radio applications.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #96
There are listening tests showing that Helix is as good as LAME quality-wise, if not better...

Yes. there is Kamedo2 listening test. Helix came on top.

https://hydrogenaud.io/index.php/topic,113324.0.html

Considering Helix quality (and taking it's speed into account, I really can't see why is not popular as lame - is much faster and better quality - Am I missing something here...? )
lame --abr 288 -f --lowpass 17 (+ mp3gain@92 dB)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #97
Okay, that's a bit problematic to debug, given that I don't have the source code for Windows flying around. Does the length read correctly when writing "Xing" into the header instead of "Info" (which, apparently, some players need to detect CBR files)?
Yes, that fixes it except that fb2k displays it as VBR but is otherwise correct.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #98
I really can't see why is not popular as lame
Uh, well, ... a couple of shortcomings weren't fixed until ... like, a couple of weeks ago?  :D

(Besides, the "Helix" product range was originally associated with some DRM-infestation that Real Networks was peddling.)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #99
Considering Helix quality (and taking it's speed into account, I really can't see why is not popular as lame - is much faster and better quality - Am I missing something here...? )

Well, LAME is a proper community project, was developed in the open and comes with a well-known and somewhat well-understood license (LGPL, IIRC). Helix comes with an exotic open-source license that isn't as well known and was developed in a CVS repository you had to register access for (and I think that was read-access only, with actual commits being done RealNetworks employees). Also, Helix was open-sourced back ca. 2004 ~ 2005, when LAME was already well-established and momentum switched to MP3's successors.

As for "better quality": I guess one would need a proper blind test with several participants, just like in the good old days here on HA, to collect more data on this. I really like what hmp3 produces, though. Perhaps its also a case of "the artifacts sound *different*", which sounds refreshing ;-)

Okay, that's a bit problematic to debug, given that I don't have the source code for Windows flying around. Does the length read correctly when writing "Xing" into the header instead of "Info" (which, apparently, some players need to detect CBR files)?
Yes, that fixes it except that fb2k displays it as VBR but is otherwise correct.

This might actually warrant rolling back to writing "Xing" in the header, even for CBR files. fb2k might be fixable, but Windows isn't.