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 33519 times) previous topic - next topic
maikmerten, john33 (+ 1 Hidden) and 9 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #50
As an aside, on my 8500T based test micro system, a 64 bit build of the C code using LLVM 15.0.5, optimised for AVX2 is roughly 10% faster than the 32 bit ASM build.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #51
As an aside, on my 8500T based test micro system, a 64 bit build of the C code using LLVM 15.0.5, optimised for AVX2 is roughly 10% faster than the 32 bit ASM build.

Did you specify the "-U2"-flag to use the Pentium III (=SSE) code path for 32-bit?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #52
Did you specify the "-U2"-flag to use the Pentium III (=SSE) code path for 32-bit?
Actually, no. Using -U2, results in more or less identical times.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #53
Thanks to Peter in the fb2k forums it became clear that the Helix encoder writes a slightly off (by +1) number of total frames into the Xing VBR header. fb2k doesn't decode until the last frame (then discards surplus samples), but uses the number of frames to determine the total number of samples, then subtracts the padding.

Long story short: I pushed changes to GitHub so that encodes should now be sample-accurate-length in fb2k.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #54
I can confirm all is good. Many thanks for your efforts in solving all the issues here. Great work! :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #55
@maikmerten, I hope you don't mind but I have taken the liberty of providing this on rarewares, attributed to you, in place of the old compile which obviously had issues.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #56
@maikmerten, I hope you don't mind but I have taken the liberty of providing this on rarewares, attributed to you, in place of the old compile which obviously had issues.

Thanks for your vote of confidence, your testing and providing Windows builds! :-)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #57
You might be amused to know that LameTag 0.4.1 still fails to read the tag. However, I discovered I had version 0.3.1, including the pascal/Delphi source, and that reads the tag perfectly!!

If you're interested, you can d/l from here: https://www.rarewares.org/files/LameTag-0.3.1.zip

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #58
Wow! Never thought the gapless implementation will come at all, leave alone that fast. I asked for that several years back already.
Thanks for your time folks :)
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #59
You might be amused to know that LameTag 0.4.1 still fails to read the tag. However, I discovered I had version 0.3.1, including the pascal/Delphi source, and that reads the tag perfectly!!

If you're interested, you can d/l from here: https://www.rarewares.org/files/LameTag-0.3.1.zip

Well, I'm pretty sure that many MP3 tools have some built-in assumptions that are based on what LAME in particular is doing.... and who can blame them, with no other implementations choosing to implement the info tag?

Wow! Never thought the gapless implementation will come at all, leave alone that fast. I asked for that several years back already.
Thanks for your time folks :)

You're welcome, it's a fun side-project!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #60
A slight conundrum. According to LameTag 0.4.1, the latest 'lame-svn-r6507-trunk' writes Revision 0 to the lametag. Strangely, LameTag 0.3.1 fails to read the lametag beyond indicating the lame version. Changing the Revision number to 0 in hmp3 results, in my tesfile, in 196 fewer bytes being written which is reflected in the padding being reduced by the number. fb2k appears to be Revision agnostic as it displays the correct information for both files and decodes correctly. Probably of no consequence but just struck me as odd.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #61
Changing the Revision number to 0 in hmp3 results, in my tesfile, in 196 fewer bytes being written which is reflected in the padding being reduced by the number.

I'm not sure I follow. Did you edit xhead.c to simply write "version 0" into the info tag version field and suddenly fewer bytes are emitted?

I used http://gabriel.mp3-tech.org/mp3infotag.html as specification. Sadly, I don't see information on what version that spec describes, so I just assumed it would be the presumably more recent one ("version 1").

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #62
Changing the Revision number to 0 in hmp3 results, in my tesfile, in 196 fewer bytes being written which is reflected in the padding being reduced by the number.

I'm not sure I follow. Did you edit xhead.c to simply write "version 0" into the info tag version field and suddenly fewer bytes are emitted?

I used http://gabriel.mp3-tech.org/mp3infotag.html as specification. Sadly, I don't see information on what version that spec describes, so I just assumed it would be the presumably more recent one ("version 1").
Yes, that's all I did. Bizarre, I know, but I can't follow the lame code well enough to understand what's going on.

 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #63
Yes, that's all I did. Bizarre, I know, but I can't follow the lame code well enough to understand what's going on.

Ah, so you played around with LAME, not the Helix encoder?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #64
No, I changed the Revision number in xhead.c. I wasn't trying to be contentious, I was just trying to understand the difference between the revisions. ;)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #65
No, I changed the Revision number in xhead.c. I wasn't trying to be contentious, I was just trying to understand the difference between the revisions. ;)

Ah, okay, thanks for confirming. Then I don't see a reason why just changing the version of the info tag in xhead.c would have any effect on the number of bytes being written. The length of the header is determined before the actual encoding loop (line 607 in tomp3.cpp) and there's no code there to switch between version 0 and 1. The actual info header contents (including the version number) are written after the encoding loop (line 777 in tomp3.cpp). At that point the file size should already be final...

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #66
Apologies, I think I managed to confuse myself and mixed up what was encoded using the asm build and that which was encoded with the 64 bit C build. I have just confirmed that you are, of course, correct. Sorry about that!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #67
No problem, at least this confirms that the ASM builds follow a different codepath ;-)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #68
I managed to get gapless in CBR by modifying the header in the mp3 file and it works just like in VBR. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #69
Interesting, Did they ever release their raac encoder on Helix? Or was it MP3 only?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #70
I managed to get gapless in CBR by modifying the header in the mp3 file and it works just like in VBR. :)

Hi KrajzegaX, yeah, there's no proper reason why it shouldn't work for CBR - its just that RealNetworks didn't hook up the logic to submit the bitrate to their Xing-Header code. However, I know quite exactly where to hook things in and opened a ticket for that: https://github.com/maikmerten/hmp3/issues/1

(Long story short: For VBR, the header logic can just choose the smallest frame bitrate for the info frame that is big enough to fit all that information - it's VBR, after all, so frames can be of different size. For CBR, the header logic needs to pick exactly the same frame  bitrate as for the audio frames, it wouldn't be CBR otherwise. However, RealNetworks just submits "0" to the header code as bitrate, which means the information will never fit, thus the info frame is skipped)

I hope to get to that pretty soon.

Interesting, Did they ever release their raac encoder on Helix? Or was it MP3 only?

To my knowledge, they never opened their proprietary format encoders.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #71
Okay, took the liberty of enabling the Xing/Info-Header for CBR files now. Also, since yesterday, MPEG-2 files get the Xing/Info-Header as well.

edit: Note that for very low CBR bitrates, the info header may not fit and is then disabled.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #72
Fresh compiles at rarewares. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #73
I believe the version number should be bumped to Helix 6.
Thanks to the renovation effort of maikmerten, the new Helix is now very modern, compared to the ancient 2005 version, Helix v5.1.
Easier to recognize if the major version number is higher.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #74
I second that. Gapped playback is such a shortcoming that resurrecting it into a proper gapless-enabled encoder warrants a major-version-bump.

Going for "LAMEH5.11" for now. The "." makes it look better parseable as version number. The "H" behind LAME denotes "Helix" (I really really don't want to steal an actual LAME version string).
LAMELIX6.0 starts with "LAME", is sufficiently close to "HELIX" and ... well is the string too long? To test that, call it LAMELIX6.beta and see how many applications choke on it.

Also, the string now contains "MEH", which is neat.
If testing indicates that this works everywhere, I'd say you have de-meh'ed it successfully.