Resurrecting/Preserving the Helix MP3 encoder

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

0 Members and 1 Guest 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.)

Notice