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.
Recent Posts
1
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
The Helix MP3 Encoder is using floating point arithmetic (and LAME does, too). It's perfectly expected that there are slight variations in output depending on compiler version, compiler flags and platform. Rearranging floating point operations (that should be mathematically equal) can result in small (and usually inconsequential) differences in floating point values.

I don't expect hmp3 to generate identical files for Visual Studio, GCC 10.x or GCC 13.x, let alone if different instruction sets are involved.

i586 uses the x87 instruction set for floating point.
i686 uses the SSE instructions for floating point.
The Visual Studio compiles with ASM use a mixture of x87 instructions and SSE.
The Win64 x86_64-builds can use SSE(2)
I think Case's builds were AVX-enabled.
2
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by Kraeved -
As I understand it, the latest version with reasonable and properly tested changes that can run on both x86 and x64 is the @Case's build 2024-03-20. After that, you went into micro-optimization, changing the makefile and now the memsets. This has already affected the size of mp3 files, so users may have a legitimate question: if the encoding algorithm is not changed, then why mp3 files are different from each other? We need to create a stable version so that users don't wade through dozens of pages, trying out every attachment, as it happens in some other forum threads.

Code: [Select]
bytes, xxhash, filename
270150 = 71f16bfc93121db3 = out-i686.mp3
270154 = 7658cb1d84627d25 = out-i586.mp3
270227 = dad23bd189aeb6c6 = out-git-fb6f2b2.mp3
270227 = dad23bd189aeb6c6 = out-i686v2.mp3
270230 = 284a80c89cdf720b = out-case.mp3
4
General Audio / Re: How do you test SACD audio dynamic range?
Last post by wojak -
I have the 2024 Steely Dan - Aja new release from Acoustic Sounds Analogue Productions.

I can get the DSF files from disk, but I'm facing that the audio level can be easily manipulated by changing the volume [db] 0 - +6.
Can you get an honest dynamic range from SACD? 🤔

Good old and much hated DRmeter plugin for foobar will measure it and even write the DR to tag. But it only works in 32bit version of Foobar.
Replaygains also works - from that you can get True Peak, LUFS and PLR.
It works on SACDiso so probably on DSF and DFF too.
5
3rd Party Plugins - (fb2k) / Re: foo_vis_spectrum_analyzer
Last post by TF3RDL -
Work in progress: Scrolling spectogram with the SoX color scheme


I noticed the "regression" on how low frequencies look (what I meant is the sinc-interpolation on bass frequencies (assuming log frequency scale) is now improper unlike this, which is proper and matches zero-padded FFTs) becomes obvious with spectrogram display as "artifacts" on lower frequencies that doesn't appear in fb2k's built-in spectrogram even with the same window function (Gaussian window with parameter of 2.4)

BTW, this makes me want a spectrogram (and combined spectrum/spectrogram) mode for @Crossover's foo_enhanced_spectrum_analyzer more :D
7
MP3 - General / Re: Resurrecting/Preserving the Helix MP3 encoder
Last post by maikmerten -
These changes are only style- and safety-changes.

The memset for spd_cnt1Short shouldn't change runtime-behavior at all, as both spd_cnt1Short and spd_cnt have the same size, thus memset doing the same. This is only fixing a copy&paste oversight, and I fixed this to avoid confusion.

The memset for w_spdShort is more serious, as w_spd is a *bigger* buffer than w_spdShort and thus the memset would write zeroes beyond the boundaries of the w_spdShort-buffer. However, if the encoder doesn't crash during initialization, no effect otherwise is necessarily expected.

I checked before and after the changes, and the MP3 output remained identical.

As for providing fresh builds for whatever current git-state: Well, if several people keep their build-environment fired up, even if the changes are minimal, it is beneficial to know that no breaking changes were introduced by accident. I can only test on Linux and with whatever compiler version I have installed, so having another set of compiles available can be useful to gauge whether some recent work broke things.
10
Listening Tests / Re: Great killer sample, easy to ABX on most codecs
Last post by Kraeved -
Lame 3995o vbr -q1 cannot be better than any 320cbr. Helix is old, good yes but still mp3.
Just in case for less informed users among us: it's not -q1, but -Q1, a tweaked approach implemented by @halb27.

Actually, I agree with @maikmerten, who said: “Your LAME 3.995o encode did overall a better job, certainly better than LAME 3.100 for this sample. However, as one can see in the spectrogram, it somewhat avoided most of the sbf21 trouble by effectively lowpassing the high frequency band [using transition band 17960 Hz - 18494 Hz] and thus getting rid of the excessive energy there, which might be the best tradeoff in this case”. Helix without -HF2 used an even lower 16536 Hz limit and also sounds fine (with enough hiss, but without metallic fluctuations and ultrasonic bloat).

Input.


Output. lame3995o -Q1


Output. hmp3 -V150