Resurrecting/Preserving the Helix MP3 encoder

Topic: Resurrecting/Preserving the Helix MP3 encoder (Read 53617 times) previous topic - next topic

0 Members and 3 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #350 – 2024-04-10 20:30:10

Thank you. Problem with BWF file was basically the same as with Porcus' W64 sample. The WAV reader had no support for WAV chunk alignment.
The other difference you see is related to different compilers doing the math differently so frames get allocated differently. If you look at the files in foobar2000 you will see that the decoded frame length is identical.

Fixed original WAV reader to take alignment into account. I didn't see a single mention of alignment in RF64 specs, I assume it uses the same WAV format's 2-byte alignment.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #351 – 2024-04-10 23:38:48

Quote from: Case on 2024-04-10 12:31:25

I hope I didn't break anything, but I trust @Kraeved will quickly figure out if I did.

To make sure Helix MP3 encoder would process a large input as expected, I took BWV 1034 Allegro (44.1 kHz 16-bit) and looped it N times using FFMPEG to get 5 GB W64¹ and RF64², then played with sampling rates³ and bit depths⁴, added various metadata chunks. In each case, I checked the encoding as is and via pipe.

¹ ffmpeg -v error -stream_loop 99 -i allegro.wav -f w64 - | hmp3 - out.mp3
² -f wav -rf64 auto
³ -af aresample=22050:resampler=soxr:precision=28
⁴ -acodec pcm_f32le

So far so good. However, I was confused by two things.

a) The new -IL flag must be used if you want to encode a large input in its entirety, but there is no warning on the screen if the file is large and the flag is not used. Perhaps the encoder should activate it automatically if the file is large enough? Otherwise, you're surprised to find that MP3 is only, say, 3 h 22 min out of (source) 3 h 56 min long.

b) The encoding speed dropped at times (watch animation), the cause of which I haven't yet determined (overheating, writing to the end of a clogged disc, or something else), but if anyone else encounters this, know that you're not alone.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #352 – 2024-04-10 23:52:22

Quote from: Kraeved on 2024-04-10 23:38:48

... and looped it N times using FFMPEG to get 5 GB¹, gradually changing the sampling rate, bit depth, adding various metadata chunks and using W64 & RF64² formats. In each case, I checked the encoding as is and via pipe. So far so good.

So ffmpeg is finally fixed then? I remember having a problem with huge files two years ago.

Quote from: Markuza97 on 2022-08-24 00:38:51

Sorry for hijacking your thread.

I have ~150 minute, 6 channel, 32-bit float, 48 kHz RF64 WAV file created by ffmpeg.

When I try to compress it using WavPack I get "xxx.wav is not a valid .WAV file!".
When I try to compress it using ffmpeg I get "100 buffers queued in out_0_0, something may be wrong."
When I try to play it in foobar2000 it says duration is over 1 day long.

Same file but this time exported by Audacity.

WavPack loves it.
ffmpeg same warning.
Duration in foobar2000 is correct.

ffmpeg bug?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #353 – 2024-04-11 06:40:11

@Case I extracted your Wav header alignment fixes from the previous patch with interdiff and pushed them onto the case-64bit-fixes branch: https://github.com/maikmerten/hmp3/commit/9c6c125805445a7857dbe7255dc01791e4be2a76

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #354 – 2024-04-11 06:41:22

Quote from: Kraeved on 2024-04-10 23:38:48

a) The new -IL flag must be used if you want to encode a large input in its entirety, but there is no warning on the screen if the file is large and the flag is not used.

That isn't quite correct. When you are encoding from a pipe, that mode is automatically enabled because input length can't be trusted. The newly supported Wave64, RF64, BW64 input formats aren't limited to 4 GB sizes, the ignore length option should not be used with these. It could only be useful in a very special circumstances where you write an invalid regular WAV file that's over 4 GB long and want to encode that without using pipes.
The encoder can't just blindly encode beyond the length reported in WAV file headers. You even provided a sample file with extra chunks after the data section which simple encoders encoded as audio. With pipes it is pretty safe to assume that we are receiving just audio data. But if you are reading from a file the ending can have all sorts of metadata that isn't actually audio.

We could add a warning message when encoding from a WAV file that has a header indicating maximum supported size.

Quote from: Kraeved on 2024-04-10 23:38:48

b) The encoding speed dropped at times (watch animation), the cause of which I haven't yet determined (overheating, writing to the end of a clogged disc, or something else), but if anyone else encounters this, know that you're not alone.

If your drives are regular hard drives and they are close to being full or very heavily fragmented it could be from slow seeking.
Your allegro loop test produced a 252 MB mp3 file here and even though the test drive I used shouldn't be that fragmented, it was still split in 44 different fragments.
In Windows fragmentation could be reduced by using a large write buffer and possibly eliminated entirely by telling the file system the file sizes in advance.
But this is just speculation. I haven't seen slowdowns. You'd need to use some system monitoring tools while encoding to see what hits its limits. The Task Manager in new Windows would be usable as it even shows disk utilizations. With older Windows perfmon can be used.

Quote from: maikmerten on 2024-04-11 06:40:11

@Case I extracted your Wav header alignment fixes from the previous patch with interdiff and pushed them onto the case-64bit-fixes branch: https://github.com/maikmerten/hmp3/commit/9c6c125805445a7857dbe7255dc01791e4be2a76

Ah, that's great!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #355 – 2024-04-11 11:20:28

Quote from: Case on 2024-04-11 06:41:22

The newly supported Wave64, RF64, BW64 input formats aren't limited to 4 GB sizes, the ignore length option should not be used with these. It could only be useful in a very special circumstances where you write an invalid regular WAV file that's over 4 GB long and want to encode that without using pipes.

Hmm, I get 3 h 22 min MP3 without -IL, whereas the source WAV RF64 is 3 h 56 min.
Does it mean that FFMPEG writes invalid WAV RF64 here?

Code: [Select]

$ mediainfo allegro.wav
General
Complete name                            : allegro.wav
Format                                   : Wave
Format settings                          : PcmWaveformat
File size                                : 47.7 MiB
Duration                                 : 4 min 43 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 1 411 kb/s
Producer                                 : TASCAM HD-P2
Description                              : tTAPE=090228
Encoded date                             : 2009-02-28 21:21:29

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 1
Duration                                 : 4 min 43 s
Bit rate mode                            : Constant
Bit rate                                 : 1 411.2 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Bit depth                                : 16 bits
Stream size                              : 47.7 MiB (100%)

$ ffmpeg -stream_loop 49 -i allegro.wav -f wav -acodec pcm_f32le -rf64 auto -write_bext 1 out.wav

$ mediainfo out.wav
General
Complete name                            : out.wav
Format                                   : Wave
Format profile                           : RF64
Format settings                          : WaveFormatEx
File size                                : 4.66 GiB
Duration                                 : 3 h 56 min
Overall bit rate mode                    : Constant
Overall bit rate                         : 2 822 kb/s
Encoded by                               : TASCAM HD-P2
Recorded date                            : 2009-02-28
Encoded date                             :
Writing application                      : Lavf61.3.100
Comment                                  : tTAPE=090228

Audio
Format                                   : PCM
Format profile                           : Float
Codec ID                                 : 3
Codec ID/Hint                            : IEEE
Duration                                 : 3 h 56 min
Bit rate mode                            : Constant
Bit rate                                 : 2 822 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Bit depth                                : 32 bits
Stream size                              : 4.66 GiB (100%)

$ hmp3case out.wav out.mp3
 pcm file:  channels = 2  bits = 32,  rate = 44100  type = 3
 Layer III   mode 1 STEREO   44100Hz  VBR-50
--------------------------------------------------------------------------------------
      Frames  |            Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
      466038  |           4294967296 /  196657861 |   100%   | 126.59 / 129.23 Kbps
--------------------------------------------------------------------------------------
 Compress Ratio 4.578798%

$ mediainfo out.mp3
General
Complete name                            : out.mp3
Format                                   : MPEG Audio
File size                                : 188 MiB
Duration                                 : 3 h 22 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 129 kb/s
Writing library                          : LAMEH5.22

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Format settings                          : Joint stereo / MS Stereo
Duration                                 : 3 h 22 min
Bit rate mode                            : Variable
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Frame rate                               : 38.281 FPS (1152 SPF)
Compression mode                         : Lossy
Stream size                              : 188 MiB (100%)
Writing library                          : LAMEH5.22
Encoding settings                        : -m  -V 5 -q 0 -lowpass 15.8

$ hmp3case -IL out.wav out-il.mp3
 pcm file:  channels = 2  bits = 32,  rate = 44100  type = 3
 Layer III   mode 1 STEREO   44100Hz  VBR-50
--------------------------------------------------------------------------------------
      Frames  |            Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
      542882  |           5003191296 /  229035869 |   100%   |  63.72 / 129.20 Kbps
--------------------------------------------------------------------------------------
 Compress Ratio N/A

$ mediainfo out-il.mp3
General
Complete name                            : out-il.mp3
Format                                   : MPEG Audio
File size                                : 218 MiB
Duration                                 : 3 h 56 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 129 kb/s
Writing library                          : LAMEH5.22

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Format settings                          : Joint stereo / MS Stereo
Duration                                 : 3 h 56 min
Bit rate mode                            : Variable
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Frame rate                               : 38.281 FPS (1152 SPF)
Compression mode                         : Lossy
Stream size                              : 218 MiB (100%)
Writing library                          : LAMEH5.22
Encoding settings                        : -m  -V 5 -q 0 -lowpass 15.8

However, W64 is encoded as expected without -IL, i.e. MP3 duration is the same as the source W64.

Code: [Select]

$ ffmpeg -stream_loop 49 -i allegro.wav -f w64 -acodec pcm_f32le out.w64

$ mediainfo out.w64
General
Complete name                            : out.w64
Format                                   : Wave64
File size                                : 4.66 GiB
Duration                                 : 3 h 56 min
Overall bit rate mode                    : Constant
Overall bit rate                         : 2 822 kb/s

Audio
Format                                   : PCM
Format profile                           : Float
Codec ID                                 : 3
Codec ID/Hint                            : IEEE
Duration                                 : 3 h 56 min
Bit rate mode                            : Constant
Bit rate                                 : 2 822 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Bit depth                                : 32 bits
Stream size                              : 4.66 GiB (100%)

$ hmp3case out.w64 out-w64.mp3
 pcm file:  channels = 2  bits = 32,  rate = 44100  type = 3
 Layer III   mode 1 STEREO   44100Hz  VBR-50
--------------------------------------------------------------------------------------
      Frames  |            Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
      542882  |           5003160800 /  229035869 |   100%   |  63.72 / 129.20 Kbps
--------------------------------------------------------------------------------------
 Compress Ratio 4.577823%

$ mediainfo out-w64.mp3
General
Complete name                            : out-w64.mp3
Format                                   : MPEG Audio
File size                                : 218 MiB
Duration                                 : 3 h 56 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 129 kb/s
Writing library                          : LAMEH5.22

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Format settings                          : Joint stereo / MS Stereo
Duration                                 : 3 h 56 min
Bit rate mode                            : Variable
Bit rate                                 : 128 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 kHz
Frame rate                               : 38.281 FPS (1152 SPF)
Compression mode                         : Lossy
Stream size                              : 218 MiB (100%)
Writing library                          : LAMEH5.22
Encoding settings                        : -m  -V 5 -q 0 -lowpass 15.8

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #356 – 2024-04-11 12:05:47

You are good at finding bugs. This was caused by a an oversight after fixing the WAV padding issue.
Fixes attached.

Edit: Bah. I can't remove these obsolete old attachments. Newer set can be found in a later post.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #357 – 2024-04-11 12:11:52

When hmp3 accepts piped input, the -IL parameter takes effect by default and does not need to be used explicitly.

The -IL parameter is not required when a correct Wave64 file is used as input.

When a WAV file exceeding 4G is used as input, an error will occur if the -IL parameter is not used explicitly.
This should be the logic

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #358 – 2024-04-11 16:27:01

I wanted to avoid adding size checks because that's more platform specific code. But I added a check for this requested feature.

I also noticed that the new status printing looks horrible on Windows with default 80 characters wide console. I experimented with various different methods that showed the sizes in KB, MB, and GB as needed but I didn't like any of these. But I think the routine I implemented for this patch is good enough: it shows input bytes as bytes when the number has 13 digits or less, if it gets longer it will switch to showing it in floating point terabytes, petabytes or exabytes as needed.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #359 – 2024-04-11 16:38:57

Thanks again, pushed that patch over to the case-64bit-fixes branch in this commit: https://github.com/maikmerten/hmp3/commit/1ded92c7e412296c9d0a10e1d0f2b7ef804e9920

I took the liberty of fixing this compiler warning by allocating a slightly bigger char buffer:

Code: [Select]

hmp3/src/test/tomp3.cpp:576:55: warning: ‘%3d’ directive writing between 3 and 10 bytes into a region of size 8 [-Wformat-overflow=]
  576 |         if ( progress >= 0 ) sprintf ( progress_str, "%3d%%", progress );
      |                                                       ^~~
hmp3/src/test/tomp3.cpp:576:54: note: directive argument in the range [0, 2147483647]
  576 |         if ( progress >= 0 ) sprintf ( progress_str, "%3d%%", progress );
      |                                                      ^~~~~~~
In file included from /usr/include/stdio.h:894,
                 from hmp3/src/test/tomp3.cpp:41:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:38:34: note: ‘__builtin___sprintf_chk’ output between 5 and 12 bytes into a destination of size 8
   38 |   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   39 |                                   __glibc_objsize (__s), __fmt,
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   40 |                                   __va_arg_pack ());
      |                                   ~~~~~~~~~~~~~~~~~

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #360 – 2024-04-13 13:06:10

Quote from: Case on 2024-03-20 14:59:02

Quote from: Kraeved on 2024-03-19 21:28:08
* Gapless. You mentioned this word several times in this thread, but what exactly do you mean?
In this context "gapless" mean that the encoded length is 100 % correct without silence added or samples removed. Perfect audibly gapless playback requires more work, if it's at all possible when working with separate tracks. I may test extrapolation filter to see if that improves things.

Last night I followed the white rabbit and got to the Mad Hatter's ~~ayahuasca~~ tea party. Among other odd things, he digitized vinyl in 768 kHz 64-bit float and then exported it for delivery in 384 kHz 32-bit integer. I rummaged among the records next to the smorgasbord and pulled out a few iconic ones, mixed entirely or almost without gaps, although accompanied by a cue sheet for convenient navigation. Let's see, or rather listen to how Helix MP3 encoder handles transitions between much-loved compositions using VBR mode.

Sources (IconicGapless.zip) were only resampled to 44.1 kHz via SoX DSP x64 before encoding.

• 1990. Enigma — MCMXC A.D. (Vinyl, 24/192)

Code: [Select]

ffmpeg -sseof -21.400 -i "01. The Voice Of Enigma.flac" -c:a pcm_s24le -map_metadata -1 -bitexact Enigma01.wav
ffmpeg -i "02. Principles Of Lust.flac" -t 23.400 -c:a pcm_s24le -map_metadata -1 -bitexact Enigma02.wav

• 1994. Vangelis — Blade Runner (Vinyl, 32/384)

Code: [Select]

ffmpeg -sseof -26.000 -i "A1 Main Titles.wv" -c:a pcm_s32le -map_metadata -1 -bitexact BladeRunner01.wav
ffmpeg -i "A2 Blush Response.wv" -t 23.600 -c:a pcm_s32le -map_metadata -1 -bitexact BladeRunner02.wav

• 2000. Hans Zimmer, Lisa Gerrard — Gladiator (CD, 16/44.1)

Code: [Select]

ffmpeg -sseof -23.900 -i "02. The Wheat.flac" -map_metadata -1 -bitexact Gladiator01.wav
ffmpeg -i "03. The Battle.flac" -t 30.000 -map_metadata -1 -bitexact Gladiator02.wav

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #361 – 2024-04-13 23:00:17

Finally had time to take a listen. All transitions sounded perfect to me.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #362 – 2024-04-14 08:44:20

@Case As far as I can tell, your recent round of fixes seems to work plenty great. Mind if I merge this to the main branch and bump the version to 5.2.3?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #363 – 2024-04-14 08:58:10

Indeed seems like no further issues have been found. I definitely don't mind at all.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #364 – 2024-04-14 09:30:01

Thanks! I merged your branch to main and bumped the version to 5.2.3.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #365 – 2024-04-14 10:58:48

@maikmerten, I downloaded the portable C and C++ development kit for Windows along with the Helix MP3 encoder source code, then typed make. As a result, I got hmp3.exe, but there are a few alarming lines in the compilation log. Is there anything we can do about it? There is a related thread on Stack Oveflow.

Code: [Select]

~ # cd hmp3
~/hmp3 # make
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/amodini2.o hmp3/src/amodini2.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/cnts.o hmp3/src/cnts.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/detect.o hmp3/src/detect.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/emap.o hmp3/src/emap.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/l3init.o hmp3/src/l3init.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/l3pack.o hmp3/src/l3pack.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/mhead.o hmp3/src/mhead.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/pcmhpm.o hmp3/src/pcmhpm.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/setup.o hmp3/src/setup.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/spdsmr.o hmp3/src/spdsmr.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/xhead.o hmp3/src/xhead.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/cnt.o hmp3/src/cnt.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/emdct.o hmp3/src/emdct.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/filter2.o hmp3/src/filter2.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/hwin.o hmp3/src/hwin.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/l3math.o hmp3/src/l3math.c

hmp3/src/l3math.c: In function 'align16':
hmp3/src/l3math.c:135:27: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
  135 |     y = ( float * ) ( ( ( ( int ) x ) + 15 ) & ( ~15 ) );
      |                           ^
hmp3/src/l3math.c:135:9: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
  135 |     y = ( float * ) ( ( ( ( int ) x ) + 15 ) & ( ~15 ) );
      |         ^

gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/pow34.o hmp3/src/pow34.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/sbt.o hmp3/src/sbt.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/xhwin.o hmp3/src/xhwin.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/xsbt.o hmp3/src/xsbt.c
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitallo.o hmp3/src/bitallo.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitallo1.o hmp3/src/bitallo1.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitallo3.o hmp3/src/bitallo3.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitalloc.o hmp3/src/bitalloc.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitallos.o hmp3/src/bitallos.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/bitallosc.o hmp3/src/bitallosc.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/mp3enc.o hmp3/src/mp3enc.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/srcc.o hmp3/src/srcc.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/srccf.o hmp3/src/srccf.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/srccfb.o hmp3/src/srccfb.cpp
gcc -O3 -c -I./hmp3/src/pub -DIEEE_FLOAT -D_FILE_OFFSET_BITS=64 -o builds/release/test/tomp3.o hmp3/src/test/tomp3.cpp
gcc -o builds/release/hmp3 builds/release/amodini2.o builds/release/cnts.o builds/release/detect.o builds/release/emap.o builds/release/l3init.o builds/release/l3pack.o builds/release/mhead.o builds/release/pcmhpm.o builds/release/setup.o builds/release/spdsmr.o builds/release/xhead.o builds/release/cnt.o builds/release/emdct.o builds/release/filter2.o builds/release/hwin.o builds/release/l3math.o builds/release/pow34.o builds/release/sbt.o builds/release/xhwin.o builds/release/xsbt.o builds/release/bitallo.o builds/release/bitallo1.o builds/release/bitallo3.o builds/release/bitalloc.o builds/release/bitallos.o builds/release/bitallosc.o builds/release/mp3enc.o builds/release/srcc.o builds/release/srccf.o builds/release/srccfb.o builds/release/test/tomp3.o -lm -lstdc++

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #366 – 2024-04-14 11:56:29

Thankfully you don't need to worry about that warning. That function is possibly some old leftover as it's not used anywhere in the code.
If it was actually used things wouldn't work at all in 64-bit build. The function truncates a 64-bit memory address when it gets stored in a 32-bit variable. Attempts to access data in the new wrong location would crash badly.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #367 – 2024-04-14 12:01:32

These warning are harmless - that function is superfluous for the C code path (not even used) and the 32-bit ASM code path has its own version. It's just left in there so there's a human-readable version for what the ASM version is doing.

(The warning basically says: Hey, pointers are 64-bit long on 64-bit architectures, you're calculating new pointer values in 32-bit - that's somewhat suspicous! - the compiler is right, but given that this code is never called in the C versions, it's of no consequence.)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #368 – 2024-04-16 22:01:49

Rescue rangers, we have a situation related to the CBR mode with a low bitrate. Unlike LAME, the -B flag of Helix sets the value for each channel, so to get 320 kbps, we enter 160, respectively, to get 24 kbps, I entered 12. But this time the encoding did not go as expected.

Code: [Select]

$ hmp3 -B12 gudki.11khz.mono.wav gudki.11khz.mono.mp3

pcm file:  channels = 1  bits = 16,  rate = 11025  type = 1
 Layer III   MONO   22050Hz   12kbps

-------------------------------------------------------------------------------
      Frames  |     Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
         621  |        352800 /      24293 |   100%   |  11.88 /  12.00 Kbps
-------------------------------------------------------------------------------
 Compress Ratio 6.885771%


$ hmp3 -B12 gudki.22khz.mono.wav gudki.22khz.mono.mp3

 pcm file:  channels = 1  bits = 16,  rate = 22050  type = 1
 Layer III   MONO   22050Hz   12kbps

-------------------------------------------------------------------------------
      Frames  |     Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
         621  |        705600 /      24293 |   100%   |  11.88 /  12.00 Kbps
-------------------------------------------------------------------------------
 Compress Ratio 3.442885%


$ hmp3 -B12 gudki.22khz.stereo.wav gudki.22khz.stereo.mp3

 pcm file:  channels = 2  bits = 16,  rate = 22050  type = 1
 Layer III   mode 1 STEREO  IS-3   22050Hz   24kbps

-------------------------------------------------------------------------------
      Frames  |     Bytes In  /  Bytes Out | Progress | Current/Average Bitrate
         622  |       1411200 /      48744 |   100%   |  23.80 /  24.00 Kbps
-------------------------------------------------------------------------------
 Compress Ratio 3.454082%


$ hmp3 -B12 gudki.44khz.stereo.wav gudki.44khz.stereo.mp3

 pcm file:  channels = 2  bits = 16,  rate = 44100  type = 1
 ENCODER INIT FAIL

a) gudki.11khz.mono.mp3 and gudki.22khz.mono.mp3 are malformed files (24 293 bytes), apps refuse to open them
b) gudki.22khz.stereo.mp3 is the only file here that is both encoded as expected (24 kbps) and playable
c) gudki.44khz.stereo.wav is not encoded with this setting at all, but the error message is quite vague

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #369 – 2024-04-17 07:02:09

A quick reply before taking a proper look...

Quote from: Kraeved on 2024-04-16 22:01:49

Unlike LAME, the -B flag of Helix sets the value for each channel, [...] to get 24 kbps, I entered 12. But this time the encoding did not go as expected.

For the first files the encoding went as you specified. The mono files have only one channel so the bitrate remained at the level you asked.

Quote from: Kraeved on 2024-04-16 22:01:49

a) gudki.11khz.mono.mp3 and gudki.22khz.mono.mp3 are malformed files (24 293 bytes), apps refuse to open them

The file is outside specs, also called "freeformat". There are some decoders with freeformat support, but of course it makes no sense to use such formats anywhere.
I think the best option is to disallow incorrect settings, what do you think?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #370 – 2024-04-17 07:33:21

Yeah, the "malformed" files appear to be free format. I wasn't aware Helix could do those, so that's a nice finding. Lame can decode those (e.g. "lame --decode gudki.22khz.mono.mp3"). As far as I can tell, Helix did exactly what you asked it to do, sadly many decoders cannot properly deal with this form of MP3.

Helix has a few checks to discourage settings that are deemed non-recommended. For instance, for 44.1 kHz files, it won't go below -B48 and will just barf "ENCODER INIT FAIL" at the user. When taking away those checks, Helix can, e.g., create "passable" 80 kbps 44.1 kHz CBR files with intensity stereo, but I so far refrained from relaxing those checks in fear that the encoder might explode in unexpected ways.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #371 – 2024-04-17 09:50:05

Free format is so extraordinary nowadays that one might consider to introduce a new restriction - like how LAME requires you to enter "--freeformat" to encode to such. Of course, more sorts of "overrule sanity" options may be up to some level of consideration, if one is so inclined.

(Just came to think about: Can it create "MPEG-2 only" files? Are they any problematic?)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #372 – 2024-04-17 12:21:08

@Case - I hate to bother you, but could you please post the latest binary of Helix to this thread? I try using the latest version from Rarewares (both 32 bit and 64 bit) and they both run really slow, and slow down my system...yet CPU utilization isn't near full when encoding using foobar2000.

For some reason your version from a few days ago (5.2.2) works flawlessly and fast. I have an AMD Ryzen 7 5700g, Windows 11, 32GB DDR4 RAM and 1TB nvme SSD if that matters.

The last version of helix to work from Rarewares from about March 21 I think? Every version after that either 32 or 64 bit, runs really slow, and hangs the system and just makes everything slow down to almost a crawl yet CPU usage is about half.
Thanks so much!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #373 – 2024-04-17 12:45:55

Quote from: KevinB52379 on 2024-04-17 12:21:08

@Case - I hate to bother you, but could you please post the latest binary of Helix to this thread? I try using the latest version from Rarewares (both 32 bit and 64 bit) and they both run really slow, and slow down my system...yet CPU utilization isn't near full when encoding using foobar2000.

For some reason your version from a few days ago (5.2.2) works flawlessly and fast. I have an AMD Ryzen 7 5700g, Windows 11, 32GB DDR4 RAM and 1TB nvme SSD if that matters.

The last version of helix to work from Rarewares from about March 21 I think? Every version after that either 32 or 64 bit, runs really slow, and hangs the system and just makes everything slow down to almost a crawl yet CPU usage is about half.
Thanks so much!

That's odd. I use Ryzen 7s and 9s and I haven't noticed an issue. I'll check it out a little later. Thanks for the notification.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #374 – 2024-04-17 13:46:43

I have no idea. Honestly, this is the first time I've ever had an issue using any of your binaries at RareWares. I've used your LAME binaries, Ogg Vorbis binaries and Opus binaries for well over a decade with no issues...so I'm not sure.

As I said the build, I believe it was from March 21, works fine, but everything newer from late March until mid April has these slow down issues, where it encodes slow, and the system hangs.

But if I use Case's build attached to this forum from a few days ago (5.2.2) it works perfectly fine (I know it's a Win32 binary).

If you want me to test something, let me know, I'd be happy to try and troubleshoot for you!

Notice