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

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #325 –
Quote from: synclagz on
Perhaps you could do your own ABX test to see if you can hear the difference… This way you can eliminate any dilemma you might have. After all, personal preference is what matters the most.
It's not about my dilemma, but about a better future where more users get the most out of the Helix MP3 encoder.

Not only do I use this tool myself, but I also generously share its results and evangelize its use among comrades who dedicated their lives to other professions and hobbies. "Kraeved, our neighbors say that you are privy to sound tools, whereas I work as a truck driver by day and knit funny socks for less fortunate by night, could you tell me how best to convert that eye-opening book by Eckhart Tolle from FLAC to use with my easily distorted car player?” Therefore, the criterion of personal satisfaction is not sufficient to justify the recommendation here. We must rely on a stronger evidence not to indulge in wishful thinking and to guide the masses in a more responsible way.

Such evidence grows as dear enthusiasts, armed with a wider range of audio samples, equipment and innate features than I can only dream of, accept the challenge of taming Helix's psychoacoustic model and identifying cases where approximate copies of the original are strikingly different from each other due to the presence of higher frequencies.

The community and its tools become more reliable when the pillars rest on the solid ground of consensus rather than on the postmodern relativism with confusing and vacillating individual pronouns truths. I am thrilled to be a part of such community, but too humble to believe that my limited experience is enough to proceed. That's why I urge us, at least those of us who like challenges, to pay more attention to comparing the encoding with and without -HF2 flag.

The road to a better future may not be smooth, but it is within our reach.

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #326 –
That has to be one of the weakest and most asinine responses I have ever seen! You suffer from verbal diarrhoea and need treatment.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #327 –
HF1 vs 2 likely don't matter . The whole thing don't matter as scalefactor band 21 isn't calculated. Typically you go for 16khz @ 128 k cbr.  From 160k set lowpass/HF to highest level you want up to 20khz as long as something like -Y is enabled in vbr or using cbr/abr encoding when it happens by design.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #328 –
Oh, HF1 and HF2 makes a difference, and I think I finally figured out what it is. According to the help function, HF1 enables high frequencies for "mode-1 granules", while HF2 enables high frequencies for "all granules".

It took me a while to figure out what "mode-1 granules" are: This means "M/S stereo" ("joint stereo") granules.

With HF1, *only* parts that are coded in M/S stereo can also carry high frequency content. Of course, the encoder will dynamically switch between stereo ("mode 0") and M/S stereo ("mode 1") depending on what is more efficient. Very roughly estimated, about 80% of frames are M/S-coded, while about 20% of frames are stereo-coded.

In other words, in a typical scenario, about 20% of frames don't have high frequency content with HF1. I can imagine (but I personally cannot hear this, so this is speculation) that some persons might be able to perceive the high-frequency "dropouts" with HF1.

Thus, personally, I'd go with HF2.

Why have HF1 in the first place? I speculate that this mostly (only?) makes sense in CBR encoding. If M/S-stereo is less efficient than stereo coding, then usually the two channels don't correlate much. Thus, more bits are needed to encode the stereo signal in the first place. In this scenario, when bits are limited, it may be best to have as many bits as possible for frequencies below 16 kHz by omitting high frequency content.

In VBR encoding, though, one usually can just allocate a few more bits without starving the more relevant (lower) frequency bands.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #329 –
Hello, everyone
My English is not good and my expression may not be accurate enough, please forgive me.
Longer audio (for example, more than 3 or 4 hours) encoded by hmp3 will have a high probability of playback failure. The audio file can display the correct duration in mediainfo, but in players such as foobar2000 and mpc, the audio Only the first part of the duration can be recognized and played normally, and the extra long part cannot be recognized and played by the player. This problem exists in multiple versions up to the latest, please check it out.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #330 –
Thanks for the problem report. Note that you can repair existing files with foobar2000 using the 'Utilities' -> 'Fix VBR MP3 header...' feature.
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #331 –
Quote from: maikmerten on
Oh, HF1 and HF2 makes a difference, and I think I finally figured out what it is.
[...]
With HF1, *only* parts that are coded in M/S stereo can also carry high frequency content. Of course, the encoder will dynamically switch between stereo ("mode 0") and M/S stereo ("mode 1") depending on what is more efficient. Very roughly estimated, about 80% of frames are M/S-coded, while about 20% of frames are stereo-coded.

This is an interesting insight. Thank you for your research. To visualize this, I created and encoded a pink noise file.
Settings used are -V110 -HF[1|2]. For both encoded files, an mp3 analysis shows 18.0 % Simple stereo frame
and 82.0 % Mid-side stereo frames.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #332 –
Thanks
foobar2000 'Utilities' -> 'Fix VBR MP3 header...'

It solved the problem.
But
Why does "cbr" encoded mp3 require "vbr header fix"?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #333 –
Quote from: ha7pro on
Why does "cbr" encoded mp3 require "vbr header fix"?
The info header at the beginning of MP3 was originally only needed and used for VBR files, otherwise players couldn't even know a track length without parsing throught the entire track. I guess foobar2000 could update its texts.

Attached is a fix for the issue ha7pro reported, both source patch and 32-bit win32 asm build. I hope I didn't break anything, but I trust @Kraeved will quickly figure out if I did.
The problem was related to input exceeding 4 GB, 32 bit variables wrapped over causing all sort of havoc. Fixed that by changing related variables to unsigned 64-bit integers.
I added an extra command line parameter -il (for ignore length) to allow ignoring source length. That way if you for example use foobar2000 to create a huge temporary WAV file it can be encoded fully without input size getting clipped to 4 GB. Ideally this should only be needed with pipe encoding, but I have made the encoder turn this mode on automatically with pipe input.

Since the encoder now supports over 4 GB input I added support for Wave64 file format. The support was only tested with basic w64 file created with foobar2000, so the support may be bugged with edge cases.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #334 –
it works
everything is ok
thanks a lot

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #335 –
Not saying this is all-important, but RF64 is a "more trivial" format once WAVE is supported?
The ITU are trying to kill it off and replace it by BW64 (with a "BW64" fourcc and discouraging WAVEFORMATEXTENSIBLE channel mask ... but is it still possible to know that a file is mono or stereo?)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #336 –
@Case, thanks a lot. I applied these patches to the GitHub version. The changes are currently living in this branch: https://github.com/maikmerten/hmp3/tree/case-64bit-fixes

On Linux, the progress indicator isn't updating on the same line anymore. I'll look into fixing this.

edit: This is caused by the line length exceeding the default terminal line width, thus the \r control working on the next line. I'll try to format the output a bit.

edit2: Fixed in https://github.com/maikmerten/hmp3/commit/3a9d3e2c9c785b97bd922d97a02441f9dec3a29c

btw, just in case anyone is wondering why I keep updating the date of last change and editor in the file header, that's caused by a term in the RPSL license...

Quote
(c) You must duplicate, to the extent it does not already exist, the notice in
Exhibit A in each file of the Source Code of all Your Modifications, and cause
the modified files to carry prominent notices stating that You changed the files
and the date of any change;

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #337 –
Quote from: Porcus on
Not saying this is all-important, but RF64 is a "more trivial" format once WAVE is supported?
The ITU are trying to kill it off and replace it by BW64 (with a "BW64" fourcc and discouraging WAVEFORMATEXTENSIBLE channel mask ... but is it still possible to know that a file is mono or stereo?)
Oh no, I was just coming to update my patch with RF64 support and this bit of info was waiting for me. Quick look at the specs suggests that it's not so different, so I added support for that BW64 fourcc to the RF64 support code. This addition was very last second, I don't have a clue if it works.

Quote from: maikmerten on
On Linux, the progress indicator isn't updating on the same line anymore. I'll look into fixing this. edit: This is caused by the line length exceeding the default terminal line width
Even more oh no. I forgot I had gotten annoyed at the default 80 characters not being enough for anything so all my terminals are much wider. No wonder I had so much extra space to increase the fields. 4 GB+ input required extending input byte counter from 10 characters to 20 characters. Sorry about the mess.

Attached updates with RF64 (and possibly BW64) input support.

Edit: horrible bug in the sources (should have tested with actual files).
The RF64 support code uses wrong field for data size, pcmhpm.c line 400 should read
Code: [Select]
*data_size = get_field64 ( chunk_ds64->dataSize, sizeof ( chunk_ds64->dataSize ), f_info->bigendian ); /* return actual audio data size to the frontend */

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #338 –
Was just about to update Rarewares!! ;) I'll wait a short time. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #339 –
I updated my post with a fix to the RF64 reading. Unfortunately my Audition is too old and can't write BW64 to create a test file.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #341 –
It does. I was pleasantly surprised to see that a forum problem that prevented me from removing attachments had been fixed.
Unfortunately this still includes the printing problem that you had fixed.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #342 –
Oh, I took the liberty of taking away a few dashes in the output, so things are super-okay in the terminal.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #343 –
On BW64,
Can one use https://github.com/ebu/libbw64 ?
Like more of us, I was unaware this format existed until @bennetng posted some files made by Reaper in https://hydrogenaud.io/index.php/topic,123862.25.html reply #25. There is/was some misinformation around including Wikipedia.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #344 –
The RF64 and BW64 files from his archive encode fine with hmp3. But the included reaper-wave64.wav file doesn't. I don't understand what I'm missing. The fmt chunk starts at offset 40, it reports its size as 42. That means next chunk should start at offset 82. There's just zeroes there, the next real chunk is data chunk that starts at offset 88.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #346 –
I know it's Wave64. It just doesn't seem to follow the specs I have. I'm using the 'Sony_Wave64.pdf' bryant linked not that long ago. The fmt chunk size is off by 6 bytes and I don't know why.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #347 –
Excuse my silliness. It was of course the 8 byte alignment.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #348 –
The bitwise AND for checking if sizes are divisible by 8 didn't work with the 64-bit integer, that's why Porcus' linked file didn't work. There was also a problem with my sanity checks to abort parsing if data doesn't make sense. The give-up-size was treated as signed and it never triggered. Those issues are fixed here.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #349 –
a) Source: bwf.wav. WAV (including RF64) is not encoded if (malformed? incorrectly padded?) bext chunk of BWF extension is present. Error: “UNRECOGNIZED PCM FILE TYPE”.

b) Source: gudki.wav. Differences in the number and bitrate of frames between builds.

Code: [Select]
$ hmp3johnx64.exe gudki.wav gudki.john.mp3
--------------------------------------------------------------------------------------
      Frames  |            Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
         625  |              1411200 /     104156 |   100%   |  43.13 /  51.03 Kbps
--------------------------------------------------------------------------------------
 Compress Ratio 7.380669%

$ mp3packer -i gudki.john.mp3
 Bitrate distribution:
    8: 13,0
   24: 1,0
   40: 40,0
   48: 256,0
   56: 266,0
   64: 49,0

$ hmp3case.exe gudki.wav gudki.case.mp3
--------------------------------------------------------------------------------------
      Frames  |            Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
         621  |              1411200 /     103974 |   100%   |  43.48 /  51.27 Kbps
--------------------------------------------------------------------------------------
 Compress Ratio 7.367772%

$ mp3packer -i gudki.case.mp3
 Bitrate distribution:
    8: 9,0
   24: 1,0
   32: 1,0
   40: 42,0
   48: 250,0
   56: 271,0
   64: 47,0
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data